[PATCH 05/12] ARM: dts: APQ8064: Add MDP support
From: Rob Clark
This patch adds MDP node to APQ8064 dt.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 112
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index e65aff0..9c2e9b2 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -1,6 +1,7 @@
/dts-v1/;
#include "skeleton.dtsi"
+#include
#include
#include
#include
@@ -94,6 +95,20 @@
};
};
+ hdmi_pinctrl: hdmi-pinctrl {
+ mux1 {
+ pins = "gpio69", "gpio70", "gpio71";
+ function = "hdmi";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+ mux2 {
+ pins = "gpio72";
+ function = "hdmi";
+ bias-pull-down;
+ drive-strength = <16>;
+ };
+ };
ps_hold: ps_hold {
mux {
pins = "gpio78";
@@ -228,6 +243,18 @@
};
};
+ ext_3p3v: regulator-fixed@1 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "ext_3p3v";
+ regulator-type = "voltage";
+ startup-delay-us = <0>;
+ gpio = <_pinmux 77 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+
qcom,ssbi@50 {
compatible = "qcom,ssbi";
reg = <0x0050 0x1000>;
@@ -426,6 +453,13 @@
reg = ;
};
+ pm8921_hdmi_mvs: pm8921-hdmi-mvs {
+ compatible = "qcom,rpm-pm8921-switch";
+ reg = ;
+ regulator-always-on;
+ bias-pull-down;
+ };
+
pm8921_l28: pm8921-l28 {
compatible = "qcom,rpm-pm8921-nldo1200";
reg = ;
@@ -704,5 +738,83 @@
pinctrl-0 = <_gpios>;
};
};
+
+ hdmi: qcom,hdmi-tx@4a0 {
+ compatible = "qcom,hdmi-tx-8960";
+ reg-names = "core_physical";
+ reg = <0x04a0 0x1000>;
+ interrupts = ;
+ clock-names =
+ "core_clk",
+ "master_iface_clk",
+ "slave_iface_clk";
+ clocks =
+ < HDMI_APP_CLK>,
+ < HDMI_M_AHB_CLK>,
+ < HDMI_S_AHB_CLK>;
+ qcom,hdmi-tx-ddc-clk = <_pinmux 70
+ GPIO_ACTIVE_HIGH>;
+ qcom,hdmi-tx-ddc-data = <_pinmux 71
+ GPIO_ACTIVE_HIGH>;
+ qcom,hdmi-tx-hpd = <_pinmux 72
+ GPIO_ACTIVE_HIGH>;
+ core-vdda-supply = <_hdmi_mvs>;
+ hdmi-mux-supply = <_3p3v>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pinctrl>;
+ };
+
+ gpu: qcom,adreno-3xx@430 {
+ compatible = "qcom,adreno-3xx";
+ reg = <0x0430 0x2>;
+ reg-names = "kgsl_3d0_reg_memory";
+ interrupts = ;
+ interrupt-names = "kgsl_3d0_irq";
+ clock-names =
+ "core_clk",
+ "iface_clk",
+ "mem_clk",
+ "mem_iface_clk";
+ clocks =
+ < GFX3D_CLK>,
+ < GFX3D_AHB_CLK>,
+ < GFX3D_AXI_CLK>,
+ < MMSS_IMEM_AHB_CLK>;
+ qcom,chipid = <0x03020002>;
+ qcom,gpu-pwrlevels {
+ compatible =
[PATCH 10/12] ARM: dts: apq8064: Remove incorrect gsbi2 node.
Commit 8c3166f5d74b7936d29dc44f778e759c1b9fb43a (ARM: DT: apq8064: Add i2c
device nodes)
added a new gsbi2 node which is totally wrong for 2 reasons.
First the address range is not something which maps to gsbi2 according
to datasheet and 3.4 sources.
Secondly 8064 devices do not use gsbi2 for i2c according to 3.4 kernel sources.
Removing this node as this node would never get tested.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 20
1 file changed, 20 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 63edafc..ba44f30 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -201,26 +201,6 @@
};
};
- gsbi2: gsbi@1248 {
- status = "disabled";
- compatible = "qcom,gsbi-v1.0.0";
- reg = <0x1248 0x100>;
- clocks = < GSBI2_H_CLK>;
- clock-names = "iface";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- i2c2: i2c@124a {
- compatible = "qcom,i2c-qup-v1.1.1";
- reg = <0x124a 0x1000>;
- interrupts = <0 196 IRQ_TYPE_NONE>;
- clocks = < GSBI2_QUP_CLK>, <
GSBI2_H_CLK>;
- clock-names = "core", "iface";
- #address-cells = <1>;
- #size-cells = <0>;
- };
- };
gsbi7: gsbi@1660 {
status = "disabled";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] ARM: dts: Move i2c1 pinctrl to apq8064.dtsi
I2C1 pinctrl is not really specific to a board, moving to SOC dtsi would
avoid redefining this in every board.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 7 ---
arch/arm/boot/dts/qcom-apq8064.dtsi| 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 7a6a076..ab7aee2 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -11,13 +11,6 @@
soc {
pinctrl@80 {
- i2c1_pins: i2c1 {
- mux {
- pins = "gpio20", "gpio21";
- function = "gsbi1";
- };
- };
-
card_detect: card_detect {
mux {
pins = "gpio26";
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index ba44f30..09077a0 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -115,6 +115,13 @@
function = "ps_hold";
};
};
+
+ i2c1_pins: i2c1 {
+ mux {
+ pins = "gpio20", "gpio21";
+ function = "gsbi1";
+ };
+ };
};
intc: interrupt-controller@200 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/12] ARM: dts: apq8064 add i2c3 node for panel.
This patch adds i2c3 node which is used for panel control on IFC6410.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 10 ++
arch/arm/boot/dts/qcom-apq8064.dtsi| 25 +
2 files changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index ab7aee2..70fa747 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -20,6 +20,16 @@
};
};
+ gsbi3: gsbi@1620 {
+ status = "okay";
+ qcom,mode = ;
+ i2c3: i2c@1628 {
+ status = "okay";
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ };
+ };
+
gsbi@1244 {
status = "okay";
qcom,mode = ;
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 09077a0..890db8e 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -122,6 +122,13 @@
function = "gsbi1";
};
};
+
+ i2c3_pins: i2c3 {
+ mux {
+ pins = "gpio8", "gpio9";
+ function = "gsbi3";
+ };
+ };
};
intc: interrupt-controller@200 {
@@ -208,6 +215,24 @@
};
};
+ gsbi3: gsbi@1620 {
+ status = "disabled";
+ compatible = "qcom,gsbi-v1.0.0";
+ reg = <0x1620 0x100>;
+ clocks = < GSBI3_H_CLK>;
+ clock-names = "iface";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ i2c3: i2c@1628 {
+ compatible = "qcom,i2c-qup-v1.1.1";
+ reg = <0x1628 0x1000>;
+ interrupts = <0 151 IRQ_TYPE_NONE>;
+ clocks = < GSBI3_QUP_CLK>, <
GSBI3_H_CLK>;
+ clock-names = "core", "iface";
+ };
+ };
gsbi7: gsbi@1660 {
status = "disabled";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/12] ARM: DT: apq8064: Add USB OTG support for CM QS-600
From: Nicolas Dechesne
This patch adds USB OTG support on USB1 for Compulab QS-600 Board.
Signed-off-by: Nicolas Dechesne
---
arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
index af2e075..6349f24 100644
--- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
@@ -41,6 +41,11 @@
};
};
+ /* OTG */
+ usb1_phy:phy@1250 {
+ status = "ok";
+ };
+
usb3_phy:phy@1252 {
status = "ok";
};
@@ -48,7 +53,16 @@
usb4_phy:phy@1253 {
status = "ok";
};
-
+
+ gadget1:gadget@1250 {
+ status = "ok";
+ };
+
+ /* OTG */
+ usb1: usb@1250 {
+ status = "ok";
+ };
+
usb3: usb@1252 {
status = "ok";
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/12] ARM: qcom: Add DT alias for serial port
From: Pramod Gurav
Define an alias for serial port present on ifc6410 which is used as
console.
Signed-off-by: Pramod Gurav
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 4
arch/arm/boot/dts/qcom-apq8064.dtsi| 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 3164197..7a6a076 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -5,6 +5,10 @@
model = "Qualcomm APQ8064/IFC6410";
compatible = "qcom,apq8064-ifc6410", "qcom,apq8064";
+ aliases {
+ serial0 =
+ };
+
soc {
pinctrl@80 {
i2c1_pins: i2c1 {
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 9c2e9b2..63edafc 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -232,7 +232,7 @@
#size-cells = <1>;
ranges;
- serial@1664 {
+ serial0: serial@1664 {
compatible = "qcom,msm-uartdm-v1.3",
"qcom,msm-uartdm";
reg = <0x1664 0x1000>,
<0x1660 0x1000>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/12] ARM: DT: apq8064: Add usb host support to CM QS-600
From: Nicolas Dechesne
This patch adds device tree nodes to support two usb hosts on Compulab QS600
board.
Signed-off-by: Nicolas Dechesne
---
arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
index 6e62f24..af2e075 100644
--- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
@@ -41,6 +41,22 @@
};
};
+ usb3_phy:phy@1252 {
+ status = "ok";
+ };
+
+ usb4_phy:phy@1253 {
+ status = "ok";
+ };
+
+ usb3: usb@1252 {
+ status = "ok";
+ };
+
+ usb4: usb@1253 {
+ status = "ok";
+ };
+
/* on board fixed 3.3v supply */
v3p3_pcieclk: v3p3-pcieclk {
compatible = "regulator-fixed";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/12] ARM: dts: apq8064: Add SATA controller support.
This patch adds AHCI based SATA controller support to APQ8064.
Tested on IFC6410 board.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 15 +
arch/arm/boot/dts/qcom-apq8064.dtsi| 35 ++
2 files changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 1723cdf..3164197 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -56,6 +56,12 @@
qcom,switch-mode-frequency = <480>;
};
+ pm8921_s4: pm8921-s4 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ qcom,switch-mode-frequency = <320>;
+ };
+
pm8921_l3: pm8921-l3 {
regulator-min-microvolt = <305>;
regulator-max-microvolt = <330>;
@@ -72,6 +78,15 @@
};
};
+ sata_phy0: sata-phy@1b40{
+ status = "okay";
+ };
+
+ sata0: sata@2900 {
+ status = "okay";
+ target-supply = <_s4>;
+ };
+
/* OTG */
usb1_phy: phy@1250 {
status = "okay";
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index c251c72..e65aff0 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -566,6 +566,41 @@
usb-phy = <_phy>;
};
+ sata_phy0: sata-phy@1b40{
+ compatible = "qcom,apq8064-sata-phy";
+ status = "disabled";
+ reg = <0x1b40 0x200>;
+ reg-names = "phy_mem";
+ clocks = < SATA_PHY_CFG_CLK>;
+ clock-names = "cfg";
+ #phy-cells = <0>;
+ };
+
+ sata0: sata@2900 {
+ compatible = "generic-ahci";
+ status = "disabled";
+ reg = <0x2900 0x180>;
+ interrupts = <0 209 0>;
+
+ clocks = < SFAB_SATA_S_H_CLK>,
+ < SATA_H_CLK>,
+ < SATA_A_CLK>,
+ < SATA_RXOOB_CLK>,
+ < SATA_PMALIVE_CLK>;
+ clock-names = "slave_iface",
+ "iface",
+ "bus",
+ "rxoob",
+ "core_pmalive";
+
+ assigned-clocks = < SATA_RXOOB_CLK>,
+ < SATA_PMALIVE_CLK>;
+ assigned-clock-rates= <1>, <1>;
+
+ phys= <_phy0>;
+ phy-names = "sata-phy";
+ };
+
/* Temporary fixed regulator */
vsdcc_fixed: vsdcc-regulator {
compatible = "regulator-fixed";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/12] ARM: DT: apq8064: add pci support in CM QS600
From: Nicolas Dechesne
This patch adds PCIE support to APQ8064, tested with Ethernet on Compulab QS600
board.
Signed-off-by: Nicolas Dechesne
---
arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
index 5d75666..6e62f24 100644
--- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
@@ -1,4 +1,5 @@
#include "qcom-apq8064-v2.0.dtsi"
+#include
/ {
model = "CompuLab CM-QS600";
@@ -40,6 +41,24 @@
};
};
+ /* on board fixed 3.3v supply */
+ v3p3_pcieclk: v3p3-pcieclk {
+ compatible = "regulator-fixed";
+ regulator-name = "PCIE V3P3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ pci@1b50 {
+ status = "ok";
+ pcie-clk-supply = <_pcieclk>;
+ avdd-supply = <_s3>;
+ vdd-supply = <_lvs6>;
+ qcom,external-phy-refclk;
+ reset-gpio = <_pinmux 27 GPIO_ACTIVE_LOW>;
+ };
+
amba {
/* eMMC */
sdcc1: sdcc@1240 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/12] ARM: dts: apq8064: Add USB OTG support
This patch adds USB OTG support on USB1 of APQ8064 SOC.
Tested on IFC6410 with ethernet gadget.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 22
arch/arm/boot/dts/qcom-apq8064.dtsi| 32 ++
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 40657a4..1723cdf 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -61,12 +61,25 @@
regulator-max-microvolt = <330>;
};
+ pm8921_l4: pm8921-l4 {
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <180>;
+ };
+
pm8921_l23: pm8921-l23 {
regulator-min-microvolt = <170>;
regulator-max-microvolt = <190>;
};
};
+ /* OTG */
+ usb1_phy: phy@1250 {
+ status = "okay";
+ vddcx-supply= <_s3>;
+ v3p3-supply = <_l3>;
+ v1p8-supply = <_l4>;
+ };
+
usb3_phy: phy@1252 {
status = "okay";
vddcx-supply= <_s3>;
@@ -81,6 +94,15 @@
v1p8-supply = <_l23>;
};
+ gadget1: gadget@1250 {
+ status = "okay";
+ };
+
+ /* OTG */
+ usb1: usb@1250 {
+ status = "okay";
+ };
+
usb3: usb@1252 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index e33eb03..c251c72 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -488,6 +488,21 @@
};
};
+ usb1_phy: phy@1250 {
+ compatible = "qcom,usb-otg-ci";
+ reg = <0x1250 0x400>;
+ interrupts = <0 100 IRQ_TYPE_NONE>;
+ status = "disabled";
+ dr_mode = "host";
+
+ clocks = < USB_HS1_XCVR_CLK>,
+ < USB_HS1_H_CLK>;
+ clock-names = "core", "iface";
+
+ resets = < USB_HS1_RESET>;
+ reset-names = "link";
+ };
+
usb3_phy: phy@1252 {
compatible = "qcom,usb-otg-ci";
reg = <0x1252 0x400>;
@@ -518,6 +533,23 @@
reset-names = "link";
};
+ gadget1: gadget@1250 {
+ compatible = "qcom,ci-hdrc";
+ reg = <0x1250 0x400>;
+ status = "disabled";
+ dr_mode = "peripheral";
+ interrupts = <0 100 IRQ_TYPE_NONE>;
+ usb-phy = <_phy>;
+ };
+
+ usb1: usb@1250 {
+ compatible = "qcom,ehci-host";
+ reg = <0x1250 0x400>;
+ interrupts = <0 100 IRQ_TYPE_NONE>;
+ status = "disabled";
+ usb-phy = <_phy>;
+ };
+
usb3: usb@1252 {
compatible = "qcom,ehci-host";
reg = <0x1252 0x400>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/12] ARM: dts: apq8064 dt patches.
Hi Kumar, Now that the rpm header file dependency is resolved, Could you queue these dt patches for rc2. Thanks, srini Nicolas Dechesne (3): ARM: DT: apq8064: add pci support in CM QS600 ARM: DT: apq8064: Add usb host support to CM QS-600 ARM: DT: apq8064: Add USB OTG support for CM QS-600 Pramod Gurav (1): ARM: qcom: Add DT alias for serial port Rob Clark (1): ARM: dts: APQ8064: Add MDP support Srinivas Kandagatla (7): ARM: dts: apq8064: add RPM regulators support ARM: dts: apq8064: Add usb host support. ARM: dts: apq8064: Add USB OTG support ARM: dts: apq8064: Add SATA controller support. ARM: dts: apq8064: Remove incorrect gsbi2 node. ARM: dts: Move i2c1 pinctrl to apq8064.dtsi ARM: dts: apq8064 add i2c3 node for panel. arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 49 +++ arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 98 +- arch/arm/boot/dts/qcom-apq8064.dtsi | 499 +++- 3 files changed, 629 insertions(+), 17 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/12] ARM: dts: apq8064: add RPM regulators support
This patch adds rpm node to apq8064 dt as rpm would be used by other
devices for regulator support. Also adds all the regulators in the rpm.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 241
1 file changed, 241 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index b3154c0..db5fc59 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -3,6 +3,7 @@
#include "skeleton.dtsi"
#include
#include
+#include
#include
#include
@@ -246,6 +247,246 @@
#reset-cells = <1>;
};
+ l2cc: clock-controller@2011000 {
+ compatible = "syscon";
+ reg = <0x2011000 0x1000>;
+ };
+
+ rpm@108000 {
+ compatible = "qcom,rpm-apq8064";
+ reg = <0x108000 0x1000>;
+ qcom,ipc= < 0x8 2>;
+
+ interrupts = <0 19 0>, <0 21 0>, <0 22 0>;
+ interrupt-names = "ack", "err", "wakeup";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Buck SMPS */
+ pm8921_s1: pm8921-s1 {
+ compatible = "qcom,rpm-pm8921-smps";
+ reg = ;
+ };
+
+ pm8921_s2: pm8921-s2 {
+ compatible = "qcom,rpm-pm8921-smps";
+ reg = ;
+ };
+
+ pm8921_s3: pm8921-s3 {
+ compatible = "qcom,rpm-pm8921-smps";
+ reg = ;
+ };
+
+ pm8921_s4: pm8921-s4 {
+ compatible = "qcom,rpm-pm8921-smps";
+ reg = ;
+ };
+
+ pm8921_s5: pm8921-s5 {
+ compatible = "qcom,rpm-pm8921-ftsmps";
+ reg = ;
+ };
+
+ pm8921_s6: pm8921-s6 {
+ compatible = "qcom,rpm-pm8921-ftsmps";
+ reg = ;
+ };
+
+ pm8921_s7: pm8921-s7 {
+ compatible = "qcom,rpm-pm8921-smps";
+ reg = ;
+ };
+
+ pm8921_s8: pm8921-s8 {
+ compatible = "qcom,rpm-pm8921-smps";
+ reg = ;
+ };
+
+ /* PMOS LDO */
+ pm8921_l1: pm8921-l1 {
+ compatible = "qcom,rpm-pm8921-nldo";
+ reg = ;
+ };
+
+ pm8921_l2: pm8921-l2 {
+ compatible = "qcom,rpm-pm8921-nldo";
+ reg = ;
+ };
+
+ pm8921_l3: pm8921-l3 {
+ compatible = "qcom,rpm-pm8921-pldo";
+ reg = ;
+ };
+
+ pm8921_l4: pm8921-l4 {
+ compatible = "qcom,rpm-pm8921-pldo";
+ reg = ;
+ };
+
+ pm8921_l5: pm8921-l5 {
+ compatible = "qcom,rpm-pm8921-pldo";
+ reg = ;
+ };
+
+ pm8921_l6: pm8921-l6 {
+ compatible = "qcom,rpm-pm8921-pldo";
+ reg = ;
+ };
+
+ pm8921_l7: pm8921-l7 {
+ compatible = "qcom,rpm-pm8921-pldo";
+ reg = ;
+ };
+
+ pm8921_l8: pm8921-l8 {
+ compatible = "qcom,rpm-pm8921-pldo";
+ reg = ;
+ };
+
+ pm8921_l9: pm8921-l9 {
+ compatible = "qcom,rpm-pm8921-pldo";
+ reg = ;
+ };
+
+ pm8921_l10: pm8921-l10 {
+ compatible = "qcom,rpm-pm8921-pldo";
+ reg
[PATCH 02/12] ARM: dts: apq8064: Add usb host support.
This patch adds device tree nodes to support two usb hosts on APQ8064
SOC.
Signed-off-by: Srinivas Kandagatla
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 40 +
arch/arm/boot/dts/qcom-apq8064.dtsi| 47 ++
2 files changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index e641001..40657a4 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -49,6 +49,46 @@
};
};
+ rpm@108000 {
+ pm8921_s3: pm8921-s3 {
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <140>;
+ qcom,switch-mode-frequency = <480>;
+ };
+
+ pm8921_l3: pm8921-l3 {
+ regulator-min-microvolt = <305>;
+ regulator-max-microvolt = <330>;
+ };
+
+ pm8921_l23: pm8921-l23 {
+ regulator-min-microvolt = <170>;
+ regulator-max-microvolt = <190>;
+ };
+ };
+
+ usb3_phy: phy@1252 {
+ status = "okay";
+ vddcx-supply= <_s3>;
+ v3p3-supply = <_l3>;
+ v1p8-supply = <_l23>;
+ };
+
+ usb4_phy: phy@1253 {
+ status = "okay";
+ vddcx-supply= <_s3>;
+ v3p3-supply = <_l3>;
+ v1p8-supply = <_l23>;
+ };
+
+ usb3: usb@1252 {
+ status = "okay";
+ };
+
+ usb4: usb@1253 {
+ status = "okay";
+ };
+
amba {
/* eMMC */
sdcc1: sdcc@1240 {
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index db5fc59..e33eb03 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -2,6 +2,7 @@
#include "skeleton.dtsi"
#include
+#include
#include
#include
#include
@@ -487,6 +488,52 @@
};
};
+ usb3_phy: phy@1252 {
+ compatible = "qcom,usb-otg-ci";
+ reg = <0x1252 0x400>;
+ interrupts = <0 188 IRQ_TYPE_NONE>;
+ status = "disabled";
+ dr_mode = "host";
+
+ clocks = < USB_HS3_XCVR_CLK>,
+ < USB_HS3_H_CLK>;
+ clock-names = "core", "iface";
+
+ resets = < USB_HS3_RESET>;
+ reset-names = "link";
+ };
+
+ usb4_phy: phy@1253 {
+ compatible = "qcom,usb-otg-ci";
+ reg = <0x1253 0x400>;
+ interrupts = <0 215 IRQ_TYPE_NONE>;
+ status = "disabled";
+ dr_mode = "host";
+
+ clocks = < USB_HS4_XCVR_CLK>,
+ < USB_HS4_H_CLK>;
+ clock-names = "core", "iface";
+
+ resets = < USB_HS4_RESET>;
+ reset-names = "link";
+ };
+
+ usb3: usb@1252 {
+ compatible = "qcom,ehci-host";
+ reg = <0x1252 0x400>;
+ interrupts = <0 188 IRQ_TYPE_NONE>;
+ status = "disabled";
+ usb-phy = <_phy>;
+ };
+
+ usb4: usb@1253 {
+ compatible = "qcom,ehci-host";
+ reg = <0x1253 0x400>;
+ interrupts = <0 215 IRQ_TYPE_NONE>;
+ status = "disabled";
+ usb-phy = <_phy>;
+ };
+
/* Temporary fixed regulator */
vsdcc_fixed: vsdcc-regulator {
compatible = "regulator-fixed";
--
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 0/2] powerpc/kvm: Enable running guests on RT Linux
On 20.02.2015 17:06, Sebastian Andrzej Siewior wrote: On 02/20/2015 03:57 PM, Paolo Bonzini wrote: On 20/02/2015 15:54, Sebastian Andrzej Siewior wrote: Usually you see "scheduling while atomic" on -RT and convert them to raw locks if it is appropriate. Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder not cause a DoS and large latencies in the host. I haven't seen an answer to my why question. Because if the conversation leads to large latencies in the host then it does not look right. Each host PIC has a rawlock and does mostly just mask/unmask and the raw lock makes sure the value written is not mixed up due to preemption. This hardly increase latencies because the "locked" path is very short. If this conversation leads to higher latencies then the locked path is too long and hardly suitable to become a rawlock. Yes, but large latencies just mean the code has to be rewritten (x86 doesn't anymore do event injection in an atomic regions for example). Until it is, using raw_spin_lock is correct. It does not sound like it. It sounds more like disabling interrupts to get things run faster and then limit it on a different corner to not blow up everything. Max latencies was decreased "Max latency (us) 7062" and that is why this is done? For 8 us and possible DoS in case there are too many cpus? The main reason for this patch was to enable KVM guests to run on RT hosts in certain scenarios, such as delivering external interrupts to the guest and the guest being SMP. The cyclictest measurements were just a "sanity check" to make sure the latencies don't get messed up too bad, albeit in a light scenario (guest with 1 VCPU), for a use case when the guest is not SMP and doesn't have any external interrupts delivered. This latter scenario works even without the kvm openpic being a raw_spinlock. Previous to this patch, KVM was indeed blowing up on guest_enter [1], and making the openpic lock a raw_spinlock fixes that, without causing too much cyclictest damage when the guest doesn't have many VCPUs. I had a discussion with Scott Wood a while ago regarding delivering external interrupts to the guest, and he mentioned that the correct solution was to rework the entire interrupt delivery mechanism into multiple lock domains, minimize the code on the EPR path and the locking involved. Until that can be achieved, converting the openpic lock to a raw_spinlock would be acceptable, as long as we keep the number of guest VCPUs small, so as to not cause big host latencies. [1] http://lxr.free-electrons.com/source/include/linux/kvm_host.h#L762 Best regards, Bogdan P. Paolo Sebastian -- 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/
Xen. How an error message should not look like
Hi!
This is a somewhat generic subject, so please forgive me. We are having some
very strange Xen problem in SLES11 SP3 (kernel 3.0.101-0.46-xen).
Eventually I found out that the message
kernel: [615432.648108] vbd vbd-7-51888: 2 creating vbd structure
is not a "progress" message (some vbd structure was created), but an error
message (the vbd structure was NOT created because of error "2").
So first the user has to recognize that the text actually is an error, then the
user has to find out what "2" means. Interestingly the most important
information is missing (block major an minor number of the device for
vbd_create()). When I did a little digging in the code I found this pearl of
code (/usr/src/linux/drivers/xen/blkback/xenbus.c):
switch (err) {
case -ENOMEDIUM:
if (!(be->blkif->vbd.type & (VDISK_CDROM | VDISK_REMOVABLE))) {
default:
xenbus_dev_fatal(dev, err, "creating vbd structure");
break;
}
/* fall through */
case 0:
err = xenvbd_sysfs_addif(dev);
if (err) {
vbd_free(>blkif->vbd);
xenbus_dev_fatal(dev, err, "creating sysfs entries");
}
break;
}
Itself vbd_create() does not log a message, and neither does
blkdev_get_by_dev() where the error comes from.
Regards,
Ulrich
P.S. Not subscribed to LKML, so please keep me on CC: to address me
--
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] thermal: intel Quark SoC X1000 DTS thermal driver
> -Original Message-
> From: Ong, Boon Leong
> Sent: Monday, February 23, 2015 9:39 AM
> Subject: RE: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver
>
> >Just to bring out for discussion, do you think we should put a "safety range"
> >for reporting out the critical trip temperature value (mean the value from
> >register minus 1 or 2 degree)?
> >
> >Just wondering if this is needed for the software to have the sufficient
> >shutdown time before the HW make a hard power cut off when the
> >critical trip point is reached.
>
> I assume that the suggestion is meant for the case where thermal register is
> not locked by BIOS. It is not a bad idea to have some protection against
> wrong configuration on critical trip point by user.
> Looking through the data-sheet in Quark, I could not find an recommended
> temperature. So, I propose that we use the same value set by BIOS today
> - 105C as the maximum.
What I mean here is that even the BIOS locks it and used the maximum value
105 °C for the critical trip point, should we -1 or -2 (104/103 °C) in this
driver
to let the system shut down before the actual trip point hit, in case the HW
performs a HW power cut off before the Linux kernel has enough time to
shut down properly?
>
> > > +static struct soc_sensor_entry *alloc_soc_dts(void)
> > > +{
> > > + struct soc_sensor_entry *aux_entry;
> > > + int err;
> > > + u32 out;
> > > + int wr_mask;
> > > +
> > > + aux_entry = kzalloc(sizeof(*aux_entry), GFP_KERNEL);
> >
> >Wondering is it possible to use the resource-managed functions (for e.g.
> >devm_kzalloc())? This could help the driver looks more neat and clean
> >where the resource-managed framework will help you take care all the
> >kfree().
> >
> >Understand that the flow here is to call the thermal_zone_device_register()
> >function after this aux_entry allocation.
> >
> >But thinking would it also working if change the flow to call
> >thermal_zone_device_register() function 1st to obtain the
> >thermal_zone_device
> >then later on perform devm_kzalloc() and assign it back to devdata.
> >
> Ok, it is worth exploring on this devm_kzalloc() for neatness.
> 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 1/3] clk: divider: fix calculation of maximal parent rate for a given divider
On Sat, Feb 21, 2015 at 11:40:23AM +0100, Uwe Kleine-König wrote: > The rate provided at the output of a clk-divider is calculated as: > > DIV_ROUND_UP(parent_rate, div) > > since commit b11d282dbea2 (clk: divider: fix rate calculation for > fractional rates). So to yield a rate not bigger than r parent_rate > must be <= r * div. > > The effect of choosing a parent rate that is too big as was done before > this patch results in wrongly ruling out good dividers. > > Note that this is not a complete fix as __clk_round_rate might return a > value >= its 2nd parameter. Also for dividers with > CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this > fixes the test case by Sascha Hauer that uses a chain of three dividers > under a fixed clock. > > Fixes: b11d282dbea2 (clk: divider: fix rate calculation for fractional rates) > Suggested-by: Sascha Hauer > Signed-off-by: Uwe Kleine-König Acked-by: Sascha Hauer This gives clk_round_rate/clk_set_rate on dividers a consistent behaviour. Also the testcases I posted seem to work fine. The only thing that might not be nice is that when a divider can only output fractional rates then the next higher integer value has to be used for clk_round_rate/clk_set_rate. A consumer should probably make no assumptions whether 333.333Hz is rounded up or down and use 334Hz to be sure anyway. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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/2] perf: Sample additional clock value
On 20/02/15 19:06, David Ahern wrote: > On 2/20/15 5:44 AM, Adrian Hunter wrote: >> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h >> index efe2d2d..9385140 100644 >> --- a/include/linux/perf_event.h >> +++ b/include/linux/perf_event.h >> @@ -655,7 +655,7 @@ extern void perf_pmu_migrate_context(struct pmu *pmu, >> int src_cpu, int dst_cpu); >> extern u64 perf_event_read_value(struct perf_event *event, >>u64 *enabled, u64 *running); >> - >> +u64 perf_sample_clock_pt(void); > > Core functions should not be arch specific. PT == x86. Actually it was one of the ARM guys that asked for it to be called "Processor Trace". It was "arch" in V1. http://marc.info/?l=linux-kernel=142436891806015 But it has been superseded completely by patches from Peter, so it is not going further 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 2/4] of: DT quirks infrastructure
On Fri, Feb 20, 2015 at 10:48:18AM -0800, Guenter Roeck wrote: > On Fri, Feb 20, 2015 at 01:09:58PM -0500, Peter Hurley wrote: > > Hi Guenter, > > > > On 02/20/2015 11:47 AM, Guenter Roeck wrote: > > > > [...] > > > > > I am open to hearing your suggestions for our use case, where the CPU > > > card with > > > the eeprom is manufactured separately from its carier cards. > > > > I think your use case may be more compelling than two flavors of Beaglebone > > (one of which is pretty much a dead stick), but it's also less clear what > > your > > design constraints are (not that I really want to know, 'cause I don't). > > > > But the logical extension of this is an N-way dtb that supports unrelated > > SOCs, > > and I think most would agree that's not an acceptable outcome. > > > With this logic you can pretty much refuse to accept anything new, anywhere. > Including everything old, for that matter. > > Food can be abused to poison people, therefore no one should be permitted to > distribute food. Houses can be abused to falsely imprison people, therefore > no one should live in houses. And don't even start talking about guns. > Everything can be abused, therefore we should not do anything. > > Discussions about possible abuse are for sure valid, and reducing the > potential > for abuse is a worthy goal, but not as argument to reject a solution for an > existing and real roblem outright. > > > My thought was that every design that can afford an EEPROM to probe can > > afford > > a bootloader to select the appropriate dtb, and can afford the extra space > > required for multiple dtbs. > > > There are many more use cases where this is simply not the case. Another one, > for example, is a system where the devicetree is loaded through u-boot using > tftp. In this case, u-boot would have some information about the hardware > to request the correct devicetree file, but it may not know about hardware > variants. > > Sure, one could solve that problem by making u-boot aware of such variants > and maintaining a large number of dtb files as you suggest. That means, > however, that there would be that need to maintain all those dtb files > just to address minor differences, and having modify every piece of the > system for each new variant. In essence you put a lot of burden on pretty > much everyone from software to manufacturing to testing, plus possibly > hardware, just for the purpose of rejecting a relatively simple solution > for the problem Pantelis' patch set is trying to address. > Other example that show how it becomes a mess. Tell me if we do that in a wrong way but I don't think. We have the following source files: - a dtsi file for the SoC family - a dtsi file for SoC variant enabling the devices available - a dtsi file for the CPU module describing components on this module: the ethernet phy, the nand flash, etc. - a dtsi file for the motherboard - several dtsi files for different kind of display modules - many dts file for the final board, it includes the SoC variant, the CPU module, the motherboard and one of the display module if needed. At the end we have something like this (from our github, not all these boards have been sent to the mainline) arch/arm/boot/dts/sama5d3.dtsi arch/arm/boot/dts/sama5d34ek_pda7.dts arch/arm/boot/dts/sama5d36ek_revc_pda7.dts arch/arm/boot/dts/sama5d31ek.dts arch/arm/boot/dts/sama5d34ek_revc.dts arch/arm/boot/dts/sama5d3xcm.dtsi arch/arm/boot/dts/sama5d31ek_pda4.dts arch/arm/boot/dts/sama5d34ek_revc_pda4.dts arch/arm/boot/dts/sama5d3xdm.dtsi arch/arm/boot/dts/sama5d31ek_pda7.dts arch/arm/boot/dts/sama5d34ek_revc_pda7.dts arch/arm/boot/dts/sama5d3xdm_pda4.dtsi arch/arm/boot/dts/sama5d31ek_revc.dts arch/arm/boot/dts/sama5d35ek.dts arch/arm/boot/dts/sama5d3xdm_pda7.dtsi arch/arm/boot/dts/sama5d31ek_revc_pda4.dts arch/arm/boot/dts/sama5d35ek_revc.dts arch/arm/boot/dts/sama5d3xek.its arch/arm/boot/dts/sama5d31ek_revc_pda7.dts arch/arm/boot/dts/sama5d36ek.dts arch/arm/boot/dts/sama5d3xek_pda4.its arch/arm/boot/dts/sama5d33ek.dts arch/arm/boot/dts/sama5d36ek_cmp.dts arch/arm/boot/dts/sama5d3xek_pda7.its arch/arm/boot/dts/sama5d33ek_pda4.dts arch/arm/boot/dts/sama5d36ek_cmp_pins_sleep.dtsi arch/arm/boot/dts/sama5d3xmb.dtsi arch/arm/boot/dts/sama5d33ek_pda7.dts arch/arm/boot/dts/sama5d36ek_hdmi.dts arch/arm/boot/dts/sama5d3xmb_revc.dtsi arch/arm/boot/dts/sama5d33ek_revc.dts arch/arm/boot/dts/sama5d36ek_pda4.dts arch/arm/boot/dts/sama5d3xmb_revc_isi.dtsi arch/arm/boot/dts/sama5d33ek_revc_pda4.dts arch/arm/boot/dts/sama5d36ek_pda7.dts arch/arm/boot/dts/sama5d4.dtsi arch/arm/boot/dts/sama5d33ek_revc_pda7.dts arch/arm/boot/dts/sama5d36ek_revc.dts arch/arm/boot/dts/sama5d4ek.dts arch/arm/boot/dts/sama5d34ek.dts arch/arm/boot/dts/sama5d36ek_revc_cmp.dts arch/arm/boot/dts/sama5d4ek_hdmi.dts arch/arm/boot/dts/sama5d34ek_pda4.dts arch/arm/boot/dts/sama5d36ek_revc_pda4.dts arch/arm/boot/dts/sama5d4ek_pin_sleep_state.dtsi > Ultimately, no matter what the kernel
Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
On 20.02.2015 16:54, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
Thomas, what is the usual approach for patches like this? Do you take
them into your rt tree or should they get integrated to upstream?
Patch 1 is definitely suitable for upstream, that's the reason why we
have raw_spin_lock vs. raw_spin_unlock.
raw_spin_lock were introduced in c2f21ce2e31286a0a32 ("locking:
Implement new raw_spinlock). They are used in context which runs with
IRQs off - especially on -RT. This includes usually interrupt
controllers and related core-code pieces.
Usually you see "scheduling while atomic" on -RT and convert them to
raw locks if it is appropriate.
Bogdan wrote in 2/2 that he needs to limit the number of CPUs in oder
not cause a DoS and large latencies in the host. I haven't seen an
answer to my why question. Because if the conversation leads to
large latencies in the host then it does not look right.
What I did notice were bad cyclictest results, when run in a guest with
24 VCPUs. There were 24 netperf flows running in the guest. The max
cyclictest latencies got up to 15ms in the guest, however I haven't
captured any host side information related to preemptirqs off statistics.
What I was planning to do in the past days was to rerun the test and
come up with the host preemptirqs off disabled statistics (mainly the
max latency), so I could have a more reliable argument. I haven't had
the time nor the setup to do that yet, and will come back with this as
soon as I have them available.
Each host PIC has a rawlock and does mostly just mask/unmask and the
raw lock makes sure the value written is not mixed up due to
preemption.
This hardly increase latencies because the "locked" path is very short.
If this conversation leads to higher latencies then the locked path is
too long and hardly suitable to become a rawlock.
From my understanding, the kvm openpic emulation code does more than
just that - it requires to be atomic with interrupt delivery. This might
mean the bad cyclictest max latencies visible from the guest side
(15ms), may also have a correspondent to how much time that raw spinlock
is taken, leading to an unresponsive host.
Best regards,
Bogdan P.
Paolo
Sebastian
--
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 0/3] clk: divider: three exactness fixes (and a rant)
On Sat, Feb 21, 2015 at 11:40:22AM +0100, Uwe Kleine-König wrote: > Hello, > > TLDR: only apply patch 1 and rip of CLK_DIVIDER_ROUND_CLOSEST. > > I stared at clk-divider.c for some time now given Sascha's failing test > case. I found a fix for the failure (which happens to be what Sascha > suspected). > > The other two patches fix problems only present when handling dividers > that have CLK_DIVIDER_ROUND_CLOSEST set. Note that these are still > heavily broken however. So having a 4bit-divider and a parent clk of > 1 (as in Sascha's test case) requesting > > clk_set_rate(clk, 666) > > sets the rate to 625 (div=15) instead of 667 (div=16). The reason is the > choice of parent_rate in clk_divider_bestdiv's loop is wrong for > CLK_DIVIDER_ROUND_CLOSEST (with and without patch 1). A fix here is > non-trivial and for sure more than one rate must be tested here. This is > complicated by the fact that clk_round_rate might return a value bigger > than the requested rate which convinces me (once more) that it's a bad > idea to allow that. Even if this was fixed for .round_rate, > clk_divider_set_rate is still broken because it also uses > > div = DIV_ROUND_UP(parent_rate, rate); > > to calculate the (pretended) best divider to get near rate. > > Note this makes at least two reasons to remove support for > CLK_DIVIDER_ROUND_CLOSEST! > > Instead I'd favour creating a function > > clk_round_rate_nearest Full ack. It's a clock consumer who wants to decide the rounding strategy, not the clock itself and for sure not a specific entity of the clock tree. CLK_DIVIDER_ROUND_CLOSEST should be dropped. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 - 15/27] cris: Remove use of seq_printf return value
On Sun, Feb 22, 2015 at 05:00:30AM +0100, Joe Perches wrote:
> The seq_printf return value, because it's frequently misused,
> will eventually be converted to void.
>
> See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to
> seq_has_overflowed() and make public")
> Signed-off-by: Joe Perches
Acked-by: Jesper Nilsson
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.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-v3.19-9526-ga135c717d5cd + vfs.git] blk_update_request: I/O error, dev loop0
On Mon, Feb 23, 2015 at 5:33 AM, Jens Axboe wrote: > On 02/22/2015 12:12 PM, Sedat Dilek wrote: >> >> On Sun, Feb 22, 2015 at 9:04 PM, Jens Axboe wrote: >>> >>> On Feb 22, 2015, at 12:02 PM, Sedat Dilek wrote: > On Sun, Feb 22, 2015 at 5:06 PM, Jens Axboe wrote: >> >> On 02/22/2015 06:09 AM, Sedat Dilek wrote: >> >> Hi, >> >> when testing Linux-next (upcoming v3.20) I fell over similiar messages >> when running fio here. >> >> This commit helped which is now upstream [1]... >> >> commit 9f9ee1f2b2f94f19437ae2def7c0d6636d7fe02e >> "block: Quiesce zeroout wrapper" >> >> --- dmesg_3.19.0-9526.2-iniza-small_before-fio-2.2.5.txt >> 2015-02-22 14:09:35.411824880 +0100 >> +++ dmesg_3.19.0-9526.2-iniza-small_after-fio-2.2.5.txt 2015-02-22 >> 14:10:25.327824500 +0100 >> @@ -853,3 +853,25 @@ >> [ 428.226000] Adding 36k swap on swapfile29. Priority:-29 >> extents:1 >> across:36k FS >> [ 469.339645] Process 7691(waitpid02) has RLIMIT_CORE set to 1 >> [ 469.339650] Aborting core >> +[ 1877.189057] fio-testcase.sh (10238): drop_caches: 3 >> +[ 1882.250174] blk_update_request: I/O error, dev loop0, sector >> 2883712 >> +[ 1882.807993] blk_update_request: I/O error, dev loop0, sector >> 32460632 >> +[ 1884.655458] blk_update_request: I/O error, dev loop0, sector >> 16869712 >> +[ 1884.656896] blk_update_request: I/O error, dev loop0, sector >> 16854368 >> +[ 1884.659316] blk_update_request: I/O error, dev loop0, sector >> 16855008 >> +[ 1884.660834] blk_update_request: I/O error, dev loop0, sector >> 16869792 >> +[ 1884.661780] blk_update_request: I/O error, dev loop0, sector >> 16854848 >> +[ 1884.663282] blk_update_request: I/O error, dev loop0, sector >> 16855432 >> +[ 1884.664775] blk_update_request: I/O error, dev loop0, sector >> 16859808 >> +[ 1884.671472] blk_update_request: I/O error, dev loop0, sector >> 16866400 >> +[ 1892.239383] blk_update_request: 20 callbacks suppressed >> +[ 1892.239389] blk_update_request: I/O error, dev loop0, sector >> 7872768 >> +[ 1897.221576] blk_update_request: I/O error, dev loop0, sector >> 23331008 >> +[ 1898.299271] blk_update_request: I/O error, dev loop0, sector >> 25690688 >> +[ 1898.444161] blk_update_request: I/O error, dev loop0, sector >> 25726496 >> +[ 1898.445946] blk_update_request: I/O error, dev loop0, sector >> 25690832 >> +[ 1898.448185] blk_update_request: I/O error, dev loop0, sector >> 25692312 >> +[ 1898.449321] blk_update_request: I/O error, dev loop0, sector >> 25704840 >> +[ 1898.450314] blk_update_request: I/O error, dev loop0, sector >> 25710392 >> +[ 1898.451351] blk_update_request: I/O error, dev loop0, sector >> 25726080 >> +[ 1898.452348] blk_update_request: I/O error, dev loop0, sector >> 25737608 >> >> FYI: This is with Linux-v3.19-9526-ga135c717d5cd plus >> vfs.git#for-linus. > > > > This really has nothing to do with commit 9f9ee1f2b2f, other than that > they > both have some block related messages. The above is normal IO errors on > the > device, we expect to see messages related to that. The question is > mostly > why you are seeing those. What are you running on the device? > > And is this a regression since 3.19? OK, I mixed it up - I was on a hurry travelling back home. This is (still) a Ubuntu/precise AMD64 WUBI system where I did the block-loopmq testing. It seems to be a regression since 3.19 (see my attached tarball). >>> >>> >>> All I get is an attached file for a checksum, doesn't really help me in >>> any way. >>> >> >> It's 2 files, I have unpacked it and attached all single files. > > > BTW, the other messages are the same (just the sha attached). And like Ming > said, I don't see the warnings in the files you attached. So lets back it up > a bit. A good bug report contains: > > 1) What was being run (kernel version) > 2) What was run (fio command, in this case). This includes setup of how to > reproduce. > 3) Result > 4) Expected result > > Otherwise it ends up being way too obtuse, people have to guess at what you > (the reporter) thinks is wrong, in the cases where this isn't immediately > obvious. > > So lets get back to basics on this one. What, in your opinion, has regressed > in 4.0-rc1 compared to 3.19? And what is the exact test case? > As Linux v4.0-rc1 was released I will send you a new bug-report. - Sedat - -- 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: openrisc: Dead or alive? openrisc.net has no dns entry
On Sat, Feb 21, 2015 at 07:18:27PM -0800, Joe Perches wrote: > Hello Stefan, Jonas: > > I sent a patch for openrisc use of seq_printf > to li...@lists.openrisc.net that bounced. > > https://lkml.org/lkml/2015/2/21/228 > > There's no DNS entry for openrisc.net. > > I notice Stefan has an active openrisc kernel at > https://github.com/skristiansson/linux > > But, the canonical MAINTAINERS file for linux has: > > OPENRISC ARCHITECTURE > M:Jonas Bonn > W:http://openrisc.net > L:li...@lists.openrisc.net (moderated for non-subscribers) > S:Maintained > T:git git://openrisc.net/~jonas/linux > F:arch/openrisc/ > > Is openrisc or Jonas still active? > > Should this entry be updated or deleted? > Me and Jonas had an off-list discussion about this, and due to that he currently have a hard time to find enough time to properly maintain the openrisc kernel port, I have agreed to step in as a co-maintainer to help him out for the time being. Stefan -- 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/
GARP Issue
Hi All, I am working custom platform based on x86_64 running 3.10 kernel, Recently I found an issue related to GARP. It seems like no GARP packets are being sent out when an Interface is made up. But I also noticed that only when I use "arping" tool only then it sends out any GARP packet. I also try setting the net variable "arp_notify" then I see the arp_send() function is being called after that I am unable to track further. Could you please help me, what could be issue, Is it a valid expectation that during interface up the linux kernel should send out GARP packet? If so, am I missing any kernel configuration related to it? Thanks in Advance. Regards, A.Mydeen. -- 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/4] of: DT quirks infrastructure
Hi Rob, On Fri, Feb 20, 2015 at 11:30:12AM -0600, Rob Herring wrote: > On Fri, Feb 20, 2015 at 8:35 AM, Ludovic Desroches > wrote: > > On Fri, Feb 20, 2015 at 09:21:38AM -0500, Peter Hurley wrote: > >> On 02/19/2015 12:38 PM, Pantelis Antoniou wrote: > >> > > >> >> On Feb 19, 2015, at 19:30 , Frank Rowand wrote: > >> >> > >> >> On 2/19/2015 9:00 AM, Pantelis Antoniou wrote: > >> >>> Hi Frank, > > [...] > > >> >>> This is one of those things that the kernel community doesn’t > >> >>> understand which makes people > >> >>> who push product quite mad. > >> >>> > >> >>> Engineering a product is not only about meeting customer spec, in > >> >>> order to turn a profit > >> >>> the whole endeavor must be engineered as well for manufacturability. > >> >>> > >> >>> Yes, you can always manually install files in the bootloader. For 1 > >> >>> board no problem. > >> >>> For 10 doable. For 100 I guess you can hire an extra guy. For 1 > >> >>> million? Guess what, > >> >>> instead of turning a profit you’re losing money if you only have a few > >> >>> cents of profit > >> >>> per unit. > >> >> > >> >> I'm not installing physical components manually. Why would I be > >> >> installing software > >> >> manually? (rhetorical question) > >> >> > >> > > >> > Because on high volume product runs the flash comes preprogrammed and is > >> > soldered as is. > >> > > >> > Having a single binary to flash to every revision of the board makes > >> > logistics considerably > >> > easier. > >> > > >> > Having to boot and tweak the bootloader settings to select the correct > >> > dtb (even if it’s present > >> > on the flash medium) takes time and is error-prone. > >> > > >> > Factory time == money, errors == money. > >> > > >> >>> > >> >>> No knobs to tweak means no knobs to break. And a broken knob can have > >> >>> pretty bad consequences > >> >>> for a few million units. > >> >> > >> >> And you produce a few million units before testing that the first one > >> >> off the line works? > >> >> > >> > > >> > The first one off the line works. The rest will get some burn in and > >> > functional testing if you’re > >> > lucky. In many cases where the product is very cheap it might make > >> > financial sense to just ship > >> > as is and deal with recalls, if you’re reasonably happy after a little > >> > bit of statistical sampling. > >> > > >> > Hardware is hard :) > >> > >> I'm failing to see how this series improves your manufacturing process at > >> all. > >> > >> 1. Won't you have to provide the factory with different eeprom images for > >> the > >>White and Black? You _trust_ them to get that right, or more likely, > >> you > >>have process control procedures in place so that you don't get 1 > >> million Blacks > >>flashed with the White eeprom image. > >> > >> 2. The White and Black use different memory technology so it's not as if > >> the > >>eMMC from the Black will end up on the White SMT line (or vice versa). > >> > >> 3 For that matter, why wouldn't you worry that all the microSD cards > >> intended > >>for the White were accidentally assembled with the first 50,000 Blacks; > >> at > >>that point you're losing a lot more than a few cents of profit. And > >> that has > >>nothing to do with what image you provided. > >> > > > > As you said, we can imagine many reasons to have a failure during the > > production, having several DTB files will increase the risk. > > Then package them as a single file. You can even use DT to do that. > See u-boot FIT image. > > Rob It is acualyy what we did but we are not happy with this solution because as said previously we rely on U-Boot and on dts/dtsi side we have too many files. Regards Ludovic -- 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] cxl: Remove useless precision specifiers
On Mon, 2015-02-23 at 14:40 +1100, Ian Munsie wrote: > Excerpts from Rasmus Villemoes's message of 2015-02-21 00:26:22 +1100: > > C99 says that a precision given as simply '.' with no following digits > > or * should be interpreted as 0. The kernel's printf implementation, > > however, treats this case as if the precision was omitted. C99 also > > says that if both the precision and value are 0, no digits should be > > printed. Even if the kernel followed C99 to the letter, I don't think > > that would be particularly useful in these cases, so just remove the > > precision specifiers. > > Nice catch Rasmus, but I think a better patch would be one that adds the > missing precision (%.16llx). The kernel much more commonly uses %016llx $ git grep "%016llx" | grep -v staging | wc -l 792 $ git grep "%\.16llx" | grep -v staging | wc -l 36 -- 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: live kernel upgrades (was: live kernel patching design)
On Sun, Feb 22, 2015 at 03:01:48PM -0800, Andrew Morton wrote: > On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina wrote: > > > But if you ask the folks who are hungry for live bug patching, they > > wouldn't care. > > > > You mentioned "10 seconds", that's more or less equal to infinity to them. > > 10 seconds outage is unacceptable, but we're running our service on a > single machine with no failover. Who is doing this?? This is the most common argument that's raised when live patching is discussed. "Why do need live patching when we have redundancy?" People who are asking for live patching typically do have failover in place, but prefer not to have to use it when they don't have to. In many cases, the failover just can't be made transparent to the outside world and there is a short outage. Examples would be legacy applications which can't run in an active-active cluster and need to be restarted on failover. Or trading systems, where the calculations must be strictly serialized and response times are counted in tens of microseconds. Another usecase is large HPC clusters, where all nodes have to run carefully synchronized. Once one gets behind in a calculation cycle, others have to wait for the results and the efficiency of the whole cluster goes down. There are people who run realtime on them for that reason. Dumping all data and restarting the HPC cluster takes a lot of time and many nodes (out of tens of thousands) may not come back up, making the restore from media difficult. Doing a rolling upgrade causes the nodes one by one stall by 10+ seconds, which times 10k is a long time, too. And even the case where you have a perfect setup with everything redundant and with instant failover does benefit from live patching. Since you have to plan for failure, you have to plan for failure while patching, too. With live patching you need 2 servers minimum (or N+1), without you need 3 (or N+2), as one will be offline while during the upgrade process. 10 seconds of outage may be acceptable in a disaster scenario. Not necessarily for a regular update scenario. The value of live patching is in near zero disruption. -- Vojtech Pavlik Director 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/
Re: [PATCH] Staging: fbtft: fix whitespace errors
From: Matteo Semenzato
This patch fixes the following errors:
ERROR: space required after that ','
ERROR: trailing whitespace
Signed-off-by: Matteo Semenzato
---
drivers/staging/fbtft/fb_st7735r.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/fbtft/fb_st7735r.c
b/drivers/staging/fbtft/fb_st7735r.c
index b63aa38..70293d8 100644
--- a/drivers/staging/fbtft/fb_st7735r.c
+++ b/drivers/staging/fbtft/fb_st7735r.c
@@ -31,20 +31,20 @@
static int default_init_sequence[] = {
/* SWRESET - Software reset */
- -1, 0x01,
+ -1, 0x01,
-2, 150, /* delay */
/* SLPOUT - Sleep out & booster on */
- -1, 0x11,
+ -1, 0x11,
-2, 500, /* delay */
/* FRMCTR1 - frame rate control: normal mode
frame rate = fosc / (1 x 2 + 40) * (LINE + 2C + 2D) */
- -1, 0xB1, 0x01, 0x2C, 0x2D,
+ -1, 0xB1, 0x01, 0x2C, 0x2D,
/* FRMCTR2 - frame rate control: idle mode
frame rate = fosc / (1 x 2 + 40) * (LINE + 2C + 2D) */
- -1, 0xB2, 0x01, 0x2C, 0x2D,
+ -1, 0xB2, 0x01, 0x2C, 0x2D,
/* FRMCTR3 - frame rate control - partial mode
dot inversion mode, line inversion mode */
@@ -68,7 +68,7 @@ static int default_init_sequence[] = {
/* PWCTR4 - Power Control
BCLK/2, Opamp current small & Medium low */
- -1, 0xC3,0x8A,0x2A,
+ -1, 0xC3, 0x8A, 0x2A,
/* PWCTR5 - Power Control */
-1, 0xC4, 0x8A, 0xEE,
@@ -91,7 +91,7 @@ static int default_init_sequence[] = {
-2, 10, /* delay */
/* end marker */
- -3
+ -3
};
static void set_addr_win(struct fbtft_par *par, int xs, int ys, int xe, int ye)
@@ -148,21 +148,21 @@ static int set_var(struct fbtft_par *par)
#define CURVE(num, idx) curves[num*par->gamma.num_values + idx]
static int set_gamma(struct fbtft_par *par, unsigned long *curves)
{
- int i,j;
+ int i, j;
fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "%s()\n", __func__);
/* apply mask */
for (i = 0; i < par->gamma.num_curves; i++)
for (j = 0; j < par->gamma.num_values; j++)
- CURVE(i,j) &= 0b11;
+ CURVE(i, j) &= 0b11;
for (i = 0; i < par->gamma.num_curves; i++)
write_reg(par, 0xE0 + i,
CURVE(i, 0), CURVE(i, 1), CURVE(i, 2), CURVE(i, 3),
CURVE(i, 4), CURVE(i, 5), CURVE(i, 6), CURVE(i, 7),
CURVE(i, 8), CURVE(i, 9), CURVE(i, 10), CURVE(i, 11),
- CURVE(i, 12), CURVE(i, 13), CURVE(i, 14), CURVE(i,15));
+ CURVE(i, 12), CURVE(i, 13), CURVE(i, 14), CURVE(i, 15));
return 0;
}
--
2.3.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: Re: [perf/core PATCH v4 2/2] perf buildid-cache: Add --purge FILE to remove all caches of FILE
(2015/02/21 4:07), Hemant Kumar wrote:
> Hi Masami,
>
> Just a small suggestion below.
>
> On 02/20/2015 03:11 PM, Masami Hiramatsu wrote:
>> [SNIP]
>> +
>> +struct strlist *build_id_cache__list_build_ids(const char *pathname)
>> +{
>> +struct strlist *list;
>> +char *dirname;
>> +DIR *dir;
>> +struct dirent *d;
>> +
>> +list = strlist__new(true, NULL);
>> +dirname = build_id_cache__dirname_from_path(pathname, false, false);
>> +if (!list || !dirname)
>> +goto error_free;
>> +
>> +/* List up all dirents */
>> +dir = opendir(dirname);
>> +if (!dir)
>> +goto error_free;
>> +while ((d = readdir(dir)) != NULL) {
>> +if (!strcmp(d->d_name, ".") || !strcmp(d->d_name, ".."))
>> +continue;
>> +strlist__add(list, d->d_name);
>> +}
>> +closedir(dir);
>> +
>> +free(dirname);
>> +return list;
>> +
>> +error_free:
>> +free(dirname);
>> +if (list)
>> +strlist__delete(list);
>
> Maybe we don't need the "if (list)" check here as strlist__delete
> already checks for this.
Ah, right!
Thanks!
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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: [perf/core PATCH v4 2/2] perf buildid-cache: Add --purge FILE to remove all caches of FILE
(2015/02/21 22:56), Namhyung Kim wrote:
> Hi Masami,
>
> On Fri, Feb 20, 2015 at 06:41:50PM +0900, Masami Hiramatsu wrote:
>> Add --purge FILE to remove all caches of FILE.
>> Since the current --remove FILE removes a cache which has
>> same build-id of given FILE. Since the command takes a
>> FILE path, it can confuse user who tries to remove cache
>> about FILE path.
>>
>> -
>> # ./perf buildid-cache -v --add ./perf
>> Adding 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
>> # (update the ./perf binary)
>> # ./perf buildid-cache -v --remove ./perf
>> Removing 305bbd1be68f66eca7e2d78db294653031edfa79 ./perf: FAIL
>> ./perf wasn't in the cache
>> -
>> Actually, the --remove's FAIL is not shown, it just silently fails.
>>
>> So, this patch adds --purge FILE action for such usecase.
>> perf buildid-cache --purge FILE removes all caches which
>> has same FILE path.
>> In other words, it removes all caches including old binaries.
>>
>> -
>> # ./perf buildid-cache -v --add ./perf
>> Adding 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
>> # (update the ./perf binary)
>> # ./perf buildid-cache -v --purge ./perf
>> Removing 133b7b5486d987a5ab5c3ebf4ea14941f45d4d4f ./perf: Ok
>> -
>>
>> BTW, if you want to purge all the caches, remove ~/.debug/* .
>>
>> Signed-off-by: Masami Hiramatsu
>
> I have a nitpick below - other than that both patches look good.
>
> Acked-by: Namhyung Kim
Thanks!
>
> Thanks,
> Namhyung
>
[...]
>> +static int build_id_cache__purge_path(const char *pathname)
>> +{
>> +struct strlist *list;
>> +struct str_node *pos;
>> +int err;
>> +
>> +list = build_id_cache__list_build_ids(pathname);
>> +if (!list)
>> +return 0;
>> +
>> +strlist__for_each(pos, list) {
>> +err = build_id_cache__remove_s(pos->s);
>> +if (verbose)
>> +pr_info("Removing %s %s: %s\n", pos->s, pathname,
>> +err ? "FAIL" : "Ok");
>
> You can simply use pr_debug() here. :)
Yes, but other operations already uses pr_info instead of pr_debug.
I thinks we'd better change them all at once.
Thank you,
>
> Thanks,
> Namhyung
>
>
>> +if (err)
>> +break;
>> +}
>> +strlist__delete(list);
>> +
>> +return err;
>> +}
>> +
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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/
[PATCH] kernel/sys.c: Fix UNAME26 for 4.0
Signed-off-by: Jon DeVree --- kernel/sys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sys.c b/kernel/sys.c index 667b2e6..0ffd403 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -1127,7 +1127,7 @@ static int override_release(char __user *release, size_t len) break; rest++; } - v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 40; + v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 60; copy = clamp_t(size_t, len, 1, sizeof(buf)); copy = scnprintf(buf, copy, "2.6.%u%s", v, rest); ret = copy_to_user(release, buf, copy + 1); -- 2.1.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] Staging: fbtft: fix whitespace errors
On Sun, Feb 22, 2015 at 08:38:50PM +0100, Matteo Semenzato wrote: > From: Matteo Semenzato > > This patch fixes the following errors: > ERROR: space required after that ',' > ERROR: trailing whitespace > > Signed-off-by Matteo Semenzato checkpatch complains - ERROR: Missing Signed-off-by: line(s) regards sudip > --- -- 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] clockevents: Add (missing) default case for switch blocks
On 20 February 2015 at 19:34, Ingo Molnar wrote:
>
> * Viresh Kumar wrote:
>> Unused. Initially all clockevent devices are supposed to
>> be in this mode but later if another device replaces an
>> existing one, the existing one is put into this mode.
>
> I'd suggest to rename it to MODE_INIT - at first glance it
> gave me the impression that it's some sort of API
> placeholder - i.e. an unused flag or so.
Sorry, if I wasn't able to clarify this earlier. The impression you got
at first glance is correct. And it should be UNUSED only instead of
INIT. Its not about if the the device is initialized or not, but if it is used
or not. And that's why there is no callback for this in the new per-mode
callbacks.
> Also, I'd suggest to rename all 'modes' to true state
> machine naming: STATE_INITIALIZED, STATE_SHUT_DOWN,
> STATE_PERIODIC, STATE_RESUMED, etc.: if these are enums for
I thought so initially and it looked like the diff will be huge as all the
variables for the enum, i.e. 'mode', need to be renamed to 'state'..
But, if you are okay with it then I would be happy to do that..
> states and not state transition names, see my later
> questions:
>
>> >> + CLOCK_EVT_DEV_MODE_SHUTDOWN,
>> >> + CLOCK_EVT_DEV_MODE_PERIODIC,
>> >> + CLOCK_EVT_DEV_MODE_ONESHOT,
>> >> + CLOCK_EVT_DEV_MODE_RESUME,
>> >
>> > What is 'resume' mode?
>>
>> Introduced with: 18de5bc4c1f1 ("clockevents: fix resume
>> logic") and is only called during system resume to resume
>> the clockevent devices before resuming the tick. Only few
>> implementations do meaningful stuff here.
>
> So is it a state that a clockevents device reaches, or a
> state transition? The two purposes seem to be mixed up in
> the nomenclature.
Where all other modes are states, 'resume' probably represents
transition. It is immediately followed by a transition to ONESHOT or
PERIODIC mode and so it is just a preliminary step before moving to
final states during resume. We *may* not need to keep this in the
states enum..
>> Its only important for NOHZ_FULL (IDLE ? Maybe). When we
>> decide that the tick (LOWRES) or hrtimer interrupt
>> (HIGHRES) isn't required for indefinite period of time
>> (i.e. no timers/hrtimers are present to serve), we skip
>> reprogramming the clockevent device. But its already
>> reprogrammed from the tick-handler and so will fire
>> atleast once again.
>
> So this new 'mode' appears to be a true state of the
> device?
Yes.
--
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] x86, fpu: Use eagerfpu by default on all CPUs
On Sun, Feb 22, 2015 at 5:45 PM, Rik van Riel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/22/2015 06:06 AM, Borislav Petkov wrote: >> On Sat, Feb 21, 2015 at 06:18:01PM -0800, Andy Lutomirski wrote: >>> That's true. The question is whether there are enough of them, >>> and whether twiddling TS is fast enough, that it's worth it. >> >> Yes, and let me make it clear what I'm trying to do here: I want to >> make sure that eager FPU handling (both allocation and switching - >> and no, I'm not confusing the concepts) *doesn't* *hurt* any >> relevant workload. If it does, then we'll stop wasting time right >> there. >> >> But(!), if the CR0.TS lazy dance turns out to be really slow and >> the eager handling doesn't bring a noticeable slowdown, in >> comparison, we should consider doing the eager thing by default. >> After running a lot more benchmarks, of course. >> >> Which brings me to the main reason why we're doing this: code >> simplification. If we switch to eager, we'll kill a lot of >> non-trivial code and the FPU handling in the kernel becomes dumb >> and nice again. > > Currently the FPU handling does something really dumb for > KVM VCPU threads. Specifically, every time we enter a > KVM guest, we save the userspace FPU state of the VCPU > thread, and every time we leave the KVM guest, we load > the userspace FPU state of the VCPU thread. > > This is done for a thread that hardly ever exits to > userspace, and generally just switches between kernel > and guest mode. > > The reason for this acrobatics is that at every > context switch time, the userspace FPU state is > saved & loaded. > > I am working on a patch series to avoid that needless > FPU save & restore, by moving the point at which the > user FPU state is loaded out to the point where we > return to userspace, in do_notify_resume. > > One implication of this is that in kernel mode, we > can no longer just assume that the user space FPU > state is always loaded, and we need to check for that > (like the lazy FPU code does today). I would really > like to keep that code around, for obvious reasons :) I like that stuff, except for the fact that it still has code that depends on whether we're in eager or lazy mode, even though eager is a little less eager with your patches. Ideally I'd like to see your patches applied *and* lazy mode removed. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] PM / sleep: add configurable delay for pm_test
When CONFIG_PM_DEBUG=y, we provide a sysfs file (/sys/power/pm_test) for
selecting one of a few suspend test modes, where rather than entering a
full suspend state, the kernel will perform some subset of suspend
steps, wait 5 seconds, and then resume back to normal operation.
This mode is useful for (among other things) observing the state of the
system just before entering a sleep mode, for debugging or analysis
purposes. However, a constant 5 second wait is not sufficient for some
sorts of analysis; for example, on an SoC, one might want to use
external tools to probe the power states of various on-chip controllers
or clocks.
This patch turns this 5 second delay into a configurable module
parameter, so users can determine how long to wait in this
pseudo-suspend state before resuming the system.
Example (wait 30 seconds);
# echo 30 > /sys/module/suspend/parameters/pm_test_delay
# echo core > /sys/power/pm_test
# time echo mem > /sys/power/state
...
[ 17.583625] suspend debug: Waiting for 30 second(s).
...
real 0m30.381s
user 0m0.017s
sys 0m0.080s
Signed-off-by: Brian Norris
Acked-by: Pavel Machek
Reviewed-by: Kevin Cernekee
Acked-by: Florian Fainelli
---
v3: - document in a few more places
v2: - make this a module param instead of an explicit sysfs file
- drop the for loop; mdelay() does the same loop internally
- decrease +36 lines of code and +2 lines of doc, to +6 lines of code and
+2 lines of doc
Documentation/kernel-parameters.txt| 7 +++
Documentation/power/basic-pm-debugging.txt | 10 ++
kernel/power/suspend.c | 13 +++--
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 176d4fe4f076..0b8a1fd0d08d 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3433,6 +3433,13 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
improve throughput, but will also increase the
amount of memory reserved for use by the client.
+ suspend.pm_test_delay=
+ [SUSPEND]
+ Sets the number of seconds to remain in a suspend test
+ mode before resuming the system (see
+ /sys/power/pm_test). Only available when CONFIG_PM_DEBUG
+ is set. Default value is 5.
+
swapaccount=[0|1]
[KNL] Enable accounting of swap in memory resource
controller if no parameter or 1 is given or disable
diff --git a/Documentation/power/basic-pm-debugging.txt
b/Documentation/power/basic-pm-debugging.txt
index edeecd447d23..b96098ccfe69 100644
--- a/Documentation/power/basic-pm-debugging.txt
+++ b/Documentation/power/basic-pm-debugging.txt
@@ -75,12 +75,14 @@ you should do the following:
# echo platform > /sys/power/disk
# echo disk > /sys/power/state
-Then, the kernel will try to freeze processes, suspend devices, wait 5 seconds,
-resume devices and thaw processes. If "platform" is written to
+Then, the kernel will try to freeze processes, suspend devices, wait a few
+seconds (5 by default, but configurable by the suspend.pm_test_delay module
+parameter), resume devices and thaw processes. If "platform" is written to
/sys/power/pm_test , then after suspending devices the kernel will additionally
invoke the global control methods (eg. ACPI global control methods) used to
-prepare the platform firmware for hibernation. Next, it will wait 5 seconds
and
-invoke the platform (eg. ACPI) global methods used to cancel hibernation etc.
+prepare the platform firmware for hibernation. Next, it will wait a
+configurable number of seconds and invoke the platform (eg. ACPI) global
+methods used to cancel hibernation etc.
Writing "none" to /sys/power/pm_test causes the kernel to switch to the normal
hibernation/suspend operations. Also, when open for reading,
/sys/power/pm_test
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index c347e3ce3a55..aee23dab0a55 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "power.h"
@@ -204,12 +205,20 @@ static bool platform_suspend_again(suspend_state_t state)
suspend_ops->suspend_again() : false;
}
+#ifdef CONFIG_PM_DEBUG
+static unsigned int pm_test_delay = 5;
+module_param(pm_test_delay, uint, 0644);
+MODULE_PARM_DESC(pm_test_delay,
+"Number of seconds to wait before resuming from suspend test");
+#endif
+
static int suspend_test(int level)
{
#ifdef CONFIG_PM_DEBUG
if (pm_test_level == level) {
- printk(KERN_INFO "suspend debug: Waiting for 5 seconds.\n");
- mdelay(5000);
+ printk(KERN_INFO "suspend debug: Waiting for %d second(s).\n",
+
Re: Linux 4.0-rc1 out..
Hi all, As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) I haven't done these for a while, so I haven't included a previous release for comparison. (No merge commits counted, next-20150209 was the last linux-next before the merge window opened.) Commits in v4.0-rc1 (relative to v3.19): 8950 Commits in next-20140804: 8279 Commits with the same SHA1:7492 Commits with the same patch_id: 452 (1) Commits with the same subject line: 70 (1) (1) not counting those in the lines above. So commits in -rc1 that were in next-20150209: 801489.5% Some breakdown of the list of extra commits (relative to next-20150209) in -rc1: Top ten first word of commit summary: 103 mips 79 staging 37 drm 32 lguest 25 ib 22 arm 19 rdma 19 input 19 alsa 18 sunrpc Top ten authors: 51 ru...@rustcorp.com.au 50 markos.chand...@imgtec.com 25 trond.mykleb...@primarydata.com 21 leonid.yegos...@imgtec.com 19 h...@lst.de 17 richard.a...@ericsson.com 16 abbo...@mev.co.uk 15 z...@redhat.com 15 a...@arndb.de 14 dhowe...@redhat.com Top ten commiters: 81 gre...@linuxfoundation.org 75 da...@davemloft.net 64 markos.chand...@imgtec.com 59 ru...@rustcorp.com.au 47 torva...@linux-foundation.org 43 rol...@purestorage.com 38 r...@linux-mips.org 31 trond.mykleb...@primarydata.com 26 mi...@kernel.org 26 idryo...@gmail.com There are also 265 commits in next-20150209 that didn't make it into v4.0-rc1. Top ten first word of commit summary: 25 rcu 24 arm 20 selftests 19 mm 11 arm-soc 6 documentation 5 tracing 5 staging 5 libceph 5 ceph Top ten authors: 36 a...@linux-foundation.org 34 paul...@linux.vnet.ibm.com 20 shua...@osg.samsung.com 11 o...@lixom.net 9 minc...@kernel.org 7 rost...@goodmis.org 6 z...@redhat.com 6 beh...@converseincode.com 5 tapaswenipat...@gmail.com 4 namjae.j...@samsung.com Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 102 s...@canb.auug.org.au 35 paul...@linux.vnet.ibm.com 21 shua...@osg.samsung.com 11 o...@lixom.net 10 idryo...@redhat.com 9 kg...@kernel.org 7 rost...@goodmis.org 7 beh...@converseincode.com 7 a...@arndb.de 4 tred...@nvidia.com Those commits by me are from the quilt series (mainly Andrew's mmotm tree). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpCexxxI_USZ.pgp Description: OpenPGP digital signature
Re: [V6,1/9] elf: Add new powerpc specifc core note sections
Uli, Sorry for the slow response. > Michael Neuling wrote on 28.01.2015 05:28:09: > > > Sorry, I'm rethinking this as we didn't consider user suspended > > transactions. > > > > It makes sense for normal transactions but for user suspended > > transactions the running values are the ones you want to modify since > > that is where you'll end up restarting from. The hardware will only > > abort/rollback once a tresume is encountered. > > OK, I see. I hadn't really looked into suspended transactions before ... > > > So we could do what you're talking about for normal transactions and > > then switch them for suspended transactions. But this just seems to be > > making the kernel interface overly complicated. > > Agreed. Given that there seems to be an inevitable difference in how > transactions are seen by the debugger between Power and z (there are > no suspended transactions on z), I guess it makes more sense to have > the interface naturally model the hardware register sets on Power, > and have GDB cope with the differences. > > > So I'm keen on just keeping it the way Anshuman has now and GDB has to > > understand the program flow better to know which ones it wants to > > modify. The kernel always provides the "normal" set as running and the > > new set as check pointed. GDB then has to check the MSR to work out > > what it wants to modify. > > So I'm thinking how this all would work out for the case of GDB wanting > to call an inferior function while the process is stopped within a > transaction (in either transactional or suspended state). Should this inferior function be run in the current mode of the processor? ie if the process is currently transactional and the transaction aborts, should we be able to see any global state change because of an inferior function being run in GDB? Also, if you modify the stack in suspend mode, that'll be persistent. So it's possible that you could corrupt your stack if you abort. For example, if your tbegin is inside a function (one or more deep) that returns (one or more times while transactional), you need make sure you don't touch the stack non-transactionally if you want to be able to abort and not corrupt your stack. I think what you're proposing with running the inferior function in suspend mode may end up corrupting the stack in this way. You'd need to be really careful to make sure the inferior function is run on the stack pointer of the checkpointed registers. We do something like this in the kernel when laying out a signal frame on the user stack when the user is transactional. We lay it out on the checkpointed stack pointer/r1. (The best way for users to avoid this problem is to use sigaltstack() but we can't rely on that). > (A) In suspended state, I guess GDB could modify the "normal" register > set and ask the kernel to continue. The kernel would then transfer > control to the inferior function entry point while still in suspended > state, and the inferior function would execute in suspended state until > it hits the GDB-placed breakpoint at the end. At this point, GDB would > reload the original values to the "normal" register set, and ask the > kernel to continue. The kernel would then transfer control to the > originally-interrupted piece of code in suspended state, which would > continue to execute until the tresume, at which point the transaction > would abort (due to TDOOMED). Right? I think so. > (B) In transactional state, GDB could modify the "checkpointed" register > set and ask the kernel to continue. The kernel would transfer control > to the originally-interrupted code in transactional state. At this > point, the transaction would immediately abort, and control would > transfer to the state specified in the checkpointed register set, > and the inferior function would now execute in non-transactional > state, until it hits the breakpoint. At this point, GDB would now > have to restore the original values of the *checkpointed* register > set into the *normal* register set (a bit weird from a GDB internals > perspective), and ask the kernel to continue. Execution would now > resume at the abort handler of the originally interrupted transaction. > (Hmm. Maybe GDB would also have to set cr0 or something?) OK, but do we want the inferior function to be run non-transactionally? Should it changes be seen after the transaction aborts? > Is it possible for GDB to change the state (transactional vs. > suspended) where the kernel ought to let the application continue in? > I guess via modifying the appropriate MSR bits via ptrace? Yes, you can change the MSR to change the TM mode. > If so, there would be other options to handle this: > > (A') In the transactional state, GDB could set the MSR to suspended, > and modify the "normal" register set. The inferior function would > execute in the suspended state as in (A) above. Upon return, GDB > would restore the normal register set (including restoring the MSR >
Re: [PATCH] cpufreq: exynos: allow build for !THERMAL or !CPU_THERMAL cases
On 20 February 2015 at 21:50, Bartlomiej Zolnierkiewicz
wrote:
> Allow driver build for !THERMAL or !CPU_THERMAL cases.
>
> The new dependency rule is the same as the one that CPUFREQ_DT
> option has (for cpufreq-dt driver which has the same issue with
> using of_cpufreq_cooling_register()).
>
> Cc: Kukjin Kim
> Cc: Arnd Bergmann
> Cc: Eduardo Valentin
> Cc: Lukasz Majewski
> Fixes: 8b2b4a4e5366 ("cpufreq: exynos: allow modular build")
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/cpufreq/Kconfig.arm | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 1b06fc4..f4df4af3 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -28,7 +28,8 @@ config ARM_VEXPRESS_SPC_CPUFREQ
> config ARM_EXYNOS_CPUFREQ
> tristate "SAMSUNG EXYNOS CPUfreq Driver"
> depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 ||
> SOC_EXYNOS5250
> - depends on THERMAL
> + # if CPU_THERMAL is on and THERMAL=m, ARM_EXYNOS_CPUFREQ cannot be =y:
> + depends on !CPU_THERMAL || THERMAL
> help
> This adds the CPUFreq driver for Samsung EXYNOS platforms.
> Supported SoC versions are:
Acked-by: Viresh Kumar
--
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-v3.19-9526-ga135c717d5cd + vfs.git] blk_update_request: I/O error, dev loop0
On 02/22/2015 12:12 PM, Sedat Dilek wrote: On Sun, Feb 22, 2015 at 9:04 PM, Jens Axboe wrote: On Feb 22, 2015, at 12:02 PM, Sedat Dilek wrote: On Sun, Feb 22, 2015 at 5:06 PM, Jens Axboe wrote: On 02/22/2015 06:09 AM, Sedat Dilek wrote: Hi, when testing Linux-next (upcoming v3.20) I fell over similiar messages when running fio here. This commit helped which is now upstream [1]... commit 9f9ee1f2b2f94f19437ae2def7c0d6636d7fe02e "block: Quiesce zeroout wrapper" --- dmesg_3.19.0-9526.2-iniza-small_before-fio-2.2.5.txt 2015-02-22 14:09:35.411824880 +0100 +++ dmesg_3.19.0-9526.2-iniza-small_after-fio-2.2.5.txt 2015-02-22 14:10:25.327824500 +0100 @@ -853,3 +853,25 @@ [ 428.226000] Adding 36k swap on swapfile29. Priority:-29 extents:1 across:36k FS [ 469.339645] Process 7691(waitpid02) has RLIMIT_CORE set to 1 [ 469.339650] Aborting core +[ 1877.189057] fio-testcase.sh (10238): drop_caches: 3 +[ 1882.250174] blk_update_request: I/O error, dev loop0, sector 2883712 +[ 1882.807993] blk_update_request: I/O error, dev loop0, sector 32460632 +[ 1884.655458] blk_update_request: I/O error, dev loop0, sector 16869712 +[ 1884.656896] blk_update_request: I/O error, dev loop0, sector 16854368 +[ 1884.659316] blk_update_request: I/O error, dev loop0, sector 16855008 +[ 1884.660834] blk_update_request: I/O error, dev loop0, sector 16869792 +[ 1884.661780] blk_update_request: I/O error, dev loop0, sector 16854848 +[ 1884.663282] blk_update_request: I/O error, dev loop0, sector 16855432 +[ 1884.664775] blk_update_request: I/O error, dev loop0, sector 16859808 +[ 1884.671472] blk_update_request: I/O error, dev loop0, sector 16866400 +[ 1892.239383] blk_update_request: 20 callbacks suppressed +[ 1892.239389] blk_update_request: I/O error, dev loop0, sector 7872768 +[ 1897.221576] blk_update_request: I/O error, dev loop0, sector 23331008 +[ 1898.299271] blk_update_request: I/O error, dev loop0, sector 25690688 +[ 1898.444161] blk_update_request: I/O error, dev loop0, sector 25726496 +[ 1898.445946] blk_update_request: I/O error, dev loop0, sector 25690832 +[ 1898.448185] blk_update_request: I/O error, dev loop0, sector 25692312 +[ 1898.449321] blk_update_request: I/O error, dev loop0, sector 25704840 +[ 1898.450314] blk_update_request: I/O error, dev loop0, sector 25710392 +[ 1898.451351] blk_update_request: I/O error, dev loop0, sector 25726080 +[ 1898.452348] blk_update_request: I/O error, dev loop0, sector 25737608 FYI: This is with Linux-v3.19-9526-ga135c717d5cd plus vfs.git#for-linus. This really has nothing to do with commit 9f9ee1f2b2f, other than that they both have some block related messages. The above is normal IO errors on the device, we expect to see messages related to that. The question is mostly why you are seeing those. What are you running on the device? And is this a regression since 3.19? OK, I mixed it up - I was on a hurry travelling back home. This is (still) a Ubuntu/precise AMD64 WUBI system where I did the block-loopmq testing. It seems to be a regression since 3.19 (see my attached tarball). All I get is an attached file for a checksum, doesn't really help me in any way. It's 2 files, I have unpacked it and attached all single files. BTW, the other messages are the same (just the sha attached). And like Ming said, I don't see the warnings in the files you attached. So lets back it up a bit. A good bug report contains: 1) What was being run (kernel version) 2) What was run (fio command, in this case). This includes setup of how to reproduce. 3) Result 4) Expected result Otherwise it ends up being way too obtuse, people have to guess at what you (the reporter) thinks is wrong, in the cases where this isn't immediately obvious. So lets get back to basics on this one. What, in your opinion, has regressed in 4.0-rc1 compared to 3.19? And what is the exact test case? -- Jens Axboe -- 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] dmaengine: qcom_bam_dma: Add support for BAM v1.7.0
Add register offset table entry for the newer (v1.7.0) version of the BAM IP
found on MSM8916. Update the DT bindings documentation.
Signed-off-by: Archit Taneja
---
Change in v2: Fix wrong execution environment multiplier for BAM_IRQ_SRCS_EE and
BAM_IRQ_SRCS_MSK_EE
.../devicetree/bindings/dma/qcom_bam_dma.txt | 1 +
drivers/dma/qcom_bam_dma.c | 30 ++
2 files changed, 31 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
index f8c3311..1c9d48e 100644
--- a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: must be one of the following:
* "qcom,bam-v1.4.0" for MSM8974, APQ8074 and APQ8084
* "qcom,bam-v1.3.0" for APQ8064, IPQ8064 and MSM8960
+ * "qcom,bam-v1.7.0" for MSM8916
- reg: Address range for DMA registers
- interrupts: Should contain the one interrupt shared by all channels
- #dma-cells: must be <1>, the cell in the dmas property of the client device
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
index d7a33b3..c737e6d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom_bam_dma.c
@@ -171,6 +171,35 @@ static const struct reg_offset_data bam_v1_4_reg_info[] = {
[BAM_P_FIFO_SIZES] = { 0x1820, 0x00, 0x1000, 0x00 },
};
+static const struct reg_offset_data bam_v1_7_reg_info[] = {
+ [BAM_CTRL] = { 0x0, 0x00, 0x00, 0x00 },
+ [BAM_REVISION] = { 0x01000, 0x00, 0x00, 0x00 },
+ [BAM_NUM_PIPES] = { 0x01008, 0x00, 0x00, 0x00 },
+ [BAM_DESC_CNT_TRSHLD] = { 0x8, 0x00, 0x00, 0x00 },
+ [BAM_IRQ_SRCS] = { 0x03010, 0x00, 0x00, 0x00 },
+ [BAM_IRQ_SRCS_MSK] = { 0x03014, 0x00, 0x00, 0x00 },
+ [BAM_IRQ_SRCS_UNMASKED] = { 0x03018, 0x00, 0x00, 0x00 },
+ [BAM_IRQ_STTS] = { 0x00014, 0x00, 0x00, 0x00 },
+ [BAM_IRQ_CLR] = { 0x00018, 0x00, 0x00, 0x00 },
+ [BAM_IRQ_EN]= { 0x0001C, 0x00, 0x00, 0x00 },
+ [BAM_CNFG_BITS] = { 0x0007C, 0x00, 0x00, 0x00 },
+ [BAM_IRQ_SRCS_EE] = { 0x03000, 0x00, 0x00, 0x1000 },
+ [BAM_IRQ_SRCS_MSK_EE] = { 0x03004, 0x00, 0x00, 0x1000 },
+ [BAM_P_CTRL]= { 0x13000, 0x1000, 0x00, 0x00 },
+ [BAM_P_RST] = { 0x13004, 0x1000, 0x00, 0x00 },
+ [BAM_P_HALT]= { 0x13008, 0x1000, 0x00, 0x00 },
+ [BAM_P_IRQ_STTS]= { 0x13010, 0x1000, 0x00, 0x00 },
+ [BAM_P_IRQ_CLR] = { 0x13014, 0x1000, 0x00, 0x00 },
+ [BAM_P_IRQ_EN] = { 0x13018, 0x1000, 0x00, 0x00 },
+ [BAM_P_EVNT_DEST_ADDR] = { 0x1382C, 0x00, 0x1000, 0x00 },
+ [BAM_P_EVNT_REG]= { 0x13818, 0x00, 0x1000, 0x00 },
+ [BAM_P_SW_OFSTS]= { 0x13800, 0x00, 0x1000, 0x00 },
+ [BAM_P_DATA_FIFO_ADDR] = { 0x13824, 0x00, 0x1000, 0x00 },
+ [BAM_P_DESC_FIFO_ADDR] = { 0x1381C, 0x00, 0x1000, 0x00 },
+ [BAM_P_EVNT_GEN_TRSHLD] = { 0x13828, 0x00, 0x1000, 0x00 },
+ [BAM_P_FIFO_SIZES] = { 0x13820, 0x00, 0x1000, 0x00 },
+};
+
/* BAM CTRL */
#define BAM_SW_RST BIT(0)
#define BAM_EN BIT(1)
@@ -1051,6 +1080,7 @@ static void bam_channel_init(struct bam_device *bdev,
struct bam_chan *bchan,
static const struct of_device_id bam_of_match[] = {
{ .compatible = "qcom,bam-v1.3.0", .data = _v1_3_reg_info },
{ .compatible = "qcom,bam-v1.4.0", .data = _v1_4_reg_info },
+ { .compatible = "qcom,bam-v1.7.0", .data = _v1_7_reg_info },
{}
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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] x86, boot: Allow 64bit EFI kernel to be loaded above 4G
Now could use kexec to place kernel/boot_params/cmd_line/initrd
above 4G, but that is with legacy interface with startup_64 directly.
This patch will allow 64bit EFI kernel to be loaded above 4G
and use EFI HANDOVER PROTOCOL to start the kernel.
Current 32bit code32_start is used for passing around load address,
so it will overflow when kernel is loaded abover 4G.
The patch mainly add ext_code32_start to take load address high 32bits.
After this patch, could use patched grub2-x86_64.efi to place
kernel/boot_params/cmd_line/initrd all above 4G and execute the kernel
above 4G.
bootlog like:
kernel: done [ linux 9.25MiB 100% 6.66MiB/s ]
params: [1618fc000,1618f]
cmdline: [1618fb000,1618fb7fe]
kernel: [15e00,161385fff]
initrd: [15bcbe000,15dbb]
initrd: 1 file done [ initrd.img 35.26MiB 100% 11.93MiB/s ]
early console in decompress_kernel
decompress_kernel:
input: [0x15fd0b3b4-0x16063c803], output: 0x15e00, heap:
[0x160645b00-0x16064daff]
Decompressing Linux... xz... Parsing ELF... done.
Booting the kernel.
[0.00] bootconsole [uart0] enabled
[0.00]real_mode_data : phys 0001618fc000
[0.00]real_mode_data : virt 8801618fc000
[0.00] Kernel Layout:
[0.00] .text: [0x15e00-0x15f08f72c]
[0.00] .rodata: [0x15f20-0x15fa44fff]
[0.00] .data: [0x15fc0-0x15fe545ff]
[0.00] .init: [0x15fe56000-0x16021afff]
[0.00].bss: [0x160229000-0x16135]
[0.00].brk: [0x16136-0x161385fff]
[0.00] memblock_reserve: [0x09f000-0x0f] flags 0x0
* BIOS reserved
...
[0.00] memblock_reserve: [0x015e00-0x016135] flags 0x0
TEXT DATA BSS
[0.00] memblock_reserve: [0x015bcbe000-0x015dff] flags 0x0
RAMDISK
-v2: add cast to avoid warning with 32bit, also update description for
ext_code32_start in boot.txt
Signed-off-by: Yinghai Lu
---
Documentation/x86/boot.txt| 19 +++
arch/x86/boot/compressed/eboot.c | 15 ++-
arch/x86/boot/compressed/head_64.S|7 ++-
arch/x86/boot/header.S|3 ++-
arch/x86/include/uapi/asm/bootparam.h |1 +
arch/x86/kernel/asm-offsets.c |1 +
6 files changed, 39 insertions(+), 7 deletions(-)
Index: linux-2.6/arch/x86/include/uapi/asm/bootparam.h
===
--- linux-2.6.orig/arch/x86/include/uapi/asm/bootparam.h
+++ linux-2.6/arch/x86/include/uapi/asm/bootparam.h
@@ -84,6 +84,7 @@ struct setup_header {
__u64 pref_address;
__u32 init_size;
__u32 handover_offset;
+ __u32 ext_code32_start;
} __attribute__((packed));
struct sys_desc_table {
Index: linux-2.6/arch/x86/kernel/asm-offsets.c
===
--- linux-2.6.orig/arch/x86/kernel/asm-offsets.c
+++ linux-2.6/arch/x86/kernel/asm-offsets.c
@@ -68,6 +68,7 @@ void common(void) {
OFFSET(BP_kernel_alignment, boot_params, hdr.kernel_alignment);
OFFSET(BP_pref_address, boot_params, hdr.pref_address);
OFFSET(BP_code32_start, boot_params, hdr.code32_start);
+ OFFSET(BP_ext_code32_start, boot_params, hdr.ext_code32_start);
BLANK();
DEFINE(PTREGS_SIZE, sizeof(struct pt_regs));
Index: linux-2.6/arch/x86/boot/compressed/head_64.S
===
--- linux-2.6.orig/arch/x86/boot/compressed/head_64.S
+++ linux-2.6/arch/x86/boot/compressed/head_64.S
@@ -264,6 +264,8 @@ ENTRY(efi_pe_entry)
mov %rax, %rsi
leaqstartup_32(%rip), %rax
movl%eax, BP_code32_start(%rsi)
+ shr $32, %rax
+ movl%eax, BP_ext_code32_start(%rsi)
jmp 2f /* Skip the relocation */
handover_entry:
@@ -287,7 +289,10 @@ fail:
hlt
jmp fail
2:
- movlBP_code32_start(%esi), %eax
+ movlBP_code32_start(%rsi), %eax
+ movlBP_ext_code32_start(%rsi), %ebx
+ shl $32, %rbx
+ orq %rbx, %rax
leaqpreferred_addr(%rax), %rax
jmp *%rax
Index: linux-2.6/arch/x86/boot/compressed/eboot.c
===
--- linux-2.6.orig/arch/x86/boot/compressed/eboot.c
+++ linux-2.6/arch/x86/boot/compressed/eboot.c
@@ -1388,6 +1388,7 @@ struct boot_params *efi_main(struct efi_
void *handle;
efi_system_table_t *_table;
bool is64;
+ unsigned long loaded_addr;
efi_early = c;
@@ -1429,9 +1430,12 @@ struct boot_params *efi_main(struct efi_
* If the kernel isn't already loaded at the preferred load
* address, relocate it.
*/
- if (hdr->pref_address != hdr->code32_start) {
- unsigned long bzimage_addr = hdr->code32_start;
-
Re: [PATCH] cxl: Remove useless precision specifiers
Excerpts from Rasmus Villemoes's message of 2015-02-21 00:26:22 +1100: > C99 says that a precision given as simply '.' with no following digits > or * should be interpreted as 0. The kernel's printf implementation, > however, treats this case as if the precision was omitted. C99 also > says that if both the precision and value are 0, no digits should be > printed. Even if the kernel followed C99 to the letter, I don't think > that would be particularly useful in these cases, so just remove the > precision specifiers. Nice catch Rasmus, but I think a better patch would be one that adds the missing precision (%.16llx). Cheers, -Ian -- 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 -tip] locking: Deprecate ACCESS_ONCE
With the new standardized functions, we can replace all
ACCESS_ONCE calls across relevant locking - this includes
lockref and seqlock while at it.
ACCESS_ONCE does not work reliably on non-scalar types.
For example gcc 4.6 and 4.7 might remove the volatile tag
for such accesses during the SRA (scalar replacement of
aggregates) step (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145)
Update the new calls regardless of if it is a scalar type,
this is cleaner than having three alternatives.
Signed-off-by: Davidlohr Bueso
---
include/linux/seqlock.h | 6 +++---
kernel/locking/mcs_spinlock.h | 6 +++---
kernel/locking/mutex.c| 8
kernel/locking/osq_lock.c | 14 +++---
kernel/locking/rwsem-xadd.c | 10 +-
lib/lockref.c | 2 +-
6 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index f5df8f6..5f68d0a 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -108,7 +108,7 @@ static inline unsigned __read_seqcount_begin(const
seqcount_t *s)
unsigned ret;
repeat:
- ret = ACCESS_ONCE(s->sequence);
+ ret = READ_ONCE(s->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
@@ -127,7 +127,7 @@ repeat:
*/
static inline unsigned raw_read_seqcount(const seqcount_t *s)
{
- unsigned ret = ACCESS_ONCE(s->sequence);
+ unsigned ret = READ_ONCE(s->sequence);
smp_rmb();
return ret;
}
@@ -179,7 +179,7 @@ static inline unsigned read_seqcount_begin(const seqcount_t
*s)
*/
static inline unsigned raw_seqcount_begin(const seqcount_t *s)
{
- unsigned ret = ACCESS_ONCE(s->sequence);
+ unsigned ret = READ_ONCE(s->sequence);
smp_rmb();
return ret & ~1;
}
diff --git a/kernel/locking/mcs_spinlock.h b/kernel/locking/mcs_spinlock.h
index d1fe2ba..75e114b 100644
--- a/kernel/locking/mcs_spinlock.h
+++ b/kernel/locking/mcs_spinlock.h
@@ -78,7 +78,7 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct
mcs_spinlock *node)
*/
return;
}
- ACCESS_ONCE(prev->next) = node;
+ WRITE_ONCE(prev->next, node);
/* Wait until the lock holder passes the lock down. */
arch_mcs_spin_lock_contended(>locked);
@@ -91,7 +91,7 @@ void mcs_spin_lock(struct mcs_spinlock **lock, struct
mcs_spinlock *node)
static inline
void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
{
- struct mcs_spinlock *next = ACCESS_ONCE(node->next);
+ struct mcs_spinlock *next = READ_ONCE(node->next);
if (likely(!next)) {
/*
@@ -100,7 +100,7 @@ void mcs_spin_unlock(struct mcs_spinlock **lock, struct
mcs_spinlock *node)
if (likely(cmpxchg(lock, node, NULL) == node))
return;
/* Wait until the next pointer is set */
- while (!(next = ACCESS_ONCE(node->next)))
+ while (!(next = READ_ONCE(node->next)))
cpu_relax_lowlatency();
}
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 43bf25e..16b2d3c 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -266,7 +266,7 @@ static inline int mutex_can_spin_on_owner(struct mutex
*lock)
return 0;
rcu_read_lock();
- owner = ACCESS_ONCE(lock->owner);
+ owner = READ_ONCE(lock->owner);
if (owner)
retval = owner->on_cpu;
rcu_read_unlock();
@@ -340,7 +340,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
* As such, when deadlock detection needs to be
* performed the optimistic spinning cannot be done.
*/
- if (ACCESS_ONCE(ww->ctx))
+ if (READ_ONCE(ww->ctx))
break;
}
@@ -348,7 +348,7 @@ static bool mutex_optimistic_spin(struct mutex *lock,
* If there's an owner, wait for it to either
* release the lock or go to sleep.
*/
- owner = ACCESS_ONCE(lock->owner);
+ owner = READ_ONCE(lock->owner);
if (owner && !mutex_spin_on_owner(lock, owner))
break;
@@ -487,7 +487,7 @@ static inline int __sched
__ww_mutex_lock_check_stamp(struct mutex *lock, struct ww_acquire_ctx *ctx)
{
struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
- struct ww_acquire_ctx *hold_ctx = ACCESS_ONCE(ww->ctx);
+ struct ww_acquire_ctx *hold_ctx = READ_ONCE(ww->ctx);
if (!hold_ctx)
return 0;
diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index c112d00..dc85ee2 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -98,7 +98,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
linux-next: Tree for Feb 23
Hi all, Please do not add any material destined for v3.21 to your linux-next included trees until after v3.20-rc1 has been released. OK, so that was interesting :-) v4.0-rc1 is out, so go crazy ... Changes since 20150222: *crickets* Non-merge commits (relative to Linus' tree): 829 527 files changed, 9529 insertions(+), 9872 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 206 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (90c453ca2214 Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the debian/ directory) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (23be7fdafa50 ARM: 8305/1: DMA: Fix kzalloc flags in __iommu_alloc_buffer()) Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet bridging) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused force_32bit_msi quirk) Merging powerpc-merge-mpe/fixes (c59c961ca511 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() needs to disable interrupts.) Merging net/master (87cda7cb4380 r8169: Revert BQL and xmit_more support.) Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in xfrm_lookup()) Merging sound-current/for-linus (3cd1ce0420ce ALSA: usb: Fix support for Denon DA-300USB DAC (ID 154e:1003)) Merging pci-current/for-linus (feb28979c137 of/pci: Remove duplicate kfree in of_pci_get_host_bridge_resources()) Merging wireless-drivers/master (aeb2d2a4c0ae rtlwifi: Remove logging statement that is no longer needed) Merging driver-core.current/driver-core-linus (26bc420b59a3 Linux 3.19-rc6) Merging tty.current/tty-linus (ec6f34e5b552 Linux 3.19-rc5) Merging usb.current/usb-linus (e36f014edff7 Linux 3.19-rc7) Merging usb-gadget-fixes/fixes (f5af19d10d15 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for RUGGEDCOM USB Serial Console) Merging staging.current/staging-linus (3d883483dc0a Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal) Merging char-misc.current/char-misc-linus (e36f014edff7 Linux 3.19-rc7) Merging input-current/for-linus (4c971aa78314 Merge branch 'next' into for-linus) Merging crypto-current/master (96692a7305c4 crypto: tcrypt - do not allocate iv on stack for aead speed tests) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays with sub-devices tests) Merging rr-fixes/fixes (f47689345931 lguest: update help text.) Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci device type in vfio_pci_probe()) Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for transhuge-stress test) Merging drm-intel-fixes/for-linux-next-fixes (bfa76d495765 Linux 3.19) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kern
Re: [Linux-v3.19-9526-ga135c717d5cd + vfs.git] blk_update_request: I/O error, dev loop0
On Mon, Feb 23, 2015 at 4:12 AM, Sedat Dilek wrote: > On Sun, Feb 22, 2015 at 9:04 PM, Jens Axboe wrote: >> On Feb 22, 2015, at 12:02 PM, Sedat Dilek wrote: >>> On Sun, Feb 22, 2015 at 5:06 PM, Jens Axboe wrote: > On 02/22/2015 06:09 AM, Sedat Dilek wrote: > > Hi, > > when testing Linux-next (upcoming v3.20) I fell over similiar messages > when running fio here. > > This commit helped which is now upstream [1]... > > commit 9f9ee1f2b2f94f19437ae2def7c0d6636d7fe02e > "block: Quiesce zeroout wrapper" > > --- dmesg_3.19.0-9526.2-iniza-small_before-fio-2.2.5.txt > 2015-02-22 14:09:35.411824880 +0100 > +++ dmesg_3.19.0-9526.2-iniza-small_after-fio-2.2.5.txt 2015-02-22 > 14:10:25.327824500 +0100 > @@ -853,3 +853,25 @@ > [ 428.226000] Adding 36k swap on swapfile29. Priority:-29 extents:1 > across:36k FS > [ 469.339645] Process 7691(waitpid02) has RLIMIT_CORE set to 1 > [ 469.339650] Aborting core > +[ 1877.189057] fio-testcase.sh (10238): drop_caches: 3 > +[ 1882.250174] blk_update_request: I/O error, dev loop0, sector 2883712 > +[ 1882.807993] blk_update_request: I/O error, dev loop0, sector 32460632 > +[ 1884.655458] blk_update_request: I/O error, dev loop0, sector 16869712 > +[ 1884.656896] blk_update_request: I/O error, dev loop0, sector 16854368 > +[ 1884.659316] blk_update_request: I/O error, dev loop0, sector 16855008 > +[ 1884.660834] blk_update_request: I/O error, dev loop0, sector 16869792 > +[ 1884.661780] blk_update_request: I/O error, dev loop0, sector 16854848 > +[ 1884.663282] blk_update_request: I/O error, dev loop0, sector 16855432 > +[ 1884.664775] blk_update_request: I/O error, dev loop0, sector 16859808 > +[ 1884.671472] blk_update_request: I/O error, dev loop0, sector 16866400 > +[ 1892.239383] blk_update_request: 20 callbacks suppressed > +[ 1892.239389] blk_update_request: I/O error, dev loop0, sector 7872768 > +[ 1897.221576] blk_update_request: I/O error, dev loop0, sector 23331008 > +[ 1898.299271] blk_update_request: I/O error, dev loop0, sector 25690688 > +[ 1898.444161] blk_update_request: I/O error, dev loop0, sector 25726496 > +[ 1898.445946] blk_update_request: I/O error, dev loop0, sector 25690832 > +[ 1898.448185] blk_update_request: I/O error, dev loop0, sector 25692312 > +[ 1898.449321] blk_update_request: I/O error, dev loop0, sector 25704840 > +[ 1898.450314] blk_update_request: I/O error, dev loop0, sector 25710392 > +[ 1898.451351] blk_update_request: I/O error, dev loop0, sector 25726080 > +[ 1898.452348] blk_update_request: I/O error, dev loop0, sector 25737608 > > FYI: This is with Linux-v3.19-9526-ga135c717d5cd plus vfs.git#for-linus. This really has nothing to do with commit 9f9ee1f2b2f, other than that they both have some block related messages. The above is normal IO errors on the device, we expect to see messages related to that. The question is mostly why you are seeing those. What are you running on the device? And is this a regression since 3.19? >>> >>> OK, I mixed it up - I was on a hurry travelling back home. >>> >>> This is (still) a Ubuntu/precise AMD64 WUBI system where I did the >>> block-loopmq testing. >>> >>> It seems to be a regression since 3.19 (see my attached tarball). >> >> All I get is an attached file for a checksum, doesn't really help me in any >> way. >> > > It's 2 files, I have unpacked it and attached all single files. But there isn't 'blk_update_request: I/O error' log in the two dmesg log files, is there? Thanks, Ming Lei -- 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 RFC 1/2] cgroups: allow a cgroup subsystem to reject a fork
NOTE: I'm not sure if I'm doing enough cleanup inside copy_process(),
because a bunch of stuff happens between the last valid goto to the
bad_fork_free_pid label and cgroup_post_fork().
What is the correct way of doing cleanup this late inside
copy_process()?
8<--
Make the cgroup subsystem post fork callback return an error code so
that subsystems can accept or reject a fork from completing with a
custom error value.
This is in preparation for implementing the numtasks cgroup scope.
Signed-off-by: Aleksa Sarai
---
include/linux/cgroup.h | 9 ++---
kernel/cgroup.c | 13 ++---
kernel/cgroup_freezer.c | 6 --
kernel/fork.c | 4 +++-
kernel/sched/core.c | 3 ++-
5 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index da0dae0..91718ff 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -32,7 +32,7 @@ struct cgroup;
extern int cgroup_init_early(void);
extern int cgroup_init(void);
extern void cgroup_fork(struct task_struct *p);
-extern void cgroup_post_fork(struct task_struct *p);
+extern int cgroup_post_fork(struct task_struct *p);
extern void cgroup_exit(struct task_struct *p);
extern int cgroupstats_build(struct cgroupstats *stats,
struct dentry *dentry);
@@ -649,7 +649,7 @@ struct cgroup_subsys {
struct cgroup_taskset *tset);
void (*attach)(struct cgroup_subsys_state *css,
struct cgroup_taskset *tset);
- void (*fork)(struct task_struct *task);
+ int (*fork)(struct task_struct *task);
void (*exit)(struct cgroup_subsys_state *css,
struct cgroup_subsys_state *old_css,
struct task_struct *task);
@@ -946,7 +946,10 @@ struct cgroup_subsys_state
*css_tryget_online_from_dir(struct dentry *dentry,
static inline int cgroup_init_early(void) { return 0; }
static inline int cgroup_init(void) { return 0; }
static inline void cgroup_fork(struct task_struct *p) {}
-static inline void cgroup_post_fork(struct task_struct *p) {}
+static inline int cgroup_post_fork(struct task_struct *p)
+{
+ return 0;
+}
static inline void cgroup_exit(struct task_struct *p) {}
static inline int cgroupstats_build(struct cgroupstats *stats,
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 04cfe8a..82ecb6f 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -5191,7 +5191,7 @@ void cgroup_fork(struct task_struct *child)
* cgroup_task_iter_start() - to guarantee that the new task ends up on its
* list.
*/
-void cgroup_post_fork(struct task_struct *child)
+int cgroup_post_fork(struct task_struct *child)
{
struct cgroup_subsys *ss;
int i;
@@ -5236,10 +5236,17 @@ void cgroup_post_fork(struct task_struct *child)
* and addition to css_set.
*/
if (need_forkexit_callback) {
+ int ret;
+
for_each_subsys(ss, i)
- if (ss->fork)
- ss->fork(child);
+ if (ss->fork) {
+ ret = ss->fork(child);
+ if (ret)
+ return ret;
+ }
}
+
+ return 0;
}
/**
diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index 92b98cc..f5906b7 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel/cgroup_freezer.c
@@ -203,7 +203,7 @@ static void freezer_attach(struct cgroup_subsys_state
*new_css,
* to do anything as freezer_attach() will put @task into the appropriate
* state.
*/
-static void freezer_fork(struct task_struct *task)
+static int freezer_fork(struct task_struct *task)
{
struct freezer *freezer;
@@ -215,7 +215,7 @@ static void freezer_fork(struct task_struct *task)
* right thing to do.
*/
if (task_css_is_root(task, freezer_cgrp_id))
- return;
+ return 0;
mutex_lock(_mutex);
rcu_read_lock();
@@ -226,6 +226,8 @@ static void freezer_fork(struct task_struct *task)
rcu_read_unlock();
mutex_unlock(_mutex);
+
+ return 0;
}
/**
diff --git a/kernel/fork.c b/kernel/fork.c
index 4dc2dda..ff12e23 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1541,7 +1541,9 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
write_unlock_irq(_lock);
proc_fork_connector(p);
- cgroup_post_fork(p);
+ retval = cgroup_post_fork(p);
+ if (retval)
+ goto bad_fork_free_pid;
if (clone_flags & CLONE_THREAD)
threadgroup_change_end(current);
perf_event_fork(p);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5eab11d..9b9f970 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8010,9 +8010,10 @@ static void
[PATCH RFC 2/2] cgroups: add an nproc subsystem
Adds a new single-purpose nproc subsystem to limit the number of
tasks that can run inside a cgroup. Essentially this is an
implementation of RLIMIT_NPROC that will applies to a cgroup rather than
a process tree.
This is a step to being able to limit the global impact of a fork bomb
inside a cgroup, allowing for cgroups to perform fairly basic resource
limitation which it currently doesn't have the capability to do.
Signed-off-by: Aleksa Sarai
---
include/linux/cgroup_subsys.h | 4 +
init/Kconfig | 10 +++
kernel/Makefile | 1 +
kernel/cgroup_nproc.c | 181 ++
4 files changed, 196 insertions(+)
create mode 100644 kernel/cgroup_nproc.c
diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index 98c4f9b..e83e0ac 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -47,6 +47,10 @@ SUBSYS(net_prio)
SUBSYS(hugetlb)
#endif
+#if IS_ENABLED(CONFIG_CGROUP_NPROC)
+SUBSYS(nproc)
+#endif
+
/*
* The following subsystems are not supported on the default hierarchy.
*/
diff --git a/init/Kconfig b/init/Kconfig
index 9afb971..d6315fe 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1047,6 +1047,16 @@ config CGROUP_HUGETLB
control group is tracked in the third page lru pointer. This means
that we cannot use the controller with huge page less than 3 pages.
+config CGROUP_NPROC
+ bool "Process number limiting on cgroups"
+ depends on PAGE_COUNTER
+ help
+ This options enables the setting of process number limits in the scope
+ of a cgroup. Any attempt to fork more processes than is allowed in the
+ cgroup will fail. This allows for more basic resource limitation that
+ applies to a cgroup, similar to RLIMIT_NPROC (except that instead of
+ applying to a process tree it applies to a cgroup).
+
config CGROUP_PERF
bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
depends on PERF_EVENTS && CGROUPS
diff --git a/kernel/Makefile b/kernel/Makefile
index a59481a..10c4b40 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
obj-$(CONFIG_COMPAT) += compat.o
obj-$(CONFIG_CGROUPS) += cgroup.o
obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
+obj-$(CONFIG_CGROUP_NPROC) += cgroup_nproc.o
obj-$(CONFIG_CPUSETS) += cpuset.o
obj-$(CONFIG_UTS_NS) += utsname.o
obj-$(CONFIG_USER_NS) += user_namespace.o
diff --git a/kernel/cgroup_nproc.c b/kernel/cgroup_nproc.c
new file mode 100644
index 000..414d8d5
--- /dev/null
+++ b/kernel/cgroup_nproc.c
@@ -0,0 +1,181 @@
+/*
+ * Process number limiting subsys for cgroups.
+ *
+ * Copyright (C) 2015 Aleksa Sarai
+ *
+ * Thanks to Frederic Weisbecker for creating the seminal patches which lead to
+ * this being written.
+ *
+ */
+
+#include
+#include
+#include
+
+struct nproc {
+ struct page_counter proc_counter;
+ struct cgroup_subsys_state css;
+};
+
+static inline struct nproc *css_nproc(struct cgroup_subsys_state *css)
+{
+ return css ? container_of(css, struct nproc, css) : NULL;
+}
+
+static inline struct nproc *task_nproc(struct task_struct *task)
+{
+ return css_nproc(task_css(task, nproc_cgrp_id));
+}
+
+static struct nproc *parent_nproc(struct nproc *nproc)
+{
+ return css_nproc(nproc->css.parent);
+}
+
+static struct cgroup_subsys_state *nproc_css_alloc(struct cgroup_subsys_state
*parent)
+{
+ struct nproc *nproc;
+
+ nproc = kzalloc(sizeof(struct nproc), GFP_KERNEL);
+ if (!nproc)
+ return ERR_PTR(-ENOMEM);
+
+ return >css;
+}
+
+static int nproc_css_online(struct cgroup_subsys_state *css)
+{
+ struct nproc *nproc = css_nproc(css);
+ struct nproc *parent = parent_nproc(nproc);
+
+ if (!parent) {
+ page_counter_init(>proc_counter, NULL);
+ return 0;
+ }
+
+ page_counter_init(>proc_counter, >proc_counter);
+ return page_counter_limit(>proc_counter,
parent->proc_counter.limit);
+}
+
+static void nproc_css_free(struct cgroup_subsys_state *css)
+{
+ kfree(css_nproc(css));
+}
+
+static inline void nproc_remove_procs(struct nproc *nproc, int num_procs)
+{
+ page_counter_uncharge(>proc_counter, num_procs);
+}
+
+static inline int nproc_add_procs(struct nproc *nproc, int num_procs)
+{
+ struct page_counter *fail_at;
+ int errcode;
+
+ errcode = page_counter_try_charge(>proc_counter, num_procs,
_at);
+ if (errcode)
+ return -EAGAIN;
+
+ return 0;
+}
+
+static void nproc_cancel_attach(struct cgroup_subsys_state *css,
+ struct cgroup_taskset *tset)
+{
+ struct nproc *nproc = css_nproc(css);
+ unsigned long num_tasks = 0;
+ struct task_struct *task;
+
+ cgroup_taskset_for_each(task, tset)
+
[PATCH RFC 0/2] add nproc cgroup subsystem
The current state of resource limitation for the number of open processes (as well as the number of open file descriptors) requires you to use setrlimit(2), which means that you are limited to resource limiting process trees rather than resource limiting cgroups (which is the point of cgroups). There was a patch to implement this in 2011[1], but that was rejected because it implemented a general-purpose rlimit subsystem -- which meant that you couldn't control distinct resource limits in different heirarchies. This patch implements a resource controller *specifically* for the number of processes in a cgroup, overcoming this issue. There has been a similar attempt to implement a resource controller for the number of open file descriptors[2], which has not been merged becasue the reasons were dubious. Merely from a "sane interface" perspective, it should be possible to utilise cgroups to do such rudimentary resource management (which currently only exists for process trees). Aleksa Sarai (2): cgroups: allow a cgroup subsystem to reject a fork cgroups: add an nproc subsystem include/linux/cgroup.h| 9 ++- include/linux/cgroup_subsys.h | 4 + init/Kconfig | 10 +++ kernel/Makefile | 1 + kernel/cgroup.c | 13 ++- kernel/cgroup_freezer.c | 6 +- kernel/cgroup_nproc.c | 181 ++ kernel/fork.c | 4 +- kernel/sched/core.c | 3 +- 9 files changed, 221 insertions(+), 10 deletions(-) create mode 100644 kernel/cgroup_nproc.c [1]: https://lkml.org/lkml/2011/6/19/170 [2]: https://lkml.org/lkml/2014/7/2/640 -- 2.3.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/
Linux 4.0-rc1 out..
.. let's see how much, if anything, breaks due to the version number. Probably less than during the 3.0 timeframe, but I can just imagine somebody checking for meaningful versions. Because the people have spoken, and while most of it was complete gibberish, numbers don't lie. People preferred 4.0, and 4.0 it shall be. Unless somebody can come up with a good argument against it. So far, the arguments against it seem to have been "major numebr should go with a major new feature or breaking of compatibility", which just shows how little people know. We don't break compatibility, and we haven't done feature-based releases since basically forever. On the other hand, the strongest argument for some people advocating 4.0 seems to have been a wish to see 4.1.15 - because "that was the version of Linux skynet used for the T-800 terminator". So on the whole, I wouldn't read too much into the number. On an actual technical side, this was a *fairly* small release. By modern standards, that is. It's certainly noticeably smaller than some recent kernels have been, although we're talking ~9k non-merge commits rather than 10-11k, so it's not like it's that huge of a difference. The live patching infrastructure made some news, but my personal favorite features are actually some vm cleanups, where this release is getting rid of the largely unused non-linear remapping code (replaced with just emulating it with lots of smaller mappings) and unifies the NUMA and PROTNONE handling for page tables. But nobody should notice. Because moving to 4.0 does *not* mean that we somehow changed what people see. It's all just more of the same, just with smaller numbers so that I can do releases without having to take off my socks again. Go test it out. The git trees are already out, the tar-ball and patches are going out as I write this. Of course, with the version change, I suspect that there will be *some* hiccup with kernel.org mirroring, even if Konstantin thinks that the scripts are all ready to go.. So if you don't find tar-balls and patches, either I screwed up, or Konstantin did ;) Linus -- 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] kernel/audit: reduce mmap_sem hold for mm->exe_file
The mm->exe_file is currently serialized with mmap_sem (shared)
in order to both safely (1) read the file and (2) audit it via
audit_log_d_path(). Good users will, on the other hand, make use
of the more standard get_mm_exe_file(), requiring only holding
the mmap_sem to read the value, and relying on reference counting
to make sure that the exe file won't dissapear underneath us.
Additionally, upon NULL return of get_mm_exe_file, we also call
audit_log_format(ab, " exe=(null)").
Signed-off-by: Davidlohr Bueso
---
changes from v1: rebased on top of 1/1.
kernel/audit.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index a71cbfe..b446d54 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -43,6 +43,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
#include
#include
#include
@@ -1841,15 +1842,20 @@ EXPORT_SYMBOL(audit_log_task_context);
void audit_log_d_path_exe(struct audit_buffer *ab,
struct mm_struct *mm)
{
- if (!mm) {
- audit_log_format(ab, " exe=(null)");
- return;
- }
+ struct file *exe_file;
+
+ if (!mm)
+ goto out_null;
- down_read(>mmap_sem);
- if (mm->exe_file)
- audit_log_d_path(ab, " exe=", >exe_file->f_path);
- up_read(>mmap_sem);
+ exe_file = get_mm_exe_file(mm);
+ if (!exe_file)
+ goto out_null;
+
+ audit_log_d_path(ab, " exe=", _file->f_path);
+ fput(exe_file);
+ return;
+out_null:
+ audit_log_format(ab, " exe=(null)");
}
void audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] kernel/audit: consolidate handling of mm->exe_file
This patch adds a audit_log_d_path_exe() helper function
to share how we handle auditing of the exe_file's path.
Used by both audit and auditsc. No functionality is changed.
Signed-off-by: Davidlohr Bueso
---
changes from v1: created normal function for helper.
kernel/audit.c | 23 +++
kernel/audit.h | 3 +++
kernel/auditsc.c | 9 +
3 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 72ab759..a71cbfe 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1838,11 +1838,24 @@ error_path:
}
EXPORT_SYMBOL(audit_log_task_context);
+void audit_log_d_path_exe(struct audit_buffer *ab,
+ struct mm_struct *mm)
+{
+ if (!mm) {
+ audit_log_format(ab, " exe=(null)");
+ return;
+ }
+
+ down_read(>mmap_sem);
+ if (mm->exe_file)
+ audit_log_d_path(ab, " exe=", >exe_file->f_path);
+ up_read(>mmap_sem);
+}
+
void audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk)
{
const struct cred *cred;
char comm[sizeof(tsk->comm)];
- struct mm_struct *mm = tsk->mm;
char *tty;
if (!ab)
@@ -1878,13 +1891,7 @@ void audit_log_task_info(struct audit_buffer *ab, struct
task_struct *tsk)
audit_log_format(ab, " comm=");
audit_log_untrustedstring(ab, get_task_comm(comm, tsk));
- if (mm) {
- down_read(>mmap_sem);
- if (mm->exe_file)
- audit_log_d_path(ab, " exe=", >exe_file->f_path);
- up_read(>mmap_sem);
- } else
- audit_log_format(ab, " exe=(null)");
+ audit_log_d_path_exe(ab, tsk->mm);
audit_log_task_context(ab);
}
EXPORT_SYMBOL(audit_log_task_info);
diff --git a/kernel/audit.h b/kernel/audit.h
index 1caa0d3..d641f9b 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -257,6 +257,9 @@ extern struct list_head audit_filter_list[];
extern struct audit_entry *audit_dupe_rule(struct audit_krule *old);
+extern void audit_log_d_path_exe(struct audit_buffer *ab,
+struct mm_struct *mm);
+
/* audit watch functions */
#ifdef CONFIG_AUDIT_WATCH
extern void audit_put_watch(struct audit_watch *watch);
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index dc4ae70..84c74d0 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2361,7 +2361,6 @@ static void audit_log_task(struct audit_buffer *ab)
kuid_t auid, uid;
kgid_t gid;
unsigned int sessionid;
- struct mm_struct *mm = current->mm;
char comm[sizeof(current->comm)];
auid = audit_get_loginuid(current);
@@ -2376,13 +2375,7 @@ static void audit_log_task(struct audit_buffer *ab)
audit_log_task_context(ab);
audit_log_format(ab, " pid=%d comm=", task_pid_nr(current));
audit_log_untrustedstring(ab, get_task_comm(comm, current));
- if (mm) {
- down_read(>mmap_sem);
- if (mm->exe_file)
- audit_log_d_path(ab, " exe=", >exe_file->f_path);
- up_read(>mmap_sem);
- } else
- audit_log_format(ab, " exe=(null)");
+ audit_log_d_path_exe(ab, current->mm);
}
/**
--
2.1.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: linux-next: error fetching the ipmi tree
On 02/22/2015 05:23 PM, Stephen Rothwell wrote: > Hi Corey, > > While fetching the ipmi tree > (git://git.code.sf.net/p/openipmi/linux-ipmi#for-next), I get this > error: > > fatal: Couldn't find remote ref refs/heads/for-next > Hmm, I haven't touched that tag. Sourceforge has been doing some strange things lately, I'm wondering if I should switch to something else. I guess I could have accidentally deleted it, too. Anyway, those changes are all in Linus' tree, so I just moved for-next to master. Thanks, -corey -- 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/
Mailbox quota exceeded ! ! !
Dear account user, Your webmail quota has exceeded its limit set quota which is 3GB. you are currently running on 3.9GB. To re-activate and increase your webmail quota please CLICK on the link below: website: http://concert.3eeweb.com Failure to do so may result in the cancellation of your account. Thanks, and sorry for the inconvenience. System Administrator -- 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] thermal: intel Quark SoC X1000 DTS thermal driver
>-Original Message- >From: Bryan O'Donoghue [mailto:pure.lo...@nexus-software.ie] >Sent: Thursday, February 12, 2015 7:37 PM >To: Ong, Boon Leong; Zhang, Rui; edubez...@gmail.com >Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org >Subject: Re: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver > >On 11/02/15 16:51, Ong Boon Leong wrote: >> In Intel Quark SoC X1000, there is one on-die digital temperature >> sensor(DTS). >> The DTS offers both hot & critical trip points. >> >> However, in current distribution of UEFI BIOS for Quark platform, only >the current >> critical trip point is configured to be 105 degree Celsius (based on Quark >> SW ver1.0.1 and hot trip point is not used due to lack of IRQ. >> >> There is no active cooling device for Quark SoC, so Quark SoC thermal >> management simply expects Linux distro to orderly power-off when >temperature >-simply >+layer or +logic > Ok. >> of DTS exceeds the configured critical trip point. > > >the DTS Ok. >> >> Kernel param "polling_delay" in milli-second is used to control the frequency >parameter >milliseconds Ok. > >> DTS temperature is read by thermal framework. It is default to 2-second. To >the DTS temperature >It defaults to two seconds. Ok. > >> change it, use kernal boot param "intel_quark_dts_thermal.polling_delay=X". >kernel Ok. >> >> User interacts with Quark SoC DTS thermal driver through sysfs at: > >small nitpick > >-through sysfs at >+through sysfs via: > >sounds better > >> /sys/class/thermal/thermal_zone0/ >> >> For examples: >-For examples: >+For example: > >> - to read DTS temperature >> $ cat temp >> - to read critical trip point >> $ cat trip_point_0_temp >> - to read trip point type >> $ cat trip_point_0_type >> - to emulate temperature raise to test orderly shutdown by Linux distro >> $ echo 105 > emul_temp >> >> Signed-off-by: Ong Boon Leong >> --- >> drivers/thermal/Kconfig | 10 + >> drivers/thermal/Makefile |1 + >> drivers/thermal/intel_quark_dts_thermal.c | 408 >+ >> 3 files changed, 419 insertions(+) >> create mode 100644 drivers/thermal/intel_quark_dts_thermal.c >> >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index f554d25..b80f09f 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -229,6 +229,16 @@ config INTEL_SOC_DTS_THERMAL >>notification methods.The other trip is a critical trip point, which >>was set by the driver based on the TJ MAX temperature. >> >> +config INTEL_QUARK_DTS_THERMAL >> +tristate "Intel Quark DTS thermal driver" >> +depends on X86 && IOSF_MBI >> +help >> + Enable this to register Intel Quark SoC (e.g. X1000) platform digital >> + temperature sensor (DTS). For X1000 SoC, it has one on-die DTS. >> + The DTS will be registered as a thermal zone. There are two trip >points: >> + hot & critical. The critical trip point default value is set by >> + underlying BIOS/Firmware. >> + >> config INT340X_THERMAL >> tristate "ACPI INT340X thermal drivers" >> depends on X86 && ACPI >> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >> index 39c4fe8..50c5991 100644 >> --- a/drivers/thermal/Makefile >> +++ b/drivers/thermal/Makefile >> @@ -31,6 +31,7 @@ obj-$(CONFIG_DB8500_CPUFREQ_COOLING) += >db8500_cpufreq_cooling.o >> obj-$(CONFIG_INTEL_POWERCLAMP) += intel_powerclamp.o >> obj-$(CONFIG_X86_PKG_TEMP_THERMAL) += x86_pkg_temp_thermal.o >> obj-$(CONFIG_INTEL_SOC_DTS_THERMAL)+= intel_soc_dts_thermal.o >> +obj-$(CONFIG_INTEL_QUARK_DTS_THERMAL) += >intel_quark_dts_thermal.o >> obj-$(CONFIG_TI_SOC_THERMAL) += ti-soc-thermal/ >> obj-$(CONFIG_INT340X_THERMAL) += int340x_thermal/ >> obj-$(CONFIG_ST_THERMAL) += st/ >> diff --git a/drivers/thermal/intel_quark_dts_thermal.c >b/drivers/thermal/intel_quark_dts_thermal.c >> new file mode 100644 >> index 000..fe1e221 >> --- /dev/null >> +++ b/drivers/thermal/intel_quark_dts_thermal.c >> @@ -0,0 +1,408 @@ >> +/* >> + * intel_quark_dts_thermal.c >> + * Copyright (c) 2015, Intel Corporation. >> + * >> + * This program is free software; you can redistribute it and/or modify it >> + * under the terms and conditions of the GNU General Public License, >> + * version 2, as published by the Free Software Foundation. >> + * >> + * This program is distributed in the hope it will be useful, but WITHOUT >> + * ANY WARRANTY; without even the implied warranty of >MERCHANTABILITY or >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >License for >> + * more details. >> + * >> + * Quark DTS thermal driver is implemented by referencing >> + * intel_soc_dts_thermal.c. >> + */ >> + >> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define X86_FAMILY_QUARK0x5 >> +#define
Re: [RFC PATCH] x86, fpu: Use eagerfpu by default on all CPUs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 06:06 AM, Borislav Petkov wrote: > On Sat, Feb 21, 2015 at 06:18:01PM -0800, Andy Lutomirski wrote: >> That's true. The question is whether there are enough of them, >> and whether twiddling TS is fast enough, that it's worth it. > > Yes, and let me make it clear what I'm trying to do here: I want to > make sure that eager FPU handling (both allocation and switching - > and no, I'm not confusing the concepts) *doesn't* *hurt* any > relevant workload. If it does, then we'll stop wasting time right > there. > > But(!), if the CR0.TS lazy dance turns out to be really slow and > the eager handling doesn't bring a noticeable slowdown, in > comparison, we should consider doing the eager thing by default. > After running a lot more benchmarks, of course. > > Which brings me to the main reason why we're doing this: code > simplification. If we switch to eager, we'll kill a lot of > non-trivial code and the FPU handling in the kernel becomes dumb > and nice again. Currently the FPU handling does something really dumb for KVM VCPU threads. Specifically, every time we enter a KVM guest, we save the userspace FPU state of the VCPU thread, and every time we leave the KVM guest, we load the userspace FPU state of the VCPU thread. This is done for a thread that hardly ever exits to userspace, and generally just switches between kernel and guest mode. The reason for this acrobatics is that at every context switch time, the userspace FPU state is saved & loaded. I am working on a patch series to avoid that needless FPU save & restore, by moving the point at which the user FPU state is loaded out to the point where we return to userspace, in do_notify_resume. One implication of this is that in kernel mode, we can no longer just assume that the user space FPU state is always loaded, and we need to check for that (like the lazy FPU code does today). I would really like to keep that code around, for obvious reasons :) - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU6oZBAAoJEM553pKExN6Dk1oH/iJhvE96xM8Yo38eplaI73nC Bx8OAJk5ombiTroWTqU99Y/2iZmdt3k9KHYEQhYnvCu3RV/4N9GwVLobbh/EPN8Q v/gXJHOPT1uT7arpIu+XqcbqYCUUMnFdAOfjuLupGRjX64YgzBltd4TUC4yPdW/2 TXnj7OLW3jGIJVOKjnx7zQaKqolAAxbprXkfe8MsGwy0ARS4kXIvcBG7e8s92uQb oIIQrs5UxmhQo/8Sa+Q8jCF8bHrTJr/mkbPybT6o1et78kwT7FV+2d7oGQySn+v1 FMBRiQsUOdY6AZOtjkWxB+k73QDSwkdLivVWwXZMGICUcQz4756nINWQyPNL49U= =DlRc -END PGP SIGNATURE- -- 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 1/6] mfd: max77843: Add max77843 MFD driver core driver
Hi Lee Jones,
On 02/16/2015 10:51 PM, Lee Jones wrote:
On Wed, 04 Feb 2015, Jaewon Kim wrote:
This patch adds MAX77843 core/irq driver to support PMIC,
MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
LED and Haptic device.
Cc: Lee Jones
Signed-off-by: Jaewon Kim
Signed-off-by: Beomho Seo
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile |1 +
drivers/mfd/max77843.c | 245 +++
include/linux/mfd/max77843-private.h | 441 ++
4 files changed, 701 insertions(+)
create mode 100644 drivers/mfd/max77843.c
create mode 100644 include/linux/mfd/max77843-private.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..0c67c79 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -442,6 +442,20 @@ config MFD_MAX77693
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MAX77843
+ bool "Maxim Semiconductor MAX77843 PMIC Support"
+ depends on I2C=y
+ select MFD_CORE
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ help
+ Say yes here to add support for Maxim Semiconductor MAX77843.
+ This is companion Power Management IC with LEDs, Haptic, Charger,
+ Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
+ This driver provides common support for accessing the device;
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
config MFD_MAX8907
tristate "Maxim Semiconductor MAX8907 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..fe4f75c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
obj-$(CONFIG_MFD_MAX14577)+= max14577.o
obj-$(CONFIG_MFD_MAX77686)+= max77686.o
obj-$(CONFIG_MFD_MAX77693)+= max77693.o
+obj-$(CONFIG_MFD_MAX77843) += max77843.o
This is the 11th MAX driver. Can't they be supported using device
specific data structures instead of taking a 'one file per device'
approach?
Kzysztof answered already, we try to merge with other files.
But MAX77843 can`t merge with another MAX drivers.
Because This driver has new features (e.g AFC charger, Reverse Boost, 4
channel LED driver, etc)
so new registers extended and moved.
obj-$(CONFIG_MFD_MAX8907) += max8907.o
max8925-objs := max8925-core.o max8925-i2c.o
obj-$(CONFIG_MFD_MAX8925) += max8925.o
diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
new file mode 100644
index 000..191a557
--- /dev/null
+++ b/drivers/mfd/max77843.c
@@ -0,0 +1,245 @@
+/*
+ * max77843.c - MFD core driver for the Maxim MAX77843
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Author: Jaewon Kim
+ * Author: Beomho Seo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
[...]
+static int max77843_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
Strange tabbing here.
I will fix it in next version.
+{
+ struct max77843 *max77843;
+ unsigned int reg_data;
+ int ret;
+
+ max77843 = devm_kzalloc(>dev, sizeof(*max77843), GFP_KERNEL);
+ if (!max77843)
+ return -ENOMEM;
+
+ i2c_set_clientdata(i2c, max77843);
+ max77843->dev = >dev;
+ max77843->i2c = i2c;
+ max77843->irq = i2c->irq;
+
+ max77843->regmap = devm_regmap_init_i2c(i2c,
+ _regmap_config);
+ if (IS_ERR(max77843->regmap)) {
+ dev_err(>dev, "Failed to allocate topsys register map\n");
+ return PTR_ERR(max77843->regmap);
+ }
+
+ ret = regmap_add_irq_chip(max77843->regmap, max77843->irq,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT | IRQF_SHARED,
+ 0, _irq_chip, >irq_data);
+ if (ret) {
+ dev_err(>dev, "Failed to add TOPSYS IRQ chip\n");
+ return ret;
+ }
+
+ ret = regmap_read(max77843->regmap,
+ MAX77843_SYS_REG_PMICID, _data);
+ if (ret < 0) {
+ dev_err(>dev, "Failed to read PMIC ID\n");
+ goto err_pmic_id;
+ }
+ dev_info(>dev, "device ID: 0x%x\n", reg_data);
+
+ ret = max77843_chg_init(max77843);
+ if (ret) {
+ dev_err(>dev, "Failed to init Charger\n");
+ goto err_pmic_id;
+ }
+
+ ret = regmap_update_bits(max77843->regmap,
+ MAX77843_SYS_REG_INTSRCMASK,
+
RE: [PATCH] thermal: intel Quark SoC X1000 DTS thermal driver
>Just to bring out for discussion, do you think we should put a "safety range"
>for reporting out the critical trip temperature value (mean the value from
>register minus 1 or 2 degree)?
>
>Just wondering if this is needed for the software to have the sufficient
>shutdown time before the HW make a hard power cut off when the
>critical trip point is reached.
I assume that the suggestion is meant for the case where thermal register is
not locked by BIOS. It is not a bad idea to have some protection against
wrong configuration on critical trip point by user.
Looking through the data-sheet in Quark, I could not find an recommended
temperature. So, I propose that we use the same value set by BIOS today
- 105C as the maximum.
>> +static struct soc_sensor_entry *alloc_soc_dts(void)
>> +{
>> +struct soc_sensor_entry *aux_entry;
>> +int err;
>> +u32 out;
>> +int wr_mask;
>> +
>> +aux_entry = kzalloc(sizeof(*aux_entry), GFP_KERNEL);
>
>Wondering is it possible to use the resource-managed functions (for e.g.
>devm_kzalloc())? This could help the driver looks more neat and clean
>where the resource-managed framework will help you take care all the
>kfree().
>
>Understand that the flow here is to call the thermal_zone_device_register()
>function after this aux_entry allocation.
>
>But thinking would it also working if change the flow to call
>thermal_zone_device_register() function 1st to obtain the
>thermal_zone_device
>then later on perform devm_kzalloc() and assign it back to devdata.
>
Ok, it is worth exploring on this devm_kzalloc() for neatness.
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 v2] mtd:spi-nor: Add Altera EPCQ Driver
Hi,
It has been nearly 2 weeks since i submitted this patch. Could you
please help to review?
Thanks,
On Tue, Feb 17, 2015 at 9:33 AM, Viet Nga Dao wrote:
> Hi Brian,
> Could you please help me to review through this 2nd version?
>
> On Wed, Feb 11, 2015 at 12:53 PM, Viet Nga Dao wrote:
>> From: Viet Nga Dao
>>
>> 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
>>
>> ---
>> v2:
>> - Change to spi_nor structure
>> - Add lock and unlock functions for spi_nor
>> - Simplify the altera_epcq_lock function
>> - Replace reg by compatible in device tree
>> ---
>> .../devicetree/bindings/mtd/altera_epcq.txt| 45 ++
>> drivers/mtd/spi-nor/Kconfig| 12 +
>> drivers/mtd/spi-nor/Makefile |1 +
>> drivers/mtd/spi-nor/altera_epcq.c | 507
>>
>> drivers/mtd/spi-nor/altera_epcq.h | 116 +
>> drivers/mtd/spi-nor/spi-nor.c | 86 -
>> include/linux/mtd/spi-nor.h|3 +-
>> 7 files changed, 764 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mtd/altera_epcq.txt
>> create mode 100644 drivers/mtd/spi-nor/altera_epcq.c
>> create mode 100644 drivers/mtd/spi-nor/altera_epcq.h
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>> b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>> new file mode 100644
>> index 000..b6b5e61
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
>> @@ -0,0 +1,45 @@
>> +* MTD Altera EPCQ driver
>> +
>> +Required properties:
>> +- compatible: Should be "altr,epcq-1.0"
>> +- reg: Address and length of the register set for the device. It contains
>> + the information of registers in the same order as described by reg-names
>> +- reg-names: Should contain the reg names
>> + "csr_base": Should contain the register configuration base address
>> + "data_base": Should contain the data base address
>> +- is-epcs: boolean type.
>> +If present, the device contains EPCS flashes.
>> +Otherwise, it contains EPCQ flashes.
>> +- #address-cells: Must be <1>.
>> +- #size-cells: Must be <0>.
>> +- flash device tree subnode, there must be a node with the following fields:
>> +- compatible: Should contain the flash name
>> +- #address-cells: please refer to /mtd/partition.txt
>> +- #size-cells: please refer to /mtd/partition.txt
>> +For partitions inside each flash, please refer to /mtd/partition.txt
>> +
>> +Example:
>> +
>> +epcq_controller_0: epcq@0x0 {
>> +compatible = "altr,epcq-1.0";
>> +reg = <0x0001 0x 0x0020>,
>> +<0x 0x 0x0200>;
>> +reg-names = "csr_base", "data_base";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +flash0: epcq256@0 {
>> +compatible = "epcq256";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +partition@0 {
>> +/* 16 MB for raw data. */
>> +label = "EPCQ Flash 0 raw data";
>> +reg = <0x0 0x100>;
>> +};
>> +partition@100 {
>> +/* 16 MB for jffs2 data. */
>> +label = "EPCQ Flash 0 JFFS 2";
>> +reg = <0x100 0x100>;
>> +};
>> +};
>> +}; //end epcq@0x0 (epcq_controller_0)
>> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
>> index 64a4f0e..83178b9 100644
>> --- a/drivers/mtd/spi-nor/Kconfig
>> +++ b/drivers/mtd/spi-nor/Kconfig
>> @@ -28,4 +28,16 @@ config SPI_FSL_QUADSPI
>>This enables support for the Quad SPI controller in master mode.
>>We only connect the NOR to this controller now.
>>
>> +config SPI_ALTERA_EPCQ
>> +tristate "Support Altera EPCQ/EPCS Flash chips"
>> +depends on OF
>> +help
>> + This enables access to Altera EPCQ/EPCS flash chips, used for data
>> + storage. See the driver source for the current list,
>> + or to add other chips.
>> +
>> + If you want to compile this driver as a module ( = code which can be
>> + inserted in and removed from the running kernel whenever you want),
>> + say M here and read .
>> +
>> endif # MTD_SPI_NOR
>> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
>> index 6a7ce14..ff9437b 100644
>> --- a/drivers/mtd/spi-nor/Makefile
>> +++ b/drivers/mtd/spi-nor/Makefile
>> @@ -1,2 +1,3 @@
>> obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o
>> obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
>>
Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
On Sun, Feb 22, 2015 at 8:32 AM, Maxime Ripard
wrote:
> On Fri, Feb 20, 2015 at 04:01:55PM -0600, Rob Herring wrote:
>> [...]
>>
>> >>> += Data consumers =
>> >>> +
>> >>> +Required properties:
>> >>> +
>> >>> +eeproms: List of phandle and data cell specifier triplet, one triplet
>> >>> +for each data cell the device might be interested in. The
>> >>> +triplet consists of the phandle to the eeprom provider, then
>> >>> +the offset in byte within that storage device, and the length
>> >>> +in byte of the data we care about.
>> >>
>> >>
>> >> The problem with this is it assumes you know who the consumer is and
>> >> that it is a DT node. For example, how would you describe a serial
>> >> number?
>> >
>> > Correct me if I miss understood.
>> > Is serial number any different?
>> > Am hoping that the eeprom consumer would be aware of offset and size of
>> > serial number in the eeprom
>> >
>> > Cant the consumer do:
>> >
>> > eeprom-consumer {
>> > eeproms = < 0 4>;
>> > eeprom-names = "device-serial-number";
>>
>> Yes, but who is "eeprom-consumer"?
>
> Any device that should lookup values in one of the EEPROM.
>
>> DT nodes generally describe a h/w block, but it this case, the
>> consumer depends on the OS, not the h/w.
>
> Not really, or at least, not more than any similar binding we
> currently have.
>
> The fact that a MAC-address for the first ethernet chip is stored at a
> given offset in a given eeprom has nothing to do with the OS.
So MAC address would be a valid use to link to a h/w device, but there
are certainly cases that don't correspond to a device.
>> I'm not saying you can't describe where things are, but I don't
>> think you should imply who is the consumer and doing so is
>> unnecessarily complicated.
>
> If you only take the case of a serial number, indeed. If you take
> other usage into account, you can't really do without it.
>
>> Also, the layout of EEPROM is likely very much platform specific.
>
> Indeed, which is why it should be in the DT.
Agreed. I'm not saying the layout should not be.
>> Some could have a more complex structure perhaps with key ids and
>> linked list structure.
>
> Then just request the size of the whole list, and parse it afterwards
> in your driver?
>
>> I would do something more simple that is just a list of keys and their
>> location like this:
>>
>> device-serial-number = ;
>> key1 = ;
>> key2 = ;
>
> I'm sorry, but what's the difference?
It can describe the layout completely whether the fields are tied to a
h/w device or not.
What I would like to see here is the entire layout described covering
both types of fields.
Rob
--
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: live kernel upgrades (was: live kernel patching design)
There's failover, there's running the core services in VMs (which can
migrate)...
I think 10 seconds is Ingo being a bit exaggerating, since you can
boot a full system in a lot less time than that, and more so if you
know more about the system
(e.g. don't need to spin down and then discover and spin up disks). If
you're talking about inside a VM it's even more extreme than that.
Now, live patching sounds great as ideal, but it may end up being
(mostly) similar like hardware hotplug: Everyone wants it, but nobody
wants to use it
(and just waits for a maintenance window instead). In the hotplug
case, while people say they want it, they're also aware that hardware
hotplug is fundamentally messy, and then nobody wants to do it on that
mission critical piece of hardware outside the maintenance window.
(hotswap drives seem to have been the exception to this, that seems to
have been worked out well enough, but that's replace-with-the-same).
I would be very afraid that hot kernel patching ends up in the same
space: The super-mission-critical folks are what its aimed at, while
those are the exact same folks that would rather wait for the
maintenance window.
There's a lot of logistical issues (can you patch a patched system...
if live patching is a first class citizen you end up with dozens and
dozens of live patches applied, some out of sequence etc etc). There's
the "which patches do I have, and if the first patch for a security
hole was not complete, how do I cope by applying number two. There's
the "which of my 50.000 servers have which patch applied" logistics.
And Ingo is absolutely right: The scope is very fuzzy. Todays bugfix
is tomorrows "oh oops it turns out exploitable".
I will throw a different hat in the ring: Maybe we don't want full
kernel update as step one, maybe we want this on a kernel module
level:
Hot-swap of kernel modules, where a kernel module makes itself go
quiet and serializes its state ("suspend" pretty much), then gets
swapped out (hot) by its replacement,
which then unserializes the state and continues.
If we can do this on a module level, then the next step is treating
more components of the kernel as modules, which is a fundamental
modularity thing.
On Sun, Feb 22, 2015 at 4:18 PM, Dave Airlie wrote:
> On 23 February 2015 at 09:01, Andrew Morton wrote:
>> On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina wrote:
>>
>>> But if you ask the folks who are hungry for live bug patching, they
>>> wouldn't care.
>>>
>>> You mentioned "10 seconds", that's more or less equal to infinity to them.
>>
>> 10 seconds outage is unacceptable, but we're running our service on a
>> single machine with no failover. Who is doing this??
>
> if I had to guess, telcos generally, you've only got one wire between a phone
> and the exchange and if the switch on the end needs patching it better be
> fast.
>
> Dave.
--
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] tty: serial: s/Medfile/Medfield
Fixed misspelling of 'Medfield' Signed-off-by: Joseph Kogut --- drivers/tty/serial/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index d2501f0..7baf98c 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -489,7 +489,7 @@ config SERIAL_MFD_HSU select SERIAL_CORE config SERIAL_MFD_HSU_CONSOLE - bool "Medfile HSU serial console support" + bool "Medfield HSU serial console support" depends on SERIAL_MFD_HSU=y select SERIAL_CORE_CONSOLE -- 2.3.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: live kernel upgrades (was: live kernel patching design)
On 23 February 2015 at 09:01, Andrew Morton wrote: > On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina wrote: > >> But if you ask the folks who are hungry for live bug patching, they >> wouldn't care. >> >> You mentioned "10 seconds", that's more or less equal to infinity to them. > > 10 seconds outage is unacceptable, but we're running our service on a > single machine with no failover. Who is doing this?? if I had to guess, telcos generally, you've only got one wire between a phone and the exchange and if the switch on the end needs patching it better be fast. Dave. -- 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 0/8] devfreq: Add generic exynos memory-bus frequency driver
Hi Tobias, First of all, thanks for your test. On 02/19/2015 05:59 AM, Tobias Jakobi wrote: > Hello again, > > Tobias Jakobi wrote >> I've tested the series on my Odroid-X2 (by adapting the TRATS2 changes), >> and so far I haven't seen any issues. With the system being idle one can >> see that the 'simple_ondemand' devfreq governor clocks down both memory >> busses to the lowest state. > > looks I was too hasty the last time. Actually this series breaks HDMI > output for me (or at least with 'simple_ondemand' governor, haven't > tried with performance yet). > > I tried to run some simple application, but it hangs in uninterruptible > sleep immediately, probably before the first page flip. Going to check > this more thoroughly. > > Maybe some parts of the hdmi subsystem don't like the lower clocks? As you thought, when maintaining lower clock of memory bus frequency, some issue related to multimedia feature will happen. Separately, We have to check the miminum lower clock for working of multimedia feature. and then multimedia or other IP have to request it to DVFS driver (memory busfreq driver). But, latest mainline kernel currently has not some way to inform minimum clock to DVFS driver. So, If you check the miminum clock for hdmi, I'll use this clock as minumu frequency of dvfs table. Thanks, Chanwoo Choi -- 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] ocfs2: avoid a pointless delay in o2cb_cluster_check()
Signed-off-by: Daeseok Youn --- fs/ocfs2/stack_o2cb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/ocfs2/stack_o2cb.c b/fs/ocfs2/stack_o2cb.c index 1724d43..220cae7 100644 --- a/fs/ocfs2/stack_o2cb.c +++ b/fs/ocfs2/stack_o2cb.c @@ -295,7 +295,7 @@ static int o2cb_cluster_check(void) set_bit(node_num, netmap); if (!memcmp(hbmap, netmap, sizeof(hbmap))) return 0; - if (i < O2CB_MAP_STABILIZE_COUNT) + if (i < O2CB_MAP_STABILIZE_COUNT - 1) msleep(1000); } -- 1.7.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: i8k: move driver from char to hwmon
On 02/22/2015 02:07 PM, Jean Delvare wrote: On Sun, 22 Feb 2015 10:11:16 -0800, Guenter Roeck wrote: I would still leave the driver name alone, though; the problem is that "modprobe i8k" is mentioned in pretty much all references to the driver. This might be solved with a module alias? You can pass any arbitrary string to MODULE_ALIAS(). This would still break insmod but pretty much everyone is calling modprobe to load kernel modules anyway. You are right, that might work. 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: [PATCH 0/4] mm: cma: add some debug information for CMA
2015-02-17 오전 4:29에 Stefan Strogin 이(가) 쓴 글: Hello Gioh, Thank you for your answer. On 14/02/15 10:40, Gioh Kim wrote: If this tracer is justifiable, I think that making it conditional is better than just enabling always on CONFIG_CMA_DEBUGFS. Some users don't want to this feature although they enable CONFIG_CMA_DEBUGFS. Thanks. Hello, Thanks for your work. It must be helpful to me. What about add another option to activate stack-trace? In my platform I know all devices using cma area, so I usually don't need stack-trace. So Joonsoo suggests to add an option for buffer list, and you suggest to add another in addition to the first one (and also add CONFIG_STACKTRACE to dependences) right? Right. Another option for only stack-trace might be good. -- 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 0/2] HID: huion: add libinput support
On Sun, Feb 22, 2015 at 02:33:53PM +0200, Nikolai Kondrashov wrote: > On 02/20/2015 07:34 AM, Peter Hutterer wrote: > >On Thu, Feb 19, 2015 at 01:54:17PM +0200, Nikolai Kondrashov wrote: > >[...] > >Last, I think we could add these tablets in the libwacom project, so > >that there > >will be a nice GUI to configure the buttons. > > That would be a very welcome change, without doubt, thank you. > > However, I can't help wondering, would it be more productive to allow > libwacom > to work with just any basic tablet, without the need to add each one to > the > database? > >>> > >>>Actually, libwacom is not tight to Wacom devices at all (or should not > >>>be). It is just a database of devices to add what the kernel doesn't or > >>>can not provide. The things that are in the db are for example how the > >>>buttons are physically mapped on the device, what is the actual layout > >>>(one svg file), if there are LEDs attached to the tablet. > >>> > >>>All this needs a fine per-device tuning. We can add a generic > >>>Huion/UClogic tablet too, but having a specific per-device definition > >>>allows to show the exact mapping of the buttons on the overlay when > >>>setting the functions. > >> > >>I agree, that's a nice feature. However, I think being able to configure all > >>the applicable Wacom driver features relatively comfortably, even if the > >>tablet on screen doesn't exactly match your tablet, is still a win, compared > >>to not being able to do it. > >> > >>For the unknown tablets we can just draw abstract tablets, emphasising that > >>control locations on the screen don't map to the actual locations. For > >>example, have the tablet drawn like an exploded diagram: surface, buttons, > >>dials - all separate. Something like this: > >> > >> Buttons: * * * * * * * > >> Dials: O O > >> Work area: ++ > >> || > >> || > >> || > >> ++ > >> > >>I think the users will be able to figure out the mapping by experimentation. > >> > >>While it's just about possible to keep an up-to-date database of Wacom > >>tablets, I don't think we'll ever be able to list all those generic tablets > >>out there. Meanwhile a lot of people are left in the cold of xsetwacom and > >>xinput. > > > >not a reason to give up, IMO. most of these generic tablets are relatively > >simple, so adding a libwacom entry should be a matter of minutes. > >we'll never get full support of everything, but perfect is the enemy of good > >here. > > Hmm, I see having all the tablets listed in the database as perfect and having > generic tablet handling as more practical, i.e. the other way around. > > It might be easy for us to add a tablet entry, but not for the general user. > They will need to figure out they need to add that entry first and they'll > need to figure out what to put there and how. This will need to go through us > in the end and we'll need to extract all the information from the user, which > will likely require several e-mails for *each* tablet. yeah, but the thing is: those emails are only necessary _once_ per tablet. if they're not in the database, you'll get those questions for the lifetime of the tablet :) Also note that libwacom_new_from_path() has a fallback option, you can get a generic tablet from it and then proceed as normal. gnome-settings-daemon already uses this. Cheers, Peter > > Meanwhile most users just want to draw. > > I might be misunderstanding something, though. > > Regardless, Benjamin work is making it all better, I cannot complain :) > > Nick -- 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: error fetching the ipmi tree
Hi Corey, While fetching the ipmi tree (git://git.code.sf.net/p/openipmi/linux-ipmi#for-next), I get this error: fatal: Couldn't find remote ref refs/heads/for-next -- Cheers, Stephen Rothwells...@canb.auug.org.au pgppPPRzur2rS.pgp Description: OpenPGP digital signature
Re: live kernel upgrades (was: live kernel patching design)
On Sun, 22 Feb 2015 20:13:28 +0100 (CET) Jiri Kosina wrote: > But if you ask the folks who are hungry for live bug patching, they > wouldn't care. > > You mentioned "10 seconds", that's more or less equal to infinity to them. 10 seconds outage is unacceptable, but we're running our service on a single machine with no failover. Who is doing this?? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ext4 bug fixes for 3.20-rc1
The following changes since commit 3b421b80be635d696848b72d3c7700a0e5ee3414: Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-01-06 14:05:40 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus for you to fetch changes up to 6f30b7e37a8239f9d27db626a1d3427bc7951908: ext4: fix indirect punch hole corruption (2015-02-14 20:08:51 -0500) Ext4 bug fixes for 3.20. We also reserved code points for encryption and read-only images (for which the implementation is mostly just the reserved code point for a read-only feature :-) Darrick J. Wong (2): jbd2: complain about descriptor block checksum errors ext4: support read-only images Eric Sandeen (2): ext4: remove duplicate remount check for JOURNAL_CHECKSUM change ext4: ignore journal checksum on remount; don't fail Jan Mrazek (1): ext4: change to use setup_timer() instead of init_timer() Omar Sandoval (1): ext4: fix indirect punch hole corruption Theodore Ts'o (1): ext4: reserve codepoints used by the ext4 encryption feature Xiaoguang Wang (1): ext4: fix mmap data corruption in nodelalloc mode when blocksize < pagesize fs/ext4/ext4.h | 18 --- fs/ext4/indirect.c | 105 + fs/ext4/inode.c| 7 + fs/ext4/super.c| 31 -- fs/jbd2/recovery.c | 3 ++ 5 files changed, 108 insertions(+), 56 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/
Re: [PATCH] powerpc: re-enable dynticks
On Sun, 2015-02-22 at 23:13 +0100, Frederic Weisbecker wrote: > Yes that should work. After all "self-IPI" is an oxymoron. One would > expect an IPI to be triggered by an irq controller but if such > operation isn't supported with the current CPU being both source and > destination, anything triggering the desired callback in an interrupt > context in a reasonable amount of time ahead does the job here. We could do self-IPI on platforms that have an SMP-capable interrupt controller too but it would probably have higher overhead and would require verifying that the code for each of our different interrupt controllers is safe to be called from NMIs (hint: ioremap space isn't safe to access from NMIs for us on some CPU families...). We might be able to do better than using the decrementer on some CPUs by using local doorbells, but for now this will do. > I thought well that's what powerpc was doing for irq work but I wasn't > sure I understood the code correctly. I should have pinged people > about that, sorry. No worries, Cheers, Ben. -- 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] powerpc: re-enable dynticks
Hi Ben,
2015-02-16 5:06 GMT+01:00 Benjamin Herrenschmidt :
> On Mon, 2015-02-16 at 11:08 +1100, Michael Ellerman wrote:
>> On Fri, 2015-02-13 at 13:38 -0600, Paul Clarke wrote:
>> > implement arch_irq_work_has_interrupt() for powerpc
>> >
>> > Commit 9b01f5bf3 introduced a dependency on "IRQ work self-IPIs" for
>> > full dynamic ticks to be enabled, by expecting architectures to
>> > implement a suitable arch_irq_work_has_interrupt() routine.
>> >
>> > Several arches have implemented this routine, including x86 (3010279f)
>> > and arm (09f6edd4), but powerpc was omitted.
>> >
>> > This patch implements this routine for powerpc.
>> >
> .../...
>>
>> It makes the message change, but is that correct? ie. do we actually
>> implement
>> "IRQ work self-IPIs"?
>
> I think so... Fred, do you think what we do will work ? We hijack our
> decrementer (local timer) by making it shoot almost immediately (1 tick
> away) and run the irq work at the beginning of __timer_interrupt().
>
> At that point we are on our irq stack and have done irq_enter but that's
> about it.
Yes that should work. After all "self-IPI" is an oxymoron. One would
expect an IPI to be triggered by an irq controller but if such
operation isn't supported with the current CPU being both source and
destination, anything triggering the desired callback in an interrupt
context in a reasonable amount of time ahead does the job here.
I thought well that's what powerpc was doing for irq work but I wasn't
sure I understood the code correctly. I should have pinged people
about that, sorry.
Thanks.
>
> Cheers,
> Ben.
>
>> > diff --git a/arch/powerpc/include/asm/irq_work.h
>> > b/arch/powerpc/include/asm/irq_work.h
>> > new file mode 100644
>> > index 000..18365ec
>> > --- /dev/null
>> > +++ b/arch/powerpc/include/asm/irq_work.h
>> > @@ -0,0 +1,11 @@
>> > +#ifndef _ASM_IRQ_WORK_H
>> > +#define _ASM_IRQ_WORK_H
>> > +
>> > +#include
>> > +
>> > +static inline bool arch_irq_work_has_interrupt(void)
>> > +{
>> > + return 1;
>>
>> Should be "true";
>>
>> > +}
>>
>> cheers
>>
>>
>> ___
>> Linuxppc-dev mailing list
>> linuxppc-...@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
--
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: i8k: move driver from char to hwmon
On Sun, 22 Feb 2015 10:11:16 -0800, Guenter Roeck wrote: > I would still leave the driver name alone, though; the problem > is that "modprobe i8k" is mentioned in pretty much all references > to the driver. This might be solved with a module alias? You can pass any arbitrary string to MODULE_ALIAS(). This would still break insmod but pretty much everyone is calling modprobe to load kernel modules anyway. -- Jean Delvare SUSE L3 Support -- 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] livepatch: RCU protect struct klp_func all the time when used in klp_ftrace_handler()
On Wed, 18 Feb 2015, Petr Mladek wrote: > func->new_func has been accessed after rcu_read_unlock() in > klp_ftrace_handler() > and therefore the access was not protected. > > Signed-off-by: Petr Mladek Applied to for-3.20/upstream-fixes, thanks. -- 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/
Re: [PATCH] __aligned(size) is preferred over __attribute__((aligned(size)))
cFrom: Ameen Ali Date: Sun, 22 Feb 2015 23:40:36 +0200 > Signed-off-by: Ameen Ali Applied, but please use a proper Subject line next time, in particular you should put a proper subsystem prefix. In this case, "net: " would be an appropriate prefix. Otherwise people scanning the shortlog in the repository cannot tell where you are making your changes. What if we had 100 commits all doing this same transformation? It is the subsystem prefix that helps people see what is unique in each such change. -- 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] batman-adv: Fix use of seq_has_overflowed()
From: Joe Perches
Date: Sun, 22 Feb 2015 13:47:56 -0800
> net-next commit 6d91147d183c ("batman-adv: Remove uses of return value
> of seq_printf") incorrectly changed the overflow occurred return from
> -1 to 1. Change it back so that the test of batadv_write_buffer_text's
> return value in batadv_gw_client_seq_print_text works properly.
>
> Signed-off-by: Joe Perches
Applied, thanks Joe.
--
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 06/27] power: wakeup: Remove use of seq_printf return value
On Sun, 2015-02-22 at 22:38 +0100, Pavel Machek wrote:
> On Sat 2015-02-21 18:53:33, Joe Perches wrote:
> > The seq_printf return value, because it's frequently misused,
> > will eventually be converted to void.
> >
> > See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to
> > seq_has_overflowed() and make public")
>
> You've just removed overflow handling from
> print_wakeup_source_stats.
>
> Can you explain why that is good idea?
If overflow occurs, the seq_file subsystem allocates
a bigger buffer and calls the show function again.
See Al's comment in the 0/n patch and here:
https://lkml.org/lkml/2015/2/17/642
--
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: 3.19: Sony playstation controller causes kernel oops
[ some CCs added and full dmesg kept for reference ]
On Sun, 22 Feb 2015, Pavel Machek wrote:
> Hi!
>
> I plugged in part of PS move to the PC, to let it charge. Got: full
> dmesg in attachment. I believe I charged it in PC before, but it may
> be year ago or more.
>
> Ideas?
Ok, this is embarassing. I guess the patch below fixes it, right? (the
spinlock got introduced in d2d782fccee, so I guess you didn't have it a
year ago)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 31e9d25..3756a62 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -2140,6 +2140,7 @@ static int __init sony_init(void)
{
dbg_hid("Sony:%s\n", __func__);
+ spin_lock_init(_dev_list_lock);
return hid_register_driver(_driver);
}
> [124225.084151] usb 2-1: USB disconnect, device number 2
> [124227.240047] usb 2-1: new full-speed USB device number 3 using uhci_hcd
> [124227.519329] usb 2-1: New USB device found, idVendor=054c, idProduct=042f
> [124227.519335] usb 2-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [124227.519338] usb 2-1: Product: Navigation Controller
> [124227.519341] usb 2-1: Manufacturer: Sony
> [124227.599936] input: Sony Navigation Controller as
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/0003:054C:042F.0005/input/input50
> [124227.657352] sony 0003:054C:042F.0005: input,hiddev0,hidraw3: USB HID
> v1.11 Joystick [Sony Navigation Controller] on usb-:00:1d.0-1/input0
> [124227.692076] BUG: spinlock bad magic on CPU#0, kworker/0:0/15184
> [124227.692088] lock: sony_dev_list_lock+0x0/0x38, .magic: , .owner:
> /-1, .owner_cpu: 0
> [124227.692092] CPU: 0 PID: 15184 Comm: kworker/0:0 Tainted: GW
> 3.19.0 #17
> [124227.692094] Hardware name: /DG41MJ, BIOS
> MJG4110H.86A.0006.2009.1223.1155 12/23/2009
> [124227.692100] Workqueue: usb_hub_wq hub_event
> [124227.692103] 85b83800 880001153468 84949b24
> 0007
> [124227.692109] 880001153488 84081330
> 85b83800
> [124227.692114] 84d64cc0 8800011534a8 840813b1
> 85b83800
> [124227.692119] Call Trace:
> [124227.692125] [] dump_stack+0x45/0x57
> [124227.692131] [] spin_dump+0x80/0xe0
> [124227.692135] [] spin_bug+0x21/0x30
> [124227.692139] [] do_raw_spin_lock+0x12c/0x190
> [124227.692142] [] _raw_spin_lock_irqsave+0x3a/0x50
> [124227.692147] [] ? sony_probe+0x556/0xd60
> [124227.692151] [] sony_probe+0x556/0xd60
> [124227.692156] [] ? hid_match_id+0x2d/0x50
> [124227.692160] [] hid_device_probe+0xd4/0x150
> [124227.692165] [] ? driver_probe_device+0x3d0/0x3d0
> [124227.692169] [] driver_probe_device+0x8b/0x3d0
> [124227.692173] [] ? driver_probe_device+0x3d0/0x3d0
> [124227.692176] [] __device_attach+0x3b/0x40
> [124227.692180] [] bus_for_each_drv+0x63/0xa0
> [124227.692183] [] device_attach+0x90/0xb0
> [124227.692187] [] bus_probe_device+0xb0/0xe0
> [124227.692191] [] device_add+0x48d/0x660
> [124227.692195] [] hid_add_device+0xc1/0x290
> [124227.692199] [] ? __raw_spin_lock_init+0x31/0x60
> [124227.692203] [] usbhid_probe+0x327/0x480
> [124227.692208] [] usb_probe_interface+0x1d6/0x350
> [124227.692211] [] ? driver_probe_device+0x3d0/0x3d0
> [124227.692215] [] driver_probe_device+0x8b/0x3d0
> [124227.692219] [] ? driver_probe_device+0x3d0/0x3d0
> [124227.69] [] __device_attach+0x3b/0x40
> [124227.692226] [] bus_for_each_drv+0x63/0xa0
> [124227.692229] [] device_attach+0x90/0xb0
> [124227.692233] [] bus_probe_device+0xb0/0xe0
> [124227.692236] [] device_add+0x48d/0x660
> [124227.692240] [] usb_set_configuration+0x563/0x960
> [124227.692245] [] ? kernfs_add_one+0xe2/0x170
> [124227.692249] [] ? driver_probe_device+0x3d0/0x3d0
> [124227.692254] [] generic_probe+0x29/0x90
> [124227.692258] [] usb_probe_device+0x2d/0x80
> [124227.692262] [] driver_probe_device+0x8b/0x3d0
> [124227.692265] [] ? driver_probe_device+0x3d0/0x3d0
> [124227.692269] [] __device_attach+0x3b/0x40
> [124227.692272] [] bus_for_each_drv+0x63/0xa0
> [124227.692276] [] device_attach+0x90/0xb0
> [124227.692279] [] bus_probe_device+0xb0/0xe0
> [124227.692283] [] device_add+0x48d/0x660
> [124227.692286] [] usb_new_device+0x2b0/0x500
> [124227.692290] [] hub_event+0x886/0x1620
> [124227.692295] [] process_one_work+0x1ab/0x430
> [124227.692299] [] ? process_one_work+0x146/0x430
> [124227.692303] [] worker_thread+0x6b/0x480
> [124227.692307] [] ? cancel_delayed_work+0x80/0x80
> [124227.692311] [] kthread+0x100/0x120
> [124227.692315] [] ? kthread_create_on_node+0x230/0x230
> [124227.692319] [] ret_from_fork+0x7c/0xb0
> [124227.692323] [] ? kthread_create_on_node+0x230/0x230
--
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
[PATCH net-next] batman-adv: Fix use of seq_has_overflowed()
net-next commit 6d91147d183c ("batman-adv: Remove uses of return value
of seq_printf") incorrectly changed the overflow occurred return from
-1 to 1. Change it back so that the test of batadv_write_buffer_text's
return value in batadv_gw_client_seq_print_text works properly.
Signed-off-by: Joe Perches
---
sorry 'bout that.
I believe this won't have any real effect unless there
are something like 500+ entries in the gateway list.
net/batman-adv/gateway_client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/gateway_client.c b/net/batman-adv/gateway_client.c
index a0876ea..090828c 100644
--- a/net/batman-adv/gateway_client.c
+++ b/net/batman-adv/gateway_client.c
@@ -601,7 +601,7 @@ static int batadv_write_buffer_text(struct batadv_priv
*bat_priv,
gw_node->bandwidth_down % 10,
gw_node->bandwidth_up / 10,
gw_node->bandwidth_up % 10);
- ret = seq_has_overflowed(seq);
+ ret = seq_has_overflowed(seq) ? -1 : 0;
if (curr_gw)
batadv_gw_node_free_ref(curr_gw);
--
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] __aligned(size) is preferred over __attribute__((aligned(size)))
Signed-off-by: Ameen Ali
---
net/compat.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/compat.c b/net/compat.c
index 3236b41..49c6a8f 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -508,25 +508,25 @@ COMPAT_SYSCALL_DEFINE5(getsockopt, int, fd, int, level,
int, optname,
struct compat_group_req {
__u32gr_interface;
struct __kernel_sockaddr_storage gr_group
- __attribute__ ((aligned(4)));
+ __aligned(4);
} __packed;
struct compat_group_source_req {
__u32gsr_interface;
struct __kernel_sockaddr_storage gsr_group
- __attribute__ ((aligned(4)));
+ __aligned(4);
struct __kernel_sockaddr_storage gsr_source
- __attribute__ ((aligned(4)));
+ __aligned(4);
} __packed;
struct compat_group_filter {
__u32gf_interface;
struct __kernel_sockaddr_storage gf_group
- __attribute__ ((aligned(4)));
+ __aligned(4);
__u32gf_fmode;
__u32gf_numsrc;
struct __kernel_sockaddr_storage gf_slist[1]
- __attribute__ ((aligned(4)));
+ __aligned(4);
} __packed;
#define __COMPAT_GF0_SIZE (sizeof(struct compat_group_filter) - \
--
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 06/27] power: wakeup: Remove use of seq_printf return value
On Sat 2015-02-21 18:53:33, Joe Perches wrote:
> The seq_printf return value, because it's frequently misused,
> will eventually be converted to void.
>
> See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to
> seq_has_overflowed() and make public")
You've just removed overflow handling from
print_wakeup_source_stats. Can you explain why that is good idea?
Pavel
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -842,7 +842,6 @@ static int print_wakeup_source_stats(struct seq_file *m,
> unsigned long active_count;
> ktime_t active_time;
> ktime_t prevent_sleep_time;
> - int ret;
>
> spin_lock_irqsave(>lock, flags);
>
> @@ -865,17 +864,16 @@ static int print_wakeup_source_stats(struct seq_file *m,
> active_time = ktime_set(0, 0);
> }
>
> - ret = seq_printf(m, "%-12s\t%lu\t\t%lu\t\t%lu\t\t%lu\t\t"
> - "%lld\t\t%lld\t\t%lld\t\t%lld\t\t%lld\n",
> - ws->name, active_count, ws->event_count,
> - ws->wakeup_count, ws->expire_count,
> - ktime_to_ms(active_time), ktime_to_ms(total_time),
> - ktime_to_ms(max_time), ktime_to_ms(ws->last_time),
> - ktime_to_ms(prevent_sleep_time));
> + seq_printf(m,
> "%-12s\t%lu\t\t%lu\t\t%lu\t\t%lu\t\t%lld\t\t%lld\t\t%lld\t\t%lld\t\t%lld\n",
> +ws->name, active_count, ws->event_count,
> +ws->wakeup_count, ws->expire_count,
> +ktime_to_ms(active_time), ktime_to_ms(total_time),
> +ktime_to_ms(max_time), ktime_to_ms(ws->last_time),
> +ktime_to_ms(prevent_sleep_time));
>
> spin_unlock_irqrestore(>lock, flags);
>
> - return ret;
> + return 0;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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: NULL pointer dereference in i2c-hid
On Friday 09 January 2015 16:29:04 Andrew Duggan wrote: > On 01/09/2015 12:04 AM, Gabriele Mazzotta wrote: > > On Thursday 08 January 2015 15:58:54 Andrew Duggan wrote: > >> On 12/24/2014 03:53 PM, Gabriele Mazzotta wrote: > >> [...snip...] > >> Also, if you can get the firmware id from your touchpad that would also > >> be useful. > >> > >> $ sudo ./rmihidtool -f /dev/hidraw0 > > firmware id: 1522295 > Thanks, I will see if I can get any additional information on this. > > Andrew > >>> Hi, > >>> > >>> I think I found the source of the problem. > >>> > >>> $ ./rmihidtool /dev/hidraw1 -r 0x50 1 > >>> 0x01 #PalmDetect Interrupt Enable, right? > >> Yes, 0x50 does appear to be the address of the palm detect interrupt > >> enable register. > >>> $ ./rmihidtool /dev/hidraw1 -w 0x50 0 #Disable PalmDetect Interrupt > >>> > >>> It makes more sense now that widths greater than 12 trigger the bug. > >> That is weird behavior and I haven't seen anything like that before. I > >> will file a bug to see if firmware has any idea why this is happening. > > According to the RMI4 specification, gesture interrupts are cleared > > only once specific flag registers, F11_2D_Data8 and F11_2D_Data9, are > > read. So I tried to read those register and found that the following > > command stops the events: > > It is unusual to see firmware gestures enabled for HID/I2C touchpads. In > fact none of the touchpads I have have that functionality enabled, which > is why I haven't been able to test. On HID touchpads there is a layer in > the firmware which reads the RMI registers and packs them into the HID > attention report. My guess is that the HID layer is not reading > F11_2D_Data8 or 9 causing it to assert indefinitely. Since this isn't a > common firmware configuration that is probably why this hasn't been > observed before. > > > $ rmihidtool /dev/hidraw1 -r 0x24 1 # I was looking for F11_2D_Data8 > > > > I'm not sure I got the right address as reading any register close to > > 0x24 (such as 0x25, 0x26) has the same effect. I would have expected > > this to happen only reading one specific register. > > With this firmware, F11_2D_Data8 should be at 0x3A. It's 2 bytes for > finger state + 5 bytes per finger * 5 fingers for abs data + 2 bytes > per finger * 5 fingers for rel data. I'm not sure why reading 0x24 would > stop the reports though. > > > > > I also honestly don't know why palms are detected when the width is at > > least 12, PalmDetectThreshold is 0 and so the palm detection should > > be inhibited. > > > > This seems to be set in the firmware config. It looks like > PalmDetectThreshold is only used when the reporting mode is 001. The > default reporting mode looks like it is 000. Hi Andrew, is there any plan on implementing a function to write registers? This would allow me to easily disable the PalmDetect Interrupt when the driver is loaded without relying on external tools. Reading F11_2D_Data8 continuously seems unnecessary. Not totally related. Is there any use for the dribble interrupts? I'm wondering if they could be disabled by default. I'm my case these interrupts go on for about a second, making the I2C host controller generate a lot of interrupts. A quick tap for example make INT33C3 generate more than 5000 interrupts when dribbling is enabled and less than 200 interrupts when disabled. The difference is not really insignificant, so if they have no real use, I'd disable them by default in order to save some power. Regards, Gabriele -- 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/
3.19: Sony playstation controller causes kernel oops
Hi! I plugged in part of PS move to the PC, to let it charge. Got: full dmesg in attachment. I believe I charged it in PC before, but it may be year ago or more. Ideas? Pavel [124225.084151] usb 2-1: USB disconnect, device number 2 [124227.240047] usb 2-1: new full-speed USB device number 3 using uhci_hcd [124227.519329] usb 2-1: New USB device found, idVendor=054c, idProduct=042f [124227.519335] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [124227.519338] usb 2-1: Product: Navigation Controller [124227.519341] usb 2-1: Manufacturer: Sony [124227.599936] input: Sony Navigation Controller as /devices/pci:00/:00:1d.0/usb2/2-1/2-1:1.0/0003:054C:042F.0005/input/input50 [124227.657352] sony 0003:054C:042F.0005: input,hiddev0,hidraw3: USB HID v1.11 Joystick [Sony Navigation Controller] on usb-:00:1d.0-1/input0 [124227.692076] BUG: spinlock bad magic on CPU#0, kworker/0:0/15184 [124227.692088] lock: sony_dev_list_lock+0x0/0x38, .magic: , .owner: /-1, .owner_cpu: 0 [124227.692092] CPU: 0 PID: 15184 Comm: kworker/0:0 Tainted: GW 3.19.0 #17 [124227.692094] Hardware name: /DG41MJ, BIOS MJG4110H.86A.0006.2009.1223.1155 12/23/2009 [124227.692100] Workqueue: usb_hub_wq hub_event [124227.692103] 85b83800 880001153468 84949b24 0007 [124227.692109] 880001153488 84081330 85b83800 [124227.692114] 84d64cc0 8800011534a8 840813b1 85b83800 [124227.692119] Call Trace: [124227.692125] [] dump_stack+0x45/0x57 [124227.692131] [] spin_dump+0x80/0xe0 [124227.692135] [] spin_bug+0x21/0x30 [124227.692139] [] do_raw_spin_lock+0x12c/0x190 [124227.692142] [] _raw_spin_lock_irqsave+0x3a/0x50 [124227.692147] [] ? sony_probe+0x556/0xd60 [124227.692151] [] sony_probe+0x556/0xd60 [124227.692156] [] ? hid_match_id+0x2d/0x50 [124227.692160] [] hid_device_probe+0xd4/0x150 [124227.692165] [] ? driver_probe_device+0x3d0/0x3d0 [124227.692169] [] driver_probe_device+0x8b/0x3d0 [124227.692173] [] ? driver_probe_device+0x3d0/0x3d0 [124227.692176] [] __device_attach+0x3b/0x40 [124227.692180] [] bus_for_each_drv+0x63/0xa0 [124227.692183] [] device_attach+0x90/0xb0 [124227.692187] [] bus_probe_device+0xb0/0xe0 [124227.692191] [] device_add+0x48d/0x660 [124227.692195] [] hid_add_device+0xc1/0x290 [124227.692199] [] ? __raw_spin_lock_init+0x31/0x60 [124227.692203] [] usbhid_probe+0x327/0x480 [124227.692208] [] usb_probe_interface+0x1d6/0x350 [124227.692211] [] ? driver_probe_device+0x3d0/0x3d0 [124227.692215] [] driver_probe_device+0x8b/0x3d0 [124227.692219] [] ? driver_probe_device+0x3d0/0x3d0 [124227.69] [] __device_attach+0x3b/0x40 [124227.692226] [] bus_for_each_drv+0x63/0xa0 [124227.692229] [] device_attach+0x90/0xb0 [124227.692233] [] bus_probe_device+0xb0/0xe0 [124227.692236] [] device_add+0x48d/0x660 [124227.692240] [] usb_set_configuration+0x563/0x960 [124227.692245] [] ? kernfs_add_one+0xe2/0x170 [124227.692249] [] ? driver_probe_device+0x3d0/0x3d0 [124227.692254] [] generic_probe+0x29/0x90 [124227.692258] [] usb_probe_device+0x2d/0x80 [124227.692262] [] driver_probe_device+0x8b/0x3d0 [124227.692265] [] ? driver_probe_device+0x3d0/0x3d0 [124227.692269] [] __device_attach+0x3b/0x40 [124227.692272] [] bus_for_each_drv+0x63/0xa0 [124227.692276] [] device_attach+0x90/0xb0 [124227.692279] [] bus_probe_device+0xb0/0xe0 [124227.692283] [] device_add+0x48d/0x660 [124227.692286] [] usb_new_device+0x2b0/0x500 [124227.692290] [] hub_event+0x886/0x1620 [124227.692295] [] process_one_work+0x1ab/0x430 [124227.692299] [] ? process_one_work+0x146/0x430 [124227.692303] [] worker_thread+0x6b/0x480 [124227.692307] [] ? cancel_delayed_work+0x80/0x80 [124227.692311] [] kthread+0x100/0x120 [124227.692315] [] ? kthread_create_on_node+0x230/0x230 [124227.692319] [] ret_from_fork+0x7c/0xb0 [124227.692323] [] ? kthread_create_on_node+0x230/0x230 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html delme.gz Description: application/gzip
Re: [PATCH] ARM: bcm2835: Add header file for pinctrl constants
On Sun, Feb 22, 2015 at 09:13:23PM +0100, Arnd Bergmann wrote: > On Sunday 22 February 2015 16:59:56 Charles Keepax wrote: > > + > > +/* IRQ Flags */ > > +#define BCM2835_PIN_IRQ_RISING 1 > > +#define BCM2835_PIN_IRQ_FALLING2 > > +#define BCM2835_PIN_IRQ_EDGE (BCM2835_PIN_IRQ_RISING | \ > > +BCM2835_PIN_IRQ_FALLING) > > +#define BCM2835_PIN_IRQ_LOW4 > > +#define BCM2835_PIN_IRQ_HIGH 8 > > Are these different from the standard definitions? > > > +/* Pin Function Settings */ > > +#define BCM2835_PIN_FUNC_GPIO_IN 0 > > +#define BCM2835_PIN_FUNC_GPIO_OUT 1 > > +#define BCM2835_PIN_FUNC_ALT5 2 > > +#define BCM2835_PIN_FUNC_ALT4 3 > > +#define BCM2835_PIN_FUNC_ALT0 4 > > +#define BCM2835_PIN_FUNC_ALT1 5 > > +#define BCM2835_PIN_FUNC_ALT2 6 > > +#define BCM2835_PIN_FUNC_ALT3 7 > > Why are these required? They don't seem to be used by any driver, > which leads me to suspect that they are just the hardware numbers. > > In that case, don't add any syntactical sugar like that and just > use the hardware numbers directly. Yeah they are just hardware numbers, I wasn't aware there was a preference to use the numbers directly in which case just ignore this patch. > > What's with the strange mapping of numbers anyway? You would need to ask Broadcom that :-) Thanks, Charles -- 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] rhashtable: initialize all rhashtable walker members
From: Sasha Levin Date: Sun, 22 Feb 2015 16:28:05 -0500 > On 02/22/2015 03:58 PM, David Miller wrote: >> From: Sasha Levin >> Date: Sat, 21 Feb 2015 15:55:11 -0500 >> >>> Commit "rhashtable: Introduce rhashtable_walk_*" forgot to initialize the >>> members of struct rhashtable_walker after allocating it, which caused >>> an undefined value for 'resize' which is used later on. >>> >>> Signed-off-by: Sasha Levin >> >> Commits should be referred to by SHA1 ID as well as the commit >> header text (in parenthesis and double quotes). > > It wasn't (isn't?) in Linus' tree yet, so I didn't want to refer to > it by a SHA1 ID which would change. Commit IDs in my tree _NEVER_ change. -- 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] rhashtable: initialize all rhashtable walker members
On 02/22/2015 03:58 PM, David Miller wrote: > From: Sasha Levin > Date: Sat, 21 Feb 2015 15:55:11 -0500 > >> Commit "rhashtable: Introduce rhashtable_walk_*" forgot to initialize the >> members of struct rhashtable_walker after allocating it, which caused >> an undefined value for 'resize' which is used later on. >> >> Signed-off-by: Sasha Levin > > Commits should be referred to by SHA1 ID as well as the commit > header text (in parenthesis and double quotes). It wasn't (isn't?) in Linus' tree yet, so I didn't want to refer to it by a SHA1 ID which would change. > Even better, refer to the commit using a "Fixes: " tag right before > your signoff. Ok, should I resend? 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 v7 7/7] powerpc/perf/hv-24x7: Document sysfs event description entries
On Fri, Jan 30, 2015 at 4:46 PM, Sukadev Bhattiprolu wrote: > From: Cody P Schafer > > Signed-off-by: Cody P Schafer > Signed-off-by: Sukadev Bhattiprolu > --- > Changelog[v6] > Update Contact info to Linux on Power Developer list > > .../testing/sysfs-bus-event_source-devices-hv_24x7 | 22 > ++ > 1 file changed, 22 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 > b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 > index 32f3f5f..f893337 100644 > --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 > +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 > @@ -21,3 +21,25 @@ Contact: Linux on PowerPC Developer List > > Description: > Exposes the "version" field of the 24x7 catalog. This is also > extractable from the provided binary "catalog" sysfs entry. > + > +What: /sys/bus/event_source/devices/hv_24x7/event_descs/ > +Date: February 2014 > +Contact: Linux on PowerPC Developer List > > +Description: > + Provides the description of a particular event as provided by > + the firmware. If firmware does not provide a description, no > + file will be created. > + > + Note that the event-name lacks the domain suffix appended for > + events in the events/ dir. I'm probably a bit late on this, but: Please consider removing the need for a user to know about the "domain suffixes" (which, as far as I know are 24x7 specific). If anyone else ever wants to add firmware/hardware/kernel provided event descriptions, they'll need to special case these ones as they don't match up with the actual event names. -- 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] rhashtable: initialize all rhashtable walker members
On 02/21/2015 09:55 PM, Sasha Levin wrote: Commit "rhashtable: Introduce rhashtable_walk_*" forgot to initialize the members of struct rhashtable_walker after allocating it, which caused an undefined value for 'resize' which is used later on. Signed-off-by: Sasha Levin --- lib/rhashtable.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index 9cc4c4a..030484c 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -894,6 +894,9 @@ int rhashtable_walk_init(struct rhashtable *ht, struct rhashtable_iter *iter) if (!iter->walker) return -ENOMEM; + INIT_LIST_HEAD(>walker->list); + iter->walker->resize = false; + The change seems fine to me, although the INIT_LIST_HEAD() unnecessary due to the below list_add()? Anyway, setting resize to false is definitely correct. In practice this shouldn't cause much issue though as rhashtable_walk_start() would only reset iterator meta data and set resize to false, but lets fix it. mutex_lock(>mutex); list_add(>walker->list, >walkers); mutex_unlock(>mutex); Thanks, Daniel -- 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] perf: Implement read_group() PMU operation
On Thu, Feb 5, 2015 at 9:59 PM, Sukadev Bhattiprolu
wrote:
> From: Sukadev Bhattiprolu
> Date: Thu Feb 5 20:56:20 EST 2015 -0300
> Subject: [RFC][PATCH] perf: Implement read_group() PMU operation
>
> This is a lightly tested, exploratory patch to allow PMUs to return
> several counters at once. Appreciate any comments :-)
>
Back when I was fiddling with this, I started looking into changing
the {start,commit,cancel}_txn to operate on (struct perf_event *)
rather than (struct pmu *), and commit_txn would generate the actual
request & reads based on the perf_event's group (sounds similar but
not identical to what Peter's proposed previously).
The key bit I was concerned about was that these "PMUs" aren't
actually physical hw, so it made a bit more sense to pin the grouping
to a group rather than a txn over a PMU.
[Of course, I never did confirm if that actually fit with how perf was
modeling txns]
--
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] rhashtable: initialize all rhashtable walker members
From: Sasha Levin Date: Sat, 21 Feb 2015 15:55:11 -0500 > Commit "rhashtable: Introduce rhashtable_walk_*" forgot to initialize the > members of struct rhashtable_walker after allocating it, which caused > an undefined value for 'resize' which is used later on. > > Signed-off-by: Sasha Levin Commits should be referred to by SHA1 ID as well as the commit header text (in parenthesis and double quotes). Even better, refer to the commit using a "Fixes: " tag right before your signoff. -- 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: 1e918876 breaks r8169 (linux-3.18+)
From: Tomas Szepe
Date: Sun, 22 Feb 2015 01:41:51 +0100
>> > Sure, just did. Unfortunately, 3.19.0 + 0bec3b70 + this patch results
>> > in a driver that retains the problem.
>>
>> OK, could you test following patch instead ?
>
> Yup, but tough luck: 3.19.0 + 0bec3b70 + this patch -> problem present.
I'm reverting the two commits for now, as below.
We can put them back in if we can resolve the problems.
[PATCH] r8169: Revert BQL and xmit_more support.
There are certain regressions which are pointing to
these two commits which we are having a hard time
resolving. So revert them for now.
Specifically this reverts:
commit 0bec3b700d106a8b0a34227b2976d1a582f1aab7
Author: Florian Westphal
Date: Wed Jan 7 10:49:49 2015 +0100
r8169: add support for xmit_more
and
commit 1e918876853aa85435e0f17fd8b4a92dcfff53d6
Author: Florian Westphal
Date: Wed Oct 1 13:38:03 2014 +0200
r8169: add support for Byte Queue Limits
There were some attempts by Eric Dumazet to address some obvious
problems in the TX flow, to see if they would fix the problems,
but none of them seem to help for the regression reporters.
Signed-off-by: David S. Miller
---
drivers/net/ethernet/realtek/r8169.c | 30 +++---
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index ad0020a..b156092 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5067,8 +5067,6 @@ static void rtl_hw_reset(struct rtl8169_private *tp)
RTL_W8(ChipCmd, CmdReset);
rtl_udelay_loop_wait_low(tp, _chipcmd_cond, 100, 100);
-
- netdev_reset_queue(tp->dev);
}
static void rtl_request_uncached_firmware(struct rtl8169_private *tp)
@@ -7049,7 +7047,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
u32 status, len;
u32 opts[2];
int frags;
- bool stop_queue;
if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
netif_err(tp, drv, dev, "BUG! Tx Ring full when queue
awake!\n");
@@ -7090,8 +7087,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
txd->opts2 = cpu_to_le32(opts[1]);
- netdev_sent_queue(dev, skb->len);
-
skb_tx_timestamp(skb);
/* Force memory writes to complete before releasing descriptor */
@@ -7106,16 +7101,11 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff
*skb,
tp->cur_tx += frags + 1;
- stop_queue = !TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS);
+ RTL_W8(TxPoll, NPQ);
- if (!skb->xmit_more || stop_queue ||
- netif_xmit_stopped(netdev_get_tx_queue(dev, 0))) {
- RTL_W8(TxPoll, NPQ);
-
- mmiowb();
- }
+ mmiowb();
- if (stop_queue) {
+ if (!TX_FRAGS_READY_FOR(tp, MAX_SKB_FRAGS)) {
/* Avoid wrongly optimistic queue wake-up: rtl_tx thread must
* not miss a ring update when it notices a stopped queue.
*/
@@ -7198,7 +7188,6 @@ static void rtl8169_pcierr_interrupt(struct net_device
*dev)
static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp)
{
unsigned int dirty_tx, tx_left;
- unsigned int bytes_compl = 0, pkts_compl = 0;
dirty_tx = tp->dirty_tx;
smp_rmb();
@@ -7222,8 +7211,10 @@ static void rtl_tx(struct net_device *dev, struct
rtl8169_private *tp)
rtl8169_unmap_tx_skb(>pci_dev->dev, tx_skb,
tp->TxDescArray + entry);
if (status & LastFrag) {
- pkts_compl++;
- bytes_compl += tx_skb->skb->len;
+ u64_stats_update_begin(>tx_stats.syncp);
+ tp->tx_stats.packets++;
+ tp->tx_stats.bytes += tx_skb->skb->len;
+ u64_stats_update_end(>tx_stats.syncp);
dev_kfree_skb_any(tx_skb->skb);
tx_skb->skb = NULL;
}
@@ -7232,13 +7223,6 @@ static void rtl_tx(struct net_device *dev, struct
rtl8169_private *tp)
}
if (tp->dirty_tx != dirty_tx) {
- netdev_completed_queue(tp->dev, pkts_compl, bytes_compl);
-
- u64_stats_update_begin(>tx_stats.syncp);
- tp->tx_stats.packets += pkts_compl;
- tp->tx_stats.bytes += bytes_compl;
- u64_stats_update_end(>tx_stats.syncp);
-
tp->dirty_tx = dirty_tx;
/* Sync with rtl8169_start_xmit:
* - publish dirty_tx ring index (write barrier)
--
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
Re: SATA link power management issues
Hi,
It seems that the following patch prevents errors when the policy is
changed. Could anybody explain why?
Thanks,
Gabriele
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 61a9c07..38d39f7 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1708,7 +1708,10 @@ static void ahci_handle_port_interrupt(struct ata_port
*ap,
status &= ~PORT_IRQ_BAD_PMP;
/* if LPM is enabled, PHYRDY doesn't mean anything */
- if (ap->link.lpm_policy > ATA_LPM_MAX_POWER) {
+ if (ap->link.lpm_policy > ATA_LPM_MAX_POWER ||
+ ap->link.flags & ATA_LFLAG_CHANGED) {
+ if (ap->link.flags & ATA_LFLAG_CHANGED)
+ ap->link.flags &= ~ATA_LFLAG_CHANGED;
status &= ~PORT_IRQ_PHYRDY;
ahci_scr_write(>link, SCR_ERROR, SERR_PHYRDY_CHG);
}
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index d2029a4..e8f965c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -3489,6 +3489,8 @@ static int ata_eh_set_lpm(struct ata_link *link, enum
ata_lpm_policy policy,
}
}
+ link->flags |= ATA_LFLAG_CHANGED;
+
return 0;
fail:
diff --git a/include/linux/libata.h b/include/linux/libata.h
index fc03efa..5abf5f2 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -205,6 +205,7 @@ enum {
ATA_LFLAG_SW_ACTIVITY = (1 << 7), /* keep activity stats */
ATA_LFLAG_NO_LPM= (1 << 8), /* disable LPM on this link */
ATA_LFLAG_RST_ONCE = (1 << 9), /* limit recovery to one reset */
+ ATA_LFLAG_CHANGED = (1 << 10),
/* struct ata_port flags */
ATA_FLAG_SLAVE_POSS = (1 << 0), /* host supports slave dev */
--
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/
sun7i: suspicious crash since d347efeb16
Hi, I'm getting the follow crash on a banana-pi with upstream kernels since "mutex: remove unused field "name" in debug mode" (d347efeb16): [2.871658] Unable to handle kernel paging request at virtual address bd809e64 [2.878936] pgd = c0004000 [2.881657] [bd809e64] *pgd= [2.885272] Internal error: Oops: 5 [#1] SMP ARM [2.889907] Modules linked in: [2.892997] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.19.0-05375-gd347efe #51 [2.900330] Hardware name: Allwinner sun7i (A20) Family [2.905575] task: de10 ti: de0b6000 task.ti: de0b6000 [2.911005] PC is at sunxi_sc_nmi_set_type+0x104/0x174 [2.916163] LR is at 0xc [2.918713] pc : []lr : [<000c>]psr: 6193 [2.918713] sp : de0b7ab8 ip : 0002 fp : de0b7adc [2.930221] r10: c1102914 r9 : 0008 r8 : de005e50 [2.935465] r7 : de15b600 r6 : de005e34 r5 : r4 : de005c18 [2.942012] r3 : bd809e64 r2 : 0002 r1 : c090959d r0 : [2.948563] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [2.955984] Control: 10c5387d Table: 4000406a DAC: 0015 [2.961749] Process swapper/0 (pid: 1, stack limit = 0xde0b6210) [2.967775] Stack: (0xde0b7ab8 to 0xde0b8000) [2.972151] 7aa0: 0053 de15b600 [2.980360] 7ac0: de005c7c 0008 0053 de0b7b04 de0b7ae0 c0084b34 c02fb9a8 [2.988568] 7ae0: 0053 de15b600 0008 c08ea118 c08ed9fc de0b7b2c de0b7b08 [2.996777] 7b00: c0085fa4 c0084ad0 c0082748 6113 de0b7b2c 0053 0008 dd5dc020 [3.004986] 7b20: de0b7b54 de0b7b30 c0089a18 c0085f68 de0b7b38 de0b7b3c 0008 [3.013195] 7b40: dd5dc000 c1102958 de0b7bac de0b7b58 c04190e4 c00898d8 de772ea8 0002 [3.021404] 7b60: 0008 c08ed9fc c1102914 de0b7ba4 de0b7b80 c01c58ec c01c20cc [3.029613] 7b80: dd5dc020 dd5dc028 c08ea118 c08ed9fc de0b7bb4 c03e6a40 [3.037822] 7ba0: de0b7bd4 de0b7bb0 c03e6a64 c04190ac dd5dc020 c1102958 [3.046031] 7bc0: c08ea118 c08ed9fc de0b7bfc de0b7bd8 c034e984 c03e6a30 c08ea118 dd5dc020 [3.054240] 7be0: c034eacc dd5d0108 c08ed9fc de0b7c14 de0b7c00 c034eb04 c034e8c8 [3.062449] 7c00: dd5dc020 de0b7c3c de0b7c18 c034cf28 c034ead8 de1d68d4 de327c54 [3.070658] 7c20: dd5d0108 dd5dc020 c08eda2c dd5dc054 de0b7c5c de0b7c40 c034e868 c034cea0 [3.078867] 7c40: dd5dc020 c08eda2c dd5dc020 dd5d0108 de0b7c7c de0b7c60 c034de60 c034e7fc [3.087076] 7c60: dd5dc020 dd5dc028 dd5d0108 de0b7cbc de0b7c80 c034c0ec c034de34 [3.095285] 7c80: dd5dc020 c1102914 dd5dc004 de0b7cbc dd5dc020 dd5dc020 dd5d00b0 [3.103494] 7ca0: dd5dc004 dd5d0108 000b 016e3600 de0b7cd4 de0b7cc0 c034c220 c034bd28 [3.111704] 7cc0: dd5dc000 dd5dc020 de0b7d0c de0b7cd8 c03e934c c034c208 dd5d00b0 dd5d0108 [3.119912] 7ce0: de77cf34 0034 dd5d00b0 dd5d0108 de77cf34 [3.128121] 7d00: de0b7d64 de0b7d10 c03e9888 c03e9228 6113 0004 [3.132166] ata1: SATA link down (SStatus 0 SControl 300) [3.141739] 7d20: 32707861 3930 0034 de0b7d18 [3.149948] 7d40: de77cf34 dd5d00b0 de77cc40 de0b7d84 de0b7d68 [3.158158] 7d60: c03e9cc4 c03e958c 00d0 dd5d0010 dd5d0010 de0b7d94 de0b7d88 [3.166367] 7d80: c03e9d00 c03e9c38 de0b7de4 de0b7d98 c03eb394 c03e9ce8 c0774693 dd5d0010 [3.174575] 7da0: 0014 7fff 00f0 000186a0 de1df010 000186a0 de1df018 ffed [3.182785] 7dc0: de1df010 c08edf60 c08edf60 c0908640 de0b7e04 de0b7de8 [3.190993] 7de0: c0350c4c c03eb028 de1df010 c1102958 de0b7e2c de0b7e08 [3.199202] 7e00: c034e984 c0350c00 de1df010 de1df044 c08edf60 c08e8918 c0908640 [3.207411] 7e20: de0b7e4c de0b7e30 c034eba0 c034e8c8 c08edf60 c034eb20 c08e8918 [3.215620] 7e40: de0b7e74 de0b7e50 c034ce44 c034eb2c de14aea4 de1b5850 de14aed4 c08edf60 [3.223829] 7e60: de378000 de0b7e84 de0b7e78 c034e47c c034cdd4 de0b7eac de0b7e88 [3.232039] 7e80: c034e0c8 c034e460 c0774693 de0b7e98 c08edf60 c0866298 c08b3760 c08b3760 [3.240248] 7ea0: de0b7ec4 de0b7eb0 c034fafc c034dfe0 dd5f7040 c0866298 de0b7ed4 de0b7ec8 [3.248457] 7ec0: c0350b68 c034fa5c de0b7ee4 de0b7ed8 c08662b0 c0350b1c de0b7f5c de0b7ee8 [3.25] 7ee0: c0008a74 c08662a4 c0073764 c0073588 de0b7f2c c00455e8 de0b7f00 de0b7f08 [3.264875] 7f00: c0838600 c02d333c de76c231 de76c229 de0b7f5c de0b7f20 c0045828 c08385f0 [3.273083] 7f20: 00a2 0006 0006 00a3 c08bb590 0006 00a3 0006 [3.281292] 7f40: 00a3 c08854e0 c08a8ab8 c0908640 de0b7f94 de0b7f60 c0838f4c c000896c [3.289500] 7f60: 0006 0006 c08385e4 c05d5108 [
Re: [GIT PULL] time/ntp fix
Hi Ingo,
On Sat, Feb 21, 2015 at 6:49 AM, Ingo Molnar wrote:
> * John Stultz wrote:
>
>> On Fri, Feb 20, 2015 at 2:26 PM, Linus Torvalds
>> wrote:
>> > On Fri, Feb 20, 2015 at 5:44 AM, Ingo Molnar wrote:
>> >>
>> >> John Stultz (1):
>> >> ntp: Fixup adjtimex freq validation on 32-bit systems
>> >
>> > This is confusing. 32-bit?
>>
>> Right, so the check that was added in a previous commit
>> is really only a concern for 64bit systems, but was
>> applied to both 32 and 64bit systems, which results in
>> breaking 32bit systems.
>>
>> Thus the "fix" here is to make the check only apply to
>> 64bit systems.
>
> Yeah, perhaps a better commit title would have been to
> write:
>
> time/ntp: Fix adjtimex freq validation code build warning on 32-bit
> systems
>
> To make it clear that the problem fixed is a 32-bit
> warning, and that the fix for that is to only check on
> 64-bit systems.
>
> I agreed with your BITS_PER_LONG check when I reviewed your
> patch, people usually do an ugly #ifdef, I think this
> in line check form is nicer.
Unfortunately it doesn't help with all compiler versions.
With gcc 4.1.2 for m68k:
kernel/time/ntp.c: In function ‘ntp_validate_timex’:
kernel/time/ntp.c:641: warning: comparison is always false due to
limited range of data type
kernel/time/ntp.c:643: warning: comparison is always false due to
limited range of data type
Gcc 4.6.3 and 4.9.0 are OK (for m68k).
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 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 6/7 linux-next] wan: cosa: replace current->state by set_current_state()
From: Fabian Frederick Date: Fri, 20 Feb 2015 19:12:56 +0100 > Use helper functions to access current->state. > Direct assignments are prone to races and therefore buggy. > > current->state = TASK_RUNNING is replaced by __set_current_state() > > Thanks to Peter Zijlstra for the exact definition of the problem. > > Suggested-By: Peter Zijlstra > Signed-off-by: Fabian Frederick Applied. -- 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 5/7 linux-next] hso: replace current->state by __set_current_state()
From: Fabian Frederick Date: Fri, 20 Feb 2015 19:12:55 +0100 > Use helper functions to access current->state. > Direct assignments are prone to races and therefore buggy. > > Thanks to Peter Zijlstra for the exact definition of the problem. > > Suggested-By: Peter Zijlstra > Signed-off-by: Fabian Frederick Applied. -- 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/7 linux-next] mISDN: replace current->state by set_current_state()
From: Fabian Frederick Date: Fri, 20 Feb 2015 19:12:52 +0100 > Use helper function to access current->state. > Direct assignments are prone to races and therefore buggy. > > Thanks to Peter Zijlstra for the exact definition of the problem. > > Signed-off-by: Fabian Frederick Applied. -- 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] ARM: bcm2835: Add header file for pinctrl constants
On Sunday 22 February 2015 16:59:56 Charles Keepax wrote: > + > +/* IRQ Flags */ > +#define BCM2835_PIN_IRQ_RISING 1 > +#define BCM2835_PIN_IRQ_FALLING2 > +#define BCM2835_PIN_IRQ_EDGE (BCM2835_PIN_IRQ_RISING | \ > +BCM2835_PIN_IRQ_FALLING) > +#define BCM2835_PIN_IRQ_LOW4 > +#define BCM2835_PIN_IRQ_HIGH 8 Are these different from the standard definitions? > +/* Pin Function Settings */ > +#define BCM2835_PIN_FUNC_GPIO_IN 0 > +#define BCM2835_PIN_FUNC_GPIO_OUT 1 > +#define BCM2835_PIN_FUNC_ALT5 2 > +#define BCM2835_PIN_FUNC_ALT4 3 > +#define BCM2835_PIN_FUNC_ALT0 4 > +#define BCM2835_PIN_FUNC_ALT1 5 > +#define BCM2835_PIN_FUNC_ALT2 6 > +#define BCM2835_PIN_FUNC_ALT3 7 Why are these required? They don't seem to be used by any driver, which leads me to suspect that they are just the hardware numbers. In that case, don't add any syntactical sugar like that and just use the hardware numbers directly. What's with the strange mapping of numbers anyway? Arnd -- 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] CRISv10: remove redundant macros from system.h
All of these are either unused or already provided by other headers, so
they can be removed.
Signed-off-by: Rabin Vincent
---
Should be applied before the patch which uses the generic atomic bitops to
ensure that CRISv10 is bisectable.
arch/cris/include/arch-v10/arch/system.h | 8
1 file changed, 8 deletions(-)
diff --git a/arch/cris/include/arch-v10/arch/system.h
b/arch/cris/include/arch-v10/arch/system.h
index 935fde3..9b5580f 100644
--- a/arch/cris/include/arch-v10/arch/system.h
+++ b/arch/cris/include/arch-v10/arch/system.h
@@ -36,12 +36,4 @@ static inline unsigned long _get_base(char * addr)
return 0;
}
-#define nop() __asm__ __volatile__ ("nop");
-
-#define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned
long)(x),(ptr),sizeof(*(ptr
-#define tas(ptr) (xchg((ptr),1))
-
-struct __xchg_dummy { unsigned long a[100]; };
-#define __xg(x) ((struct __xchg_dummy *)(x))
-
#endif
--
2.1.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/
