[PATCH v2 2/4] staging: rtl8192u: Removed unnecessary whitespace & tab warning in r819xU_phy.c
From: sanjeev sharma
This is a patch to the r819xU_phy.c file that remove unnecessary whitespace
and tabs reported by checkpatch.pl script.
Signed-off-by: Sanjeev Sharma
---
drivers/staging/rtl8192u/r819xU_phy.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_phy.c
b/drivers/staging/rtl8192u/r819xU_phy.c
index 0bcdd4e..0fcb673 100644
--- a/drivers/staging/rtl8192u/r819xU_phy.c
+++ b/drivers/staging/rtl8192u/r819xU_phy.c
@@ -106,10 +106,10 @@ void rtl8192_setBBreg(struct net_device *dev, u32
reg_addr, u32 bitmask,
/**
* function: This function reads specific bits from BB register
* input: net_device *dev
- *u32 reg_addr //target addr to be readback
- *u32 bitmask//taget bit pos to be readback
- * output:none
- * return:u32 data //the readback register value
+ * u32 reg_addr //target addr to be readback
+ * u32 bitmask//taget bit pos to be readback
+ * output: none
+ * return: u32 data //the readback register value
* notice:
**/
u32 rtl8192_QueryBBReg(struct net_device *dev, u32 reg_addr, u32 bitmask)
@@ -478,9 +478,9 @@ static void phy_FwRFSerialWrite(struct net_device *dev,
/**
* function: This function reads BB parameters from header file we generate,
*and do register read/write
- * input: net_device *dev
- * output:none
- * return:none
+ * input: net_device *dev
+ * output: none
+ * return: none
* notice:BB parameters may change all the time, so please make
*sure it has been synced with the newest.
*/
@@ -900,7 +900,7 @@ void rtl8192_phy_getTxPower(struct net_device *dev)
read_nic_byte(dev, rOFDM0_RxDetector3, >framesync);
read_nic_byte(dev, rOFDM0_RxDetector2, );
priv->framesyncC34 = tmp;
- RT_TRACE(COMP_INIT, "Default framesync (0x%x) = 0x%x \n",
+ RT_TRACE(COMP_INIT, "Default framesync (0x%x) = 0x%x\n",
rOFDM0_RxDetector3, priv->framesync);
/* Read SIFS (save the value read fome MACPHY_REG.txt) */
@@ -1463,6 +1463,7 @@ void rtl8192_SwChnl_WorkItem(struct net_device *dev)
u8 rtl8192_phy_SwChnl(struct net_device *dev, u8 channel)
{
struct r8192_priv *priv = ieee80211_priv(dev);
+
RT_TRACE(COMP_CH, "%s(), SwChnlInProgress: %d\n", __func__,
priv->SwChnlInProgress);
if (!priv->up)
@@ -1745,13 +1746,13 @@ void InitialGainOperateWorkItemCallBack(struct
work_struct *work)
RT_TRACE(COMP_SCAN, "Scan InitialGainBackup 0xa0a is %x\n",
priv->initgain_backup.cca);
- RT_TRACE(COMP_SCAN, "Write scan initial gain = 0x%x \n",
+ RT_TRACE(COMP_SCAN, "Write scan initial gain = 0x%x\n",
initial_gain);
write_nic_byte(dev, rOFDM0_XAAGCCore1, initial_gain);
write_nic_byte(dev, rOFDM0_XBAGCCore1, initial_gain);
write_nic_byte(dev, rOFDM0_XCAGCCore1, initial_gain);
write_nic_byte(dev, rOFDM0_XDAGCCore1, initial_gain);
- RT_TRACE(COMP_SCAN, "Write scan 0xa0a = 0x%x \n",
+ RT_TRACE(COMP_SCAN, "Write scan 0xa0a = 0x%x\n",
POWER_DETECTION_TH);
write_nic_byte(dev, 0xa0a, POWER_DETECTION_TH);
break;
@@ -1792,7 +1793,7 @@ void InitialGainOperateWorkItemCallBack(struct
work_struct *work)
rtl8192_setBBreg(dev, UFWP, bMaskByte1, 0x1);
break;
default:
- RT_TRACE(COMP_SCAN, "Unknown IG Operation. \n");
+ RT_TRACE(COMP_SCAN, "Unknown IG Operation.\n");
break;
}
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] staging: rtl8192u: Fixed switch and case indentation error in r819xU_phy.c
From: sanjeev sharma
This is a patch to the r819xU_phy.c file that will fix switch and case
indentation Error reported by checkpatch script.
Signed-off-by: Sanjeev Sharma
---
drivers/staging/rtl8192u/r819xU_phy.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_phy.c
b/drivers/staging/rtl8192u/r819xU_phy.c
index 0fcb673..3155616 100644
--- a/drivers/staging/rtl8192u/r819xU_phy.c
+++ b/drivers/staging/rtl8192u/r819xU_phy.c
@@ -946,12 +946,12 @@ void rtl8192_phy_RFConfig(struct net_device *dev)
struct r8192_priv *priv = ieee80211_priv(dev);
switch (priv->rf_chip) {
- case RF_8256:
- PHY_RF8256_Config(dev);
- break;
- default:
- RT_TRACE(COMP_ERR, "error chip id\n");
- break;
+ case RF_8256:
+ PHY_RF8256_Config(dev);
+ break;
+ default:
+ RT_TRACE(COMP_ERR, "error chip id\n");
+ break;
}
}
--
1.7.11.7
--
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/4] staging: rtl8192u: Remove useless return statement in r819xU_phy.c
From: sanjeev sharma
This is a patch to the r819xU_phy.c file that remove unneeded return statements
in code.
Signed-off-by: Sanjeev Sharma
---
Changes in v2:
- Remove useless return statement.
---
drivers/staging/rtl8192u/r819xU_phy.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_phy.c
b/drivers/staging/rtl8192u/r819xU_phy.c
index 02554c9..0bcdd4e 100644
--- a/drivers/staging/rtl8192u/r819xU_phy.c
+++ b/drivers/staging/rtl8192u/r819xU_phy.c
@@ -101,7 +101,6 @@ void rtl8192_setBBreg(struct net_device *dev, u32 reg_addr,
u32 bitmask,
} else {
write_nic_dword(dev, reg_addr, data);
}
- return;
}
/**
@@ -281,7 +280,6 @@ static void rtl8192_phy_RFSerialWrite(struct net_device
*dev,
priv->RfReg0Value[eRFPath] << 16);
}
}
- return;
}
/**
@@ -332,7 +330,6 @@ void rtl8192_phy_SetRFReg(struct net_device *dev,
RF90_RADIO_PATH_E eRFPath,
rtl8192_phy_RFSerialWrite(dev, eRFPath, reg_addr, data);
}
}
- return;
}
/**
@@ -513,7 +510,6 @@ void rtl8192_phy_configmac(struct net_device *dev)
rtl8192_setBBreg(dev, pdwArray[i], pdwArray[i+1],
pdwArray[i+2]);
}
- return;
}
/**
@@ -559,7 +555,6 @@ void rtl8192_phyConfigBB(struct net_device *dev, u8
ConfigType)
rtl819XAGCTAB_Array[i+1]);
}
}
- return;
}
/**
@@ -846,7 +841,6 @@ static void rtl8192_BB_Config_ParaFile(struct net_device
*dev)
priv->bCckHighPower = (u8)rtl8192_QueryBBReg(dev,
rFPGA0_XA_HSSIParameter2,
0x200);
- return;
}
/**
@@ -864,7 +858,6 @@ void rtl8192_BBConfig(struct net_device *dev)
* implemented, so use file first.
* FIXME: should implement it for hardcode? */
rtl8192_BB_Config_ParaFile(dev);
- return;
}
@@ -912,8 +905,6 @@ void rtl8192_phy_getTxPower(struct net_device *dev)
/* Read SIFS (save the value read fome MACPHY_REG.txt) */
read_nic_word(dev, SIFS, >SifsTime);
-
- return;
}
/**
@@ -942,7 +933,6 @@ void rtl8192_phy_setTxPower(struct net_device *dev, u8
channel)
__func__);
break;
}
- return;
}
/**
@@ -963,7 +953,6 @@ void rtl8192_phy_RFConfig(struct net_device *dev)
RT_TRACE(COMP_ERR, "error chip id\n");
break;
}
- return;
}
/**
@@ -974,7 +963,6 @@ void rtl8192_phy_RFConfig(struct net_device *dev)
**/
void rtl8192_phy_updateInitGain(struct net_device *dev)
{
- return;
}
/**
@@ -1094,7 +1082,6 @@ static void rtl8192_SetTxPowerLevel(struct net_device
*dev, u8 channel)
RT_TRACE(COMP_ERR, "unknown rf chip ID in %s()\n", __func__);
break;
}
- return;
}
/**
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] staging: rtl8192u: Fixed too long lines in r819xU_phy.c
From: sanjeev sharma
This is a patch to the r819xU_phy.c file that will fix too long lines warning
reported by checkpatch.pl .
Signed-off-by: Sanjeev Sharma
---
drivers/staging/rtl8192u/r819xU_phy.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_phy.c
b/drivers/staging/rtl8192u/r819xU_phy.c
index 3155616..1ea3a4e 100644
--- a/drivers/staging/rtl8192u/r819xU_phy.c
+++ b/drivers/staging/rtl8192u/r819xU_phy.c
@@ -1236,7 +1236,8 @@ static u8 rtl8192_phy_SetSwChnlCmdArray(SwChnlCmd
*CmdTable, u32 CmdTableIdx,
return false;
}
if (CmdTableIdx >= CmdTableSz) {
- RT_TRACE(COMP_ERR, "%s(): Access invalid index, please check
size of the table, CmdTableIdx:%d, CmdTableSz:%d\n",
+ RT_TRACE(COMP_ERR,
+"%s():invalid index,CmdTableIdx:%d, CmdTableSz:%d\n",
__func__, CmdTableIdx, CmdTableSz);
return false;
}
@@ -1697,7 +1698,8 @@ void InitialGain819xUsb(struct net_device *dev, u8
Operation)
priv->InitialGainOperateType = Operation;
if (priv->up)
- queue_delayed_work(priv->priv_wq,
>initialgain_operate_wq, 0);
+ queue_delayed_work(priv->priv_wq,
+ >initialgain_operate_wq, 0);
}
void InitialGainOperateWorkItemCallBack(struct work_struct *work)
@@ -1786,7 +1788,9 @@ void InitialGainOperateWorkItemCallBack(struct
work_struct *work)
RT_TRACE(COMP_SCAN, "Scan BBInitialGainRestore 0xa0a is %x\n",
priv->initgain_backup.cca);
- rtl8192_phy_setTxPower(dev,
priv->ieee80211->current_network.channel);
+ rtl8192_phy_setTxPower(dev,
+ priv->ieee80211->current_network.channel
+ );
if (dm_digtable.dig_algorithm == DIG_ALGO_BY_FALSE_ALARM)
/* FW DIG ON */
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] Fix checkpatch reported problem in r819xU_phy.c
From: sanjeev sharma I have come up with seperate patch as per Dan comment. sanjeev sharma (4): staging: rtl8192u: Remove useless return statement in r819xU_phy.c staging: rtl8192u: Removed unnecessary whitespace & tab warning in r819xU_phy.c staging: rtl8192u: Fixed switch and case indentation error in r819xU_phy.c staging: rtl8192u: Fixed too long lines in r819xU_phy.c drivers/staging/rtl8192u/r819xU_phy.c | 58 +++ 1 file changed, 25 insertions(+), 33 deletions(-) -- 1.7.11.7 -- 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] ARM: SPEAr1310 PCIe updates
Hello Olof,
Please pull PCIe updates for ST's SPEAr1310 SoC.
Last version of posted V8 patches have been Acked-by respective maintainers.
https://lkml.org/lkml/2014/4/15/260
Apart from arch/arm/ changes, it also contains patches for drivers/{pci|phy}.
Bjorn advised to get complete series via arm-soc tree.
http://www.spinics.net/lists/linux-pci/msg30271.html
Regards
Mohit
The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
Linus Torvalds (1):
Linux 3.16-rc3
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git
spear/pcie-support-v8
Mohit Kumar (1):
SPEAr13xx: defconfig: Update
Pratyush Anand (8):
clk: SPEAr13XX: Fix pcie clock name
SPEAr13XX: Fix static mapping table
phy: SPEAr1310/40-miphy: Add binding information
SPEAr: misc: Add binding information
phy: SPEAr1310/40-miphy: Add phy driver for PCIe and SATA
SPEAr13XX: Add binding information for PCIe controller
SPEAr13XX: dts: Add PCIe node information
pcie: SPEAr13xx: Add designware wrapper support
.../devicetree/bindings/arm/spear-misc.txt |9 +
.../devicetree/bindings/pci/spear13xx-pcie.txt | 14 +
.../devicetree/bindings/phy/st-spear1310-miphy.txt | 12 +
.../devicetree/bindings/phy/st-spear1340-miphy.txt | 11 +
MAINTAINERS|6 +
arch/arm/boot/dts/spear1310-evb.dts|4 +
arch/arm/boot/dts/spear1310.dtsi | 93 +-
arch/arm/boot/dts/spear1340-evb.dts|4 +
arch/arm/boot/dts/spear1340.dtsi | 30 ++-
arch/arm/boot/dts/spear13xx.dtsi |9 +-
arch/arm/configs/spear13xx_defconfig | 16 +
arch/arm/mach-spear/Kconfig|4 +
arch/arm/mach-spear/include/mach/spear.h |4 +-
arch/arm/mach-spear/spear1340.c| 127 +--
arch/arm/mach-spear/spear13xx.c|2 +-
drivers/clk/spear/spear1310_clock.c|6 +-
drivers/clk/spear/spear1340_clock.c|2 +-
drivers/pci/host/Kconfig |8 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-spear13xx.c | 406
drivers/phy/Kconfig| 12 +
drivers/phy/Makefile |2 +
drivers/phy/phy-spear1310-miphy.c | 274 +
drivers/phy/phy-spear1340-miphy.c | 300 +++
24 files changed, 1217 insertions(+), 139 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/spear-misc.txt
create mode 100644 Documentation/devicetree/bindings/pci/spear13xx-pcie.txt
create mode 100644 Documentation/devicetree/bindings/phy/st-spear1310-miphy.txt
create mode 100644 Documentation/devicetree/bindings/phy/st-spear1340-miphy.txt
create mode 100644 drivers/pci/host/pcie-spear13xx.c
create mode 100644 drivers/phy/phy-spear1310-miphy.c
create mode 100644 drivers/phy/phy-spear1340-miphy.c
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH v3 3/7] regulator: Add DT bindings for tps65218 PMIC regulators.
Add DT bindings for tps65218 PMIC regulators.
Signed-off-by: Keerthy
Reviewed-by: Felipe Balbi
---
.../devicetree/bindings/regulator/tps65218.txt | 23
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt
b/Documentation/devicetree/bindings/regulator/tps65218.txt
new file mode 100644
index 000..fccc1d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -0,0 +1,23 @@
+TPS65218 family of regulators
+
+Required properties:
+For tps65218 regulators/LDOs
+- compatible:
+ - "ti,tps65218-dcdc1" for DCDC1
+ - "ti,tps65218-dcdc2" for DCDC2
+ - "ti,tps65218-dcdc3" for DCDC3
+ - "ti,tps65218-dcdc4" for DCDC4
+ - "ti,tps65218-dcdc5" for DCDC5
+ - "ti,tps65218-dcdc6" for DCDC6
+ - "ti,tps65218-ldo1" for LDO1
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+ xyz: regulator@0 {
+ compatible = "ti,tps65218-dcdc1";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <300>;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/7] ARM: dts: AM43x: Add devcice tree nodes
The patch series adds the device tree nodes and the corresponding documentation. The series also enabled tps65218 config options in the omap2plus_defconfig. The series is boot tested on both AM43x-epos-evm and AM437x-gp-evm. Keerthy (7): regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6 mfd: Add DT bindings for tps65218 PMIC regulator: Add DT bindings for tps65218 PMIC regulators. ARM: dts: AM43x: Add TPS65218 device tree nodes ARM: dts: AM437x: Fix i2c nodes indentation ARM: dts: AM437x: Add TPS65218 device tree nodes ARM: configs: omap2plus_defconfig: enable TPS65218 configs Documentation/devicetree/bindings/mfd/tps65218.txt | 89 .../devicetree/bindings/regulator/tps65218.txt | 23 + arch/arm/boot/dts/am437x-gp-evm.dts| 71 ++-- arch/arm/boot/dts/am43x-epos-evm.dts | 59 + arch/arm/configs/omap2plus_defconfig |2 + drivers/regulator/tps65218-regulator.c | 17 ++-- 6 files changed, 246 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps65218.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/7] ARM: dts: AM43x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes. i2c clock frequency setting
also added as part of tps65218 nodes addition. As i2c clock
enabling is required.
Signed-off-by: Keerthy
Reviewed-by: Felipe Balbi
---
Changes from V1:
* Added dcdc3, dcdc5, dcdc6 nodes.
* dcdc4 is not added because of a potential PMIC bug under investigation.
arch/arm/boot/dts/am43x-epos-evm.dts | 59 ++
1 file changed, 59 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 90098f9..f1ee7495 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -327,6 +327,65 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+ clock-frequency = <40>;
+
+ tps65218: tps65218@24 {
+ reg = <0x24>;
+ compatible = "ti,tps65218";
+ interrupts = ; /* NMIn */
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = "ti,tps65218-dcdc1";
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = "ti,tps65218-dcdc2";
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1378000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = "ti,tps65218-dcdc3";
+ regulator-name = "vdcdc3";
+ regulator-min-microvolt = <135>;
+ regulator-max-microvolt = <135>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ compatible = "ti,tps65218-dcdc5";
+ regulator-name = "v1_0bat";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = "ti,tps65218-dcdc6";
+ regulator-name = "v1_8bat";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = "ti,tps65218-ldo1";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
at24@50 {
compatible = "at24,24c256";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.15 093/122] zram: revalidate disk after capacity change
Hello Greg, On Tue, Jul 08, 2014 at 08:02:26AM -0700, Greg Kroah-Hartman wrote: > On Tue, Jul 08, 2014 at 07:56:17PM +0900, Sergey Senozhatsky wrote: > > On (07/07/14 16:57), Greg Kroah-Hartman wrote: > > > Date: Mon, 7 Jul 2014 16:57:35 -0700 > > > From: Greg Kroah-Hartman > > > To: linux-kernel@vger.kernel.org > > > Cc: Greg Kroah-Hartman , > > > sta...@vger.kernel.org, Minchan Kim , "Alexander E. > > > Patrakov" , Sergey Senozhatsky > > > , Nitin Gupta , Jerome > > > Marchand , Andrew Morton > > > , > > > Linus Torvalds > > > Subject: [PATCH 3.15 093/122] zram: revalidate disk after capacity change > > > X-Mailer: git-send-email 2.0.0.254.g50f84e3 > > > User-Agent: quilt/0.63-1 > > > > > > 3.15-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Minchan Kim > > > > > > commit 2e32baea46ce542c561a519414c840295b229c8f upstream. > > > > > > Alexander reported mkswap on /dev/zram0 is failed if other process is > > > opening the block device file. > > > > > > Step is as follows, > > > > > > 0. Reset the unused zram device. > > > 1. Use a program that opens /dev/zram0 with O_RDWR and sleeps > > >until killed. > > > 2. While that program sleeps, echo the correct value to > > >/sys/block/zram0/disksize. > > > 3. Verify (e.g. in /proc/partitions) that the disk size is applied > > >correctly. It is. > > > 4. While that program still sleeps, attempt to mkswap /dev/zram0. > > >This fails: mkswap: error: swap area needs to be at least 40 KiB > > > > > > When I investigated, the size get by ioctl(fd, BLKGETSIZE64, xxx) on > > > mkswap to get a size of blockdev was zero although zram0 has right size by > > > 2. > > > > > > The reason is zram didn't revalidate disk after changing capacity so that > > > size of blockdev's inode is not uptodate until all of file is close. > > > > > > This patch should fix the BUG. > > > > > > Signed-off-by: Minchan Kim > > > Reported-by: Alexander E. Patrakov > > > Tested-by: Alexander E. Patrakov > > > Reviewed-by: Sergey Senozhatsky > > > Cc: Nitin Gupta > > > Acked-by: Jerome Marchand > > > Signed-off-by: Andrew Morton > > > Signed-off-by: Linus Torvalds > > > Signed-off-by: Greg Kroah-Hartman > > > > Hello, > > > > this patch is known to cause problems. please see > > https://lkml.org/lkml/2014/7/3/885 > > Did the fix ever get merged to Linus's tree? If not, why not? I'd > rather just take that fix as well. Not yet. Because Andrew picked his tree(ie, mmotm) today. > > thanks, > > greg k-h > -- > 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/ -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/7] regulator: tps65218: Add fixed_uV fields for dcdc5 and dcdc6
Add fixed_uV fields for dcdc5 and dcdc6.
Signed-off-by: Keerthy
---
Changes from V2:
* Added fixed_uV fields for the regulator_desc structures.
drivers/regulator/tps65218-regulator.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 9effe48..27dc70d 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -30,7 +30,7 @@
enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5, DCDC6, LDO1 };
#define TPS65218_REGULATOR(_name, _id, _ops, _n, _vr, _vm, _er, _em, _t, \
- _lr, _nlr, _delay) \
+ _lr, _nlr, _delay, _fuv)\
{ \
.name = _name,\
.id = _id, \
@@ -46,6 +46,7 @@ enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5,
DCDC6, LDO1 };
.linear_ranges = _lr, \
.n_linear_ranges= _nlr, \
.ramp_delay = _delay, \
+ .fixed_uV = _fuv \
} \
#define TPS65218_INFO(_id, _nm, _min, _max)\
@@ -186,33 +187,33 @@ static const struct regulator_desc regulators[] = {
TPS65218_REG_CONTROL_DCDC1,
TPS65218_CONTROL_DCDC1_MASK,
TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC1_EN, NULL,
- dcdc1_dcdc2_ranges, 2, 4000),
+ dcdc1_dcdc2_ranges, 2, 4000, 0),
TPS65218_REGULATOR("DCDC2", TPS65218_DCDC_2, tps65218_dcdc12_ops, 64,
TPS65218_REG_CONTROL_DCDC2,
TPS65218_CONTROL_DCDC2_MASK,
TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC2_EN, NULL,
- dcdc1_dcdc2_ranges, 2, 4000),
+ dcdc1_dcdc2_ranges, 2, 4000, 0),
TPS65218_REGULATOR("DCDC3", TPS65218_DCDC_3, tps65218_ldo1_dcdc34_ops,
64, TPS65218_REG_CONTROL_DCDC3,
TPS65218_CONTROL_DCDC3_MASK, TPS65218_REG_ENABLE1,
TPS65218_ENABLE1_DC3_EN, NULL,
- ldo1_dcdc3_ranges, 2, 0),
+ ldo1_dcdc3_ranges, 2, 0, 0),
TPS65218_REGULATOR("DCDC4", TPS65218_DCDC_4, tps65218_ldo1_dcdc34_ops,
53, TPS65218_REG_CONTROL_DCDC4,
TPS65218_CONTROL_DCDC4_MASK,
TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC4_EN, NULL,
- dcdc4_ranges, 2, 0),
+ dcdc4_ranges, 2, 0, 0),
TPS65218_REGULATOR("DCDC5", TPS65218_DCDC_5, tps65218_dcdc56_pmic_ops,
1, -1, -1, TPS65218_REG_ENABLE1,
- TPS65218_ENABLE1_DC5_EN, NULL, NULL, 0, 0),
+ TPS65218_ENABLE1_DC5_EN, NULL, NULL, 0, 0, 100),
TPS65218_REGULATOR("DCDC6", TPS65218_DCDC_6, tps65218_dcdc56_pmic_ops,
1, -1, -1, TPS65218_REG_ENABLE1,
- TPS65218_ENABLE1_DC6_EN, NULL, NULL, 0, 0),
+ TPS65218_ENABLE1_DC6_EN, NULL, NULL, 0, 0, 180),
TPS65218_REGULATOR("LDO1", TPS65218_LDO_1, tps65218_ldo1_dcdc34_ops, 64,
TPS65218_REG_CONTROL_LDO1,
TPS65218_CONTROL_LDO1_MASK, TPS65218_REG_ENABLE2,
TPS65218_ENABLE2_LDO1_EN, NULL, ldo1_dcdc3_ranges,
- 2, 0),
+ 2, 0, 0),
};
static int tps65218_regulator_probe(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/7] ARM: dts: AM437x: Fix i2c nodes indentation
Fix i2c nodes indentation.
Signed-off-by: Keerthy
Reviewed-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-gp-evm.dts | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 003766c..85ca430 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -257,16 +257,15 @@
};
{
-status = "okay";
-pinctrl-names = "default";
-pinctrl-0 = <_pins>;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
};
{
-status = "okay";
-pinctrl-names = "default";
-pinctrl-0 = <_pins>;
-
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
pixcir_ts@5c {
compatible = "pixcir,pixcir_tangoc";
pinctrl-names = "default";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/7] mfd: Add DT bindings for tps65218 PMIC
Add DT bindings for tps65218 PMIC
Signed-off-by: Keerthy
Reviewed-by: Felipe Balbi
---
Documentation/devicetree/bindings/mfd/tps65218.txt | 89
1 file changed, 89 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tps65218.txt
diff --git a/Documentation/devicetree/bindings/mfd/tps65218.txt
b/Documentation/devicetree/bindings/mfd/tps65218.txt
new file mode 100644
index 000..01ac973
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65218.txt
@@ -0,0 +1,89 @@
+Texas Instruments TPS65218 family
+
+The TPS65218 are Integrated Power Management Chips.
+
+Required properties:
+- compatible : Must be "ti,tps65218";
+ For Integrated power-management used in AM437x based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the tps65218 supports several interrupts
+ internally, it is considered as an interrupt controller cascaded to the
+ SoC one.
+- #interrupt-cells = <2>;
+- interrupt-parent : The parent interrupt controller which is gic.
+
+Optional node:
+- TPS65218 PMIC has a number of child nodes. Mainly the regularors and SMPSs.
+
+Example:
+/*
+ * Integrated Power Management Chip
+ */
+tps65218: tps65218@24 {
+ reg = <0x24>;
+ compatible = "ti,tps65218";
+ interrupts = ; /* NMIn */
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = "ti,tps65218-dcdc1";
+ /* VDD_CORE voltage limits min of OPP50 and max of OPP100 */
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = "ti,tps65218-dcdc2";
+ /* VDD_MPU voltage limits min of OPP50 and max of OPP_NITRO */
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1378000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = "ti,tps65218-dcdc3";
+ regulator-name = "vdcdc3";
+ regulator-min-microvolt = <135>;
+ regulator-max-microvolt = <135>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc4: regulator-dcdc4 {
+ compatible = "ti,tps65218-dcdc4";
+ regulator-name = "v3_3d";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc5: regulator-dcdc5 {
+ compatible = "ti,tps65218-dcdc5";
+ regulator-name = "v1_0bat";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = "ti,tps65218-dcdc6";
+ regulator-name = "v1_8vat";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = "ti,tps65218-ldo1";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 7/7] ARM: configs: omap2plus_defconfig: enable TPS65218 configs
Enable TPS65218 config options. Signed-off-by: Keerthy Acked-by: Felipe Balbi --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 536a137..f650f00 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -180,6 +180,7 @@ CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_SYSCON=y CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y +CONFIG_MFD_TPS65218=y CONFIG_MFD_TPS65910=y CONFIG_TWL6040_CORE=y CONFIG_REGULATOR_FIXED_VOLTAGE=y @@ -188,6 +189,7 @@ CONFIG_REGULATOR_TI_ABB=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y CONFIG_REGULATOR_TPS65217=y +CONFIG_REGULATOR_TPS65218=y CONFIG_REGULATOR_TPS65910=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_PBIAS=y -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/7] ARM: dts: AM437x: Add TPS65218 device tree nodes
Add TPS65218 device tree nodes. i2c clock frequency setting
also added as part of tps65218 nodes addition. As i2c clock
enabling is required.
Signed-off-by: Keerthy
Reviewed-by: Felipe Balbi
---
Changes from V1:
* Added dcdc3, dcdc5, dcdc6 nodes.
* dcdc4 is not added because of a potential PMIC bug under investigation.
arch/arm/boot/dts/am437x-gp-evm.dts | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 85ca430..f0422c2 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -260,6 +260,64 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+ clock-frequency = <40>;
+
+ tps65218: tps65218@24 {
+ reg = <0x24>;
+ compatible = "ti,tps65218";
+ interrupts = ; /* NMIn */
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = "ti,tps65218-dcdc1";
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = "ti,tps65218-dcdc2";
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1378000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = "ti,tps65218-dcdc3";
+ regulator-name = "vdcdc3";
+ regulator-min-microvolt = <135>;
+ regulator-max-microvolt = <135>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ dcdc5: regulator-dcdc5 {
+ compatible = "ti,tps65218-dcdc5";
+ regulator-name = "v1_0bat";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <100>;
+ };
+
+ dcdc6: regulator-dcdc6 {
+ compatible = "ti,tps65218-dcdc6";
+ regulator-name = "v1_8bat";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ ldo1: regulator-ldo1 {
+ compatible = "ti,tps65218-ldo1";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
};
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 6/7] ARM: add pmd_[dirty|mkclean] for THP
Hello Steve, On Tue, Jul 08, 2014 at 12:37:38PM +0100, Steve Capper wrote: > On Tue, Jul 08, 2014 at 03:03:43PM +0900, Minchan Kim wrote: > > MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent > > overwrite of the contents since MADV_FREE syscall is called for > > THP page. > > > > This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE > > support. > > > > Cc: Catalin Marinas > > Cc: Will Deacon > > Cc: Steve Capper > > Cc: Russell King > > Cc: linux-arm-ker...@lists.infradead.org > > Signed-off-by: Minchan Kim > > --- > > arch/arm/include/asm/pgtable-3level.h | 3 +++ > > arch/arm64/include/asm/pgtable.h | 2 ++ > > 2 files changed, 5 insertions(+) > > Hi Minchan, > arch/arm and arch/arm64 are handled separately. > Could you please split this patch into arm and arm64 versions? > Sure. > > > > > diff --git a/arch/arm/include/asm/pgtable-3level.h > > b/arch/arm/include/asm/pgtable-3level.h > > index 85c60adc8b60..3a7bb8dc7d05 100644 > > --- a/arch/arm/include/asm/pgtable-3level.h > > +++ b/arch/arm/include/asm/pgtable-3level.h > > @@ -220,6 +220,8 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned > > long addr) > > #define pmd_trans_splitting(pmd) (pmd_val(pmd) & PMD_SECT_SPLITTING) > > #endif > > > > +#define pmd_dirty (pmd_val(pmd) & PMD_SECT_DIRTY) > > This macro is missing the parameter definition, and will generate a > compile errror when CONFIG_ARM_LPAE=y > > For 32-bit ARM with CONFIG_ARM_LPAE=n, we don't have THP support and I noticed > some compiler errors in mm/madvise.c: > > CC mm/madvise.o > mm/madvise.c: In function ‘madvise_free_pte_range’: > mm/madvise.c:279:3: error: implicit declaration of function > ‘pmdp_get_and_clear’ [-Werror=implicit-function-declaration] >orig_pmd = pmdp_get_and_clear(mm, addr, pmd); >^ > mm/madvise.c:285:3: error: implicit declaration of function ‘pmd_mkold’ > [-Werror=implicit-function-declaration] >orig_pmd = pmd_mkold(orig_pmd); >^ > mm/madvise.c:286:3: error: implicit declaration of function ‘pmd_mkclean’ > [-Werror=implicit-function-declaration] >orig_pmd = pmd_mkclean(orig_pmd); >^ > mm/madvise.c:288:3: error: implicit declaration of function ‘set_pmd_at’ > [-Werror=implicit-function-declaration] >set_pmd_at(mm, addr, pmd, orig_pmd); >^ > cc1: some warnings being treated as errors > make[1]: *** [mm/madvise.o] Error 1 > Oops, will fix. Thanks for the review! > > Cheers, > -- > Steve > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: sgtl5000: Use devm_ functions
On Tue, 8 Jul 2014, Mark Brown wrote: > On Tue, Jul 08, 2014 at 10:15:20AM +0200, Julia Lawall wrote: > > On Tue, 8 Jul 2014, Mark Brown wrote: > > > > It should be fairly clear given what they do I'd have thought - the > > > devm_ functions tie the deallocation of a resource to the unbinding of > > > a driver from a device so they can only be used to replace things that > > > get cleaned up in a device model unbind path. There's not usually a > > > great deal of indirection going on in those. > > > It is completely clear what they do. What is not clear is what device > > libraries are set up to call the freeing functions at what point. For > > example, I know that that platform drivers are set up for this, but once I > > tried to find the lines of code that would justify that, but I could not. > > Perhaps I was not patient enough or missed something. > > All devices do this - it's done as part of the driver model core code so > there is no need for individual buses to do anything. How should one realize that this does not apply to the original file under discussion, sound/soc/codecs/sgtl5000.c? The associated structure is snd_soc_codec_driver. What code could one look for at the call sites of the probe and remove functions to know that managed memory can be used? thanks, julia -- 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] Removes FIXME message in usb.c
On Tue, Jul 08, 2014 at 09:58:39PM -0400, Nicholas Krause wrote: > This patch removes a fixme message in this file:wq for setting the usb 2 I don't think you did this correctly :) > speed on the board to the correct level. We need to depend on the > bootloader for doing this as the wires may be shared for the other > things on the board with the usb chipset. > > Signed-off-by: Nicholas Krause > --- > arch/arm/mach-omap1/usb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c > index 4118db5..172245a 100644 > --- a/arch/arm/mach-omap1/usb.c > +++ b/arch/arm/mach-omap1/usb.c > @@ -505,7 +505,7 @@ static u32 __init omap1_usb2_init(unsigned nwires, > unsigned alt_pingroup) > omap_cfg_reg(W5_USB2_SE0); > if (nwires != 3) > omap_cfg_reg(Y5_USB2_RCV); > - // FIXME omap_cfg_reg(USB2_SPEED); > + /* Depend on boatloader for USB speed to be stated for board */ Really? Is that correct? WHy? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] Staging: rts5208: Replace custom macro with print_hex_dump_bytes
On Tue, Jul 08, 2014 at 06:48:18PM -0700, Joe Perches wrote:
> On Tue, 2014-07-08 at 16:45 -0700, Greg KH wrote:
> > On Tue, Jul 08, 2014 at 11:38:30PM +0200, Fabio Falzoi wrote:
> > > Use print_hex_dump_bytes to have memory properly dumped only when
> > > DEBUG is defined.
> []
> > > diff --git a/drivers/staging/rts5208/trace.h
> > > b/drivers/staging/rts5208/trace.h
> []
> > > @@ -82,12 +82,11 @@ static inline char *filename(char *path)
> []
> > > +static inline void rtsx_hex_dump(const void *buf, size_t len)
> > > +{
> > > +#ifdef DEBUG
> > > + print_hex_dump_bytes(KBUILD_MODNAME ": ", DUMP_PREFIX_NONE, buf, len);
> > > #endif
> > > +}
> >
> > What a mess. What's wrong with just using the %*ph modifier in
> > dev_dbg() like other drivers do?
>
> Dunno.
> Is it ever desired to emit more than 64 bytes of buf?
I doubt it really matters :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] perf tools: Left-align output contents
Now perf left-aligns column headers but the contents does not. It
should have same alignment.
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 14e5a039bc45..9a531743c8c2 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -70,7 +70,7 @@ static int hist_entry__thread_snprintf(struct hist_entry *he,
char *bf,
size_t size, unsigned int width)
{
const char *comm = thread__comm_str(he->thread);
- return repsep_snprintf(bf, size, "%*s:%5d", width - 6,
+ return repsep_snprintf(bf, size, "%-*s:%5d", width - 6,
comm ?: "", he->thread->tid);
}
@@ -106,7 +106,7 @@ sort__comm_sort(struct hist_entry *left, struct hist_entry
*right)
static int hist_entry__comm_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
- return repsep_snprintf(bf, size, "%*s", width, comm__str(he->comm));
+ return repsep_snprintf(bf, size, "%-*s", width, comm__str(he->comm));
}
struct sort_entry sort_comm = {
@@ -305,7 +305,7 @@ static int hist_entry__srcline_snprintf(struct hist_entry
*he, char *bf,
size_t size,
unsigned int width __maybe_unused)
{
- return repsep_snprintf(bf, size, "%s", he->srcline);
+ return repsep_snprintf(bf, size, "%-s", he->srcline);
}
struct sort_entry sort_srcline = {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] perf tools: Make __hpp__fmt() receive an additional len argument
So that it can properly handle alignment requirements later. To do
that, add percent_color_len_snprintf() fucntion to help coloring of
overhead columns.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 14 --
tools/perf/ui/gtk/hists.c | 8 +---
tools/perf/ui/hist.c | 43 +-
tools/perf/util/color.c| 16
tools/perf/util/color.h| 1 +
tools/perf/util/hist.h | 4 ++--
6 files changed, 54 insertions(+), 32 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index a94b11fc5e00..02507ba944e3 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -653,17 +653,18 @@ struct hpp_arg {
static int __hpp__slsmg_color_printf(struct perf_hpp *hpp, const char *fmt,
...)
{
struct hpp_arg *arg = hpp->ptr;
- int ret;
+ int ret, len;
va_list args;
double percent;
va_start(args, fmt);
+ len = va_arg(args, int);
percent = va_arg(args, double);
va_end(args);
ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
- ret = scnprintf(hpp->buf, hpp->size, fmt, percent);
+ ret = scnprintf(hpp->buf, hpp->size, fmt, len, percent);
slsmg_printf("%s", hpp->buf);
advance_hpp(hpp, ret);
@@ -681,7 +682,7 @@ hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt
__maybe_unused,\
struct perf_hpp *hpp, \
struct hist_entry *he) \
{ \
- return __hpp__fmt(hpp, he, __hpp_get_##_field, " %6.2f%%", \
+ return __hpp__fmt(hpp, he, __hpp_get_##_field, " %*.2f%%", 6, \
__hpp__slsmg_color_printf, true); \
}
@@ -697,13 +698,14 @@ hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt
__maybe_unused,\
struct hist_entry *he) \
{ \
if (!symbol_conf.cumulate_callchain) { \
- int ret = scnprintf(hpp->buf, hpp->size, "%8s", "N/A"); \
+ int ret = scnprintf(hpp->buf, hpp->size,\
+ "%*s", 8, "N/A"); \
slsmg_printf("%s", hpp->buf); \
\
return ret; \
} \
- return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %6.2f%%", \
- __hpp__slsmg_color_printf, true); \
+ return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %*.2f%%", \
+ 6, __hpp__slsmg_color_printf, true); \
}
__HPP_COLOR_PERCENT_FN(overhead, period)
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 6ca60e482cdc..91f6cd7d2312 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -11,6 +11,7 @@
static int __percent_color_snprintf(struct perf_hpp *hpp, const char *fmt, ...)
{
int ret = 0;
+ int len;
va_list args;
double percent;
const char *markup;
@@ -18,6 +19,7 @@ static int __percent_color_snprintf(struct perf_hpp *hpp,
const char *fmt, ...)
size_t size = hpp->size;
va_start(args, fmt);
+ len = va_arg(args, int);
percent = va_arg(args, double);
va_end(args);
@@ -25,7 +27,7 @@ static int __percent_color_snprintf(struct perf_hpp *hpp,
const char *fmt, ...)
if (markup)
ret += scnprintf(buf, size, markup);
- ret += scnprintf(buf + ret, size - ret, fmt, percent);
+ ret += scnprintf(buf + ret, size - ret, fmt, len, percent);
if (markup)
ret += scnprintf(buf + ret, size - ret, "");
@@ -43,7 +45,7 @@ static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt
*fmt __maybe_unused,
struct perf_hpp *hpp,
\
struct hist_entry *he)
\
{
\
- return __hpp__fmt(hpp, he, he_get_##_field, " %6.2f%%",
\
+ return __hpp__fmt(hpp, he, he_get_##_field, " %*.2f%%", 6,
\
__percent_color_snprintf, true);
\
}
@@ -57,7 +59,7 @@ static int perf_gtk__hpp_color_##_type(struct perf_hpp_fmt
*fmt __maybe_unused,
struct perf_hpp *hpp,
\
struct hist_entry *he)
[PATCH 3/6] perf tools: Save column length in perf_hpp_fmt
Save column length in the hpp format and pass it to print functions.
This is a preparation for users to control column width in the output.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 2 +-
tools/perf/ui/hist.c | 135 +++--
tools/perf/util/hist.h | 2 +
tools/perf/util/sort.c | 3 +-
4 files changed, 94 insertions(+), 48 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 02507ba944e3..c1d8d3925fe1 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -849,7 +849,7 @@ static int hists__scnprintf_headers(char *buf, size_t size,
struct hists *hists)
if (perf_hpp__should_skip(fmt))
continue;
- /* We need to add the length of the columns header. */
+ /* We need to ensure length of the columns header. */
perf_hpp__reset_width(fmt, hists);
ret = fmt->header(fmt, _hpp, hists_to_evsel(hists));
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index c6cffbd0b0e1..e28ca972d046 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -110,7 +110,7 @@ int __hpp__fmt_acc(struct perf_hpp *hpp, struct hist_entry
*he,
{
if (!symbol_conf.cumulate_callchain) {
return snprintf(hpp->buf, hpp->size, "%*s",
- fmt_percent ? 8 : 12, "N/A");
+ fmt_percent ? len + 2 : len + 1, "N/A");
}
return __hpp__fmt(hpp, he, get_field, fmt, len, print_fn, fmt_percent);
@@ -190,32 +190,31 @@ static int __hpp__sort_acc(struct hist_entry *a, struct
hist_entry *b,
return ret;
}
-#define __HPP_HEADER_FN(_type, _str, _min_width, _unit_width) \
-static int hpp__header_##_type(struct perf_hpp_fmt *fmt __maybe_unused,
\
- struct perf_hpp *hpp,\
- struct perf_evsel *evsel)\
-{ \
- int len = _min_width; \
- \
- if (symbol_conf.event_group)\
- len = max(len, evsel->nr_members * _unit_width);\
- \
- return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
-}
-
-#define __HPP_WIDTH_FN(_type, _min_width, _unit_width)
\
-static int hpp__width_##_type(struct perf_hpp_fmt *fmt __maybe_unused, \
+#define __HPP_WIDTH_FN(_type, _str)\
+static int hpp__width_##_type(struct perf_hpp_fmt *fmt,
\
struct perf_hpp *hpp __maybe_unused, \
struct perf_evsel *evsel) \
{ \
- int len = _min_width; \
+ int len = fmt->len; \
\
if (symbol_conf.event_group)\
- len = max(len, evsel->nr_members * _unit_width);\
+ len = max(len, evsel->nr_members * len);\
+ \
+ if (len < (int)strlen(_str))\
+ len = strlen(_str); \
\
return len; \
}
+#define __HPP_HEADER_FN(_type, _str) \
+static int hpp__header_##_type(struct perf_hpp_fmt *fmt, \
+ struct perf_hpp *hpp,\
+ struct perf_evsel *evsel)\
+{ \
+ int len = hpp__width_##_type(fmt, hpp, evsel); \
+ return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
+}
+
static int hpp_color_scnprintf(struct perf_hpp *hpp, const char *fmt, ...)
{
va_list args;
@@ -251,18 +250,19 @@ static u64 he_get_##_field(struct hist_entry *he)
\
return he->stat._field;
\
}
\
\
-static int hpp__color_##_type(struct perf_hpp_fmt *fmt __maybe_unused,
\
[PATCH 6/6] perf tools: Add name field into perf_hpp_fmt
It makes the code a bit simpler and easier to debug IMHO.
I guess it can also remove similar code in perf diff, but let's keep
it for a future work. :)
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/hists.c | 4 +-
tools/perf/ui/hist.c | 109 ++
tools/perf/util/hist.h| 1 +
tools/perf/util/sort.c| 6 +--
4 files changed, 57 insertions(+), 63 deletions(-)
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 897b2e140428..f3fa4258b256 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -207,10 +207,8 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists,
if (perf_hpp__is_sort_entry(fmt))
sym_col = col_idx;
- fmt->header(fmt, , hists_to_evsel(hists));
-
gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
- -1, ltrim(s),
+ -1, fmt->name,
renderer, "markup",
col_idx++, NULL);
}
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index b2d60a95f01d..93285df06164 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -209,7 +209,7 @@ static int __hpp__sort_acc(struct hist_entry *a, struct
hist_entry *b,
return ret;
}
-#define __HPP_WIDTH_FN(_type, _str)\
+#define __HPP_WIDTH_FN(_type) \
static int hpp__width_##_type(struct perf_hpp_fmt *fmt,
\
struct perf_hpp *hpp __maybe_unused, \
struct perf_evsel *evsel) \
@@ -219,19 +219,19 @@ static int hpp__width_##_type(struct perf_hpp_fmt *fmt,
\
if (symbol_conf.event_group)\
len = max(len, evsel->nr_members * fmt->len); \
\
- if (len < (int)strlen(_str))\
- len = strlen(_str); \
+ if (len < (int)strlen(fmt->name)) \
+ len = strlen(fmt->name);\
\
return len; \
}
-#define __HPP_HEADER_FN(_type, _str) \
+#define __HPP_HEADER_FN(_type)
\
static int hpp__header_##_type(struct perf_hpp_fmt *fmt, \
struct perf_hpp *hpp,\
struct perf_evsel *evsel)\
{ \
int len = hpp__width_##_type(fmt, hpp, evsel); \
- return scnprintf(hpp->buf, hpp->size, "%*s", len, _str);\
+ return scnprintf(hpp->buf, hpp->size, "%*s", len, fmt->name); \
}
static int hpp_color_scnprintf(struct perf_hpp *hpp, const char *fmt, ...)
@@ -337,38 +337,35 @@ static int64_t hpp__sort_##_type(struct hist_entry *a,
struct hist_entry *b) \
}
-#define HPP_PERCENT_FNS(_type, _str, _field) \
-__HPP_WIDTH_FN(_type, _str)\
-__HPP_HEADER_FN(_type, _str) \
+#define HPP_PERCENT_FNS(_type, _field) \
+__HPP_WIDTH_FN(_type) \
+__HPP_HEADER_FN(_type) \
__HPP_COLOR_PERCENT_FN(_type, _field) \
__HPP_ENTRY_PERCENT_FN(_type, _field) \
__HPP_SORT_FN(_type, _field)
-#define HPP_PERCENT_ACC_FNS(_type, _str, _field) \
-__HPP_WIDTH_FN(_type, _str)\
-__HPP_HEADER_FN(_type, _str) \
+#define HPP_PERCENT_ACC_FNS(_type, _field) \
+__HPP_WIDTH_FN(_type) \
+__HPP_HEADER_FN(_type) \
__HPP_COLOR_ACC_PERCENT_FN(_type, _field) \
__HPP_ENTRY_ACC_PERCENT_FN(_type, _field) \
__HPP_SORT_ACC_FN(_type, _field)
-#define HPP_RAW_FNS(_type, _str, _field) \
-__HPP_WIDTH_FN(_type, _str)\
-__HPP_HEADER_FN(_type, _str)
[PATCH 4/6] perf report: Honor column width setting
Set column width and do not change it if user gives -w/--column-widths
option. It'll truncate longer symbols than the width if exists.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 23
tools/perf/ui/gtk/hists.c | 10 ++---
tools/perf/ui/hist.c | 84 +-
tools/perf/ui/stdio/hist.c | 4 +-
tools/perf/util/hist.h | 14 ---
tools/perf/util/sort.c | 44 +-
6 files changed, 116 insertions(+), 63 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index c1d8d3925fe1..f0ef031558dd 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -678,12 +678,12 @@ static u64 __hpp_get_##_field(struct hist_entry *he)
\
} \
\
static int \
-hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt __maybe_unused,\
+hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt, \
struct perf_hpp *hpp, \
struct hist_entry *he) \
{ \
- return __hpp__fmt(hpp, he, __hpp_get_##_field, " %*.2f%%", 6, \
- __hpp__slsmg_color_printf, true); \
+ return hpp__fmt(fmt, hpp, he, __hpp_get_##_field, " %*.2f%%", \
+ __hpp__slsmg_color_printf, true); \
}
#define __HPP_COLOR_ACC_PERCENT_FN(_type, _field) \
@@ -693,19 +693,20 @@ static u64 __hpp_get_acc_##_field(struct hist_entry *he)
\
} \
\
static int \
-hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt __maybe_unused,\
+hist_browser__hpp_color_##_type(struct perf_hpp_fmt *fmt, \
struct perf_hpp *hpp, \
struct hist_entry *he) \
{ \
if (!symbol_conf.cumulate_callchain) { \
+ int len = fmt->user_len ?: fmt->len;\
int ret = scnprintf(hpp->buf, hpp->size,\
- "%*s", 8, "N/A"); \
+ "%*s", len, "N/A"); \
slsmg_printf("%s", hpp->buf); \
\
return ret; \
} \
- return __hpp__fmt(hpp, he, __hpp_get_acc_##_field, " %*.2f%%", \
- 6, __hpp__slsmg_color_printf, true); \
+ return hpp__fmt(fmt, hpp, he, __hpp_get_acc_##_field, \
+ " %*.2f%%", __hpp__slsmg_color_printf, true); \
}
__HPP_COLOR_PERCENT_FN(overhead, period)
@@ -797,8 +798,11 @@ static int hist_browser__show_entry(struct hist_browser
*browser,
if (fmt->color) {
width -= fmt->color(fmt, , entry);
} else {
- width -= fmt->entry(fmt, , entry);
+ int ret = fmt->entry(fmt, , entry);
+ s[ret] = '\0';
slsmg_printf("%s", s);
+
+ width -= ret;
}
}
@@ -1549,6 +1553,9 @@ static int perf_evsel__hists_browse(struct perf_evsel
*evsel, int nr_events,
memset(options, 0, sizeof(options));
+ if (symbol_conf.col_width_list_str)
+ perf_hpp__set_user_width(symbol_conf.col_width_list_str);
+
while (1) {
const struct thread *thread = NULL;
const struct dso *dso = NULL;
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 91f6cd7d2312..897b2e140428 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -41,12 +41,12 @@ static u64 he_get_##_field(struct hist_entry *he)
\
return he->stat._field;
\
}
\
\
-static int perf_gtk__hpp_color_##_type(struct
[PATCHSET 0/6] perf tools: Honor column width setting
Hello, This patchset is to control perf report/top output column width by -w/--column-widths option so that it can fit into the terminal size. The -w option is there for perf report but it ignored by recent output field changed due to some reason. This patchset fixes it and supports perf top also. This is sometimes useful if your terminal is small and there's some C++ applications which have amazingly long symbol names. Without this patchset user might not see those symbols on TUI, since it maps left/right arrow keys to other functions. The -w option sets column width starting from the first column (overhead or optional overhead_children column unless -F option is given). It doesn't make sense to limit those overhead columns so it's not a hard-limit for them. But it *is* a hard-limit for other columns such as comm, dso, symbol, and so on. One can use 0 not to limit/force a width for those columns. For example: $ perf report --stdio -s comm,dso ... # Overhead Command Shared Object # ... . # 71.08% gnome-shell perf-1497.map 9.23% gnome-shell swrast_dri.so 3.99% Xorg [unknown] 3.18% Xorg [kernel.kallsyms] 2.93% gnome-shell [kernel.kallsyms] 2.41% swapper [kernel.kallsyms] 1.55% synergys libpthread-2.15.so 1.08% synergys synergys 0.68% systemd-journal [kernel.kallsyms] 0.59% synergys libstdc++.so.6.0.17 0.58% gnome-shell libc-2.15.so 0.54% kworker/0:2 [kernel.kallsyms] 0.20% systemd-journal [unknown] 0.19% gnome-shell libclutter-1.0.so.0.1000.8.#prelink#.1kh1we (deleted) 0.18% firefox libxul.so (deleted) 0.17% gnome-shell libcogl.so.9.1.1.#prelink#.ZL3fn1 (deleted) 0.14% firefox [kernel.kallsyms] 0.14% gnome-shell libgobject-2.0.so.0.3200.4 0.13% gnome-shell libpthread-2.15.so 0.11% synergys [kernel.kallsyms] 0.10% perf [kernel.kallsyms] $ perf report --stdio -s comm,dso -w 0,10,20 # 0 means no limit ... # Overhead Command Shared Object # .. # 71.08% gnome-shel perf-1497.map 9.23% gnome-shel swrast_dri.so 3.99% Xorg[unknown] 3.18% Xorg[kernel.kallsyms] 2.93% gnome-shel [kernel.kallsyms] 2.41% swapper [kernel.kallsyms] 1.55% synergyslibpthread-2.15.so 1.08% synergyssynergys 0.68% systemd-jo [kernel.kallsyms] 0.59% synergyslibstdc++.so.6.0.17 0.58% gnome-shel libc-2.15.so 0.54% kworker/0: [kernel.kallsyms] 0.20% systemd-jo [unknown] 0.19% gnome-shel libclutter-1.0.so.0. 0.18% firefox libxul.so (deleted) 0.17% gnome-shel libcogl.so.9.1.1.#pr 0.14% firefox [kernel.kallsyms] 0.14% gnome-shel libgobject-2.0.so.0. 0.13% gnome-shel libpthread-2.15.so 0.11% synergys[kernel.kallsyms] 0.10% perf[kernel.kallsyms] You can also get this from 'perf/width-v1' branch on my tree git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Namhyung Kim (6): perf tools: Left-align output contents perf tools: Make __hpp__fmt() receive an additional len argument perf tools: Save column length in perf_hpp_fmt perf report: Honor column width setting perf top: Add -w option for setting column width perf tools: Add name field into perf_hpp_fmt tools/perf/Documentation/perf-report.txt | 2 +- tools/perf/Documentation/perf-top.txt| 6 + tools/perf/builtin-top.c | 3 + tools/perf/ui/browsers/hists.c | 31 ++-- tools/perf/ui/gtk/hists.c| 18 +- tools/perf/ui/hist.c | 275 +++ tools/perf/ui/stdio/hist.c | 4 +-
[PATCH 5/6] perf top: Add -w option for setting column width
Add -w/--column-widths option like perf report does so that users are
able to see symbols even with some very long C++ library/functions.
It can be a list separated by comma for each column.
$ perf top -w 0,20,30
The value of 0 means there's no limit.
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 2 +-
tools/perf/Documentation/perf-top.txt| 6 ++
tools/perf/builtin-top.c | 3 +++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index d2b59af62bc0..d561e0214f52 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -147,7 +147,7 @@ OPTIONS
-w::
--column-widths=::
Force each column width to the provided list, for large terminal
- readability.
+ readability. 0 means no limit (default behavior).
-t::
--field-separator=::
diff --git a/tools/perf/Documentation/perf-top.txt
b/tools/perf/Documentation/perf-top.txt
index 180ae02137a5..28fdee394880 100644
--- a/tools/perf/Documentation/perf-top.txt
+++ b/tools/perf/Documentation/perf-top.txt
@@ -193,6 +193,12 @@ Default is to monitor all CPUS.
sum of shown entries will be always 100%. "absolute" means it retains
the original value before and after the filter is applied.
+-w::
+--column-widths=::
+ Force each column width to the provided list, for large terminal
+ readability. 0 means no limit (default behavior).
+
+
INTERACTIVE PROMPTING KEYS
--
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 377971dc89a3..bde216b2071c 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1131,6 +1131,9 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
"Don't show entries under that percent",
parse_percent_limit),
OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
"How to display percentage of filtered entries",
parse_filter_percentage),
+ OPT_STRING('w', "column-widths", _conf.col_width_list_str,
+ "width[,width...]",
+ "don't try to adjust column width, use these fixed values"),
OPT_END()
};
const char * const top_usage[] = {
--
2.0.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 NET-NEXT V2] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()
David, Sorry I don't know who owns this driver, the SOB of other patches to netxen may mislead me you could ACK it or not, so it is definitely not the original meaning that ask you specifically to review one patch. just ask for help point to someone could review it. Thanks, Ethan On 2014/7/9 11:46, David Miller wrote: From: ethan zhao Date: Wed, 09 Jul 2014 10:41:23 +0800 Please help to review and confirm this patch. It's not in patchwork, therefore it's not in my queue. It is also not my responsibility to review all patches, that's a joint responsibility of everyone on this mailing list. So asking me specifically to review a patch is really not generally inappropriate. 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/
[PATCH] Staging: comedi: check the return value of kobject_set_name
Added a check of the return value of the kobject_set_name function.
Signed-off-by: Anton Protopopov
---
drivers/staging/comedi/comedi_fops.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index 9d99fb3..dfeefa2 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2597,7 +2597,14 @@ static int __init comedi_init(void)
return -EIO;
cdev_init(_cdev, _fops);
comedi_cdev.owner = THIS_MODULE;
- kobject_set_name(_cdev.kobj, "comedi");
+
+ retval = kobject_set_name(_cdev.kobj, "comedi");
+ if (retval) {
+ unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
+COMEDI_NUM_MINORS);
+ return retval;
+ }
+
if (cdev_add(_cdev, MKDEV(COMEDI_MAJOR, 0), COMEDI_NUM_MINORS)) {
unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
COMEDI_NUM_MINORS);
--
1.8.3.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 RFCv2] arm64: eBPF JIT compiler
On Tue, Jul 8, 2014 at 2:24 AM, Alexei Starovoitov wrote:
> On Tue, Jul 8, 2014 at 12:06 AM, Zi Shen Lim wrote:
[...]
>> Also, per discussion with Alexei, and additional suggestion from
>> Daniel:
>> - moved load_pointer() from net/core/filter.c into filter.h
>> as bpf_load_pointer()
>> which is done as a separate preparatory patch. [1]
>>
>> [1] http://patchwork.ozlabs.org/patch/366906/
>
> Just to clarify. This patch is on top of [1]
Yes, that's correct. This patch uses bpf_load_pointer() from [1].
BTW, looks like David has applied it in net-next 9f12fbe603f7
("net: filter: move load_pointer() into filter.h").
[...]
>> + case BPF_DW:
>
> this case can be removed too.
Thanks for catching this :) I've removed it.
>
> Acked-by: Alexei Starovoitov
>
> Great work. Thanks.
Thanks for your time and feedback!
--
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] pinctrl: msm: Add msm8960 definitions
Signed-off-by: Bjorn Andersson --- Changes since v2: - Rewrite of device tree binding to clarify properties for both the pinctrl node and its subnodes. Changes since v1: - Deduplicated functions for alternative pins .../bindings/pinctrl/qcom,msm8960-pinctrl.txt | 181 +++ drivers/pinctrl/Kconfig|8 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-msm8960.c | 1254 4 files changed, 1444 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-msm8960.c diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt new file mode 100644 index 000..7dece8d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt @@ -0,0 +1,181 @@ +Qualcomm MSM8960 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSM8960 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,msm8960-pinctrl" + +- reg: + Usage: required + Value type: + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio151, + sdc1_clk, + sdc1_cmd, + sdc1_data + sdc3_clk, + sdc3_cmd, + sdc3_data + +- function: + Usage: optional + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + audio_pcm, bt, cam_mclk0, cam_mclk1, cam_mclk2, + codec_mic_i2s, codec_spkr_i2s, ext_gps, fm, gps_blanking, + gps_pps_in, gps_pps_out, gp_clk_0a, gp_clk_0b, gp_clk_1a, + gp_clk_1b, gp_clk_2a, gp_clk_2b, gp_mn, gp_pdm_0a, + gp_pdm_0b, gp_pdm_1a, gp_pdm_1b, gp_pdm_2a, gp_pdm_2b, + gsbi1, gsbi1_spi_cs1_n, gsbi1_spi_cs2a_n, gsbi1_spi_cs2b_n, + gsbi1_spi_cs3_n, gsbi2, gsbi2_spi_cs1_n, gsbi2_spi_cs2_n, + gsbi2_spi_cs3_n, gsbi3, gsbi4, gsbi4_3d_cam_i2c_l, + gsbi4_3d_cam_i2c_r, gsbi5, gsbi5_3d_cam_i2c_l, + gsbi5_3d_cam_i2c_r, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10, + gsbi11, gsbi11_spi_cs1a_n, gsbi11_spi_cs1b_n, + gsbi11_spi_cs2a_n, gsbi11_spi_cs2b_n, gsbi11_spi_cs3_n, + gsbi12, hdmi_cec, hdmi_ddc_clock, hdmi_ddc_data, +
Re: [PATCH] Staging: comedi: check the return value of kobject_set_name
On Wed, Jul 09, 2014 at 08:48:53AM +0400, Anton Protopopov wrote: > > > 09.07.2014 08:28, gregkh пишет: > > On Wed, Jul 09, 2014 at 08:24:06AM +0400, Anton Protopopov wrote: > >> 2014-06-09 14:01 GMT+04:00 Ian Abbott : > >>> On 2014-06-07 14:56, Anton Protopopov wrote: > > Added a check of the return value of the kobject_set_name function. > > Signed-off-by: Anton Protopopov > --- > drivers/staging/comedi/comedi_fops.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > >>> > >>> > >>> Reviewed-by: Ian Abbott > >> > >> This patch was lost, I guess? > > > > I don't seem to have it anymore in my inbox, please resend. > > > > greg k-h > > > > > Added a check of the return value of the kobject_set_name function. > > Signed-off-by: Anton Protopopov > --- > drivers/staging/comedi/comedi_fops.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Please send in a format I can apply in (i.e. I don't have to edit the changelog by hand...) -- 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: comedi: check the return value of kobject_set_name
09.07.2014 08:28, gregkh пишет:
> On Wed, Jul 09, 2014 at 08:24:06AM +0400, Anton Protopopov wrote:
>> 2014-06-09 14:01 GMT+04:00 Ian Abbott :
>>> On 2014-06-07 14:56, Anton Protopopov wrote:
Added a check of the return value of the kobject_set_name function.
Signed-off-by: Anton Protopopov
---
drivers/staging/comedi/comedi_fops.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>>
>>> Reviewed-by: Ian Abbott
>>
>> This patch was lost, I guess?
>
> I don't seem to have it anymore in my inbox, please resend.
>
> greg k-h
>
Added a check of the return value of the kobject_set_name function.
Signed-off-by: Anton Protopopov
---
drivers/staging/comedi/comedi_fops.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index 9d99fb3..dfeefa2 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -2597,7 +2597,14 @@ static int __init comedi_init(void)
return -EIO;
cdev_init(_cdev, _fops);
comedi_cdev.owner = THIS_MODULE;
- kobject_set_name(_cdev.kobj, "comedi");
+
+ retval = kobject_set_name(_cdev.kobj, "comedi");
+ if (retval) {
+ unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
+COMEDI_NUM_MINORS);
+ return retval;
+ }
+
if (cdev_add(_cdev, MKDEV(COMEDI_MAJOR, 0), COMEDI_NUM_MINORS)) {
unregister_chrdev_region(MKDEV(COMEDI_MAJOR, 0),
COMEDI_NUM_MINORS);
--
1.8.3.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/
[RESEND PATCHv2 1/2] regulator: of: Add support for parsing regulator_state for suspend state
The regulation_constraints structure includes specific field to support
suspend state for global PMIC STANDBY/HIBERNATE mode. This patch add support
for parsing regulator_state for suspend state.
Signed-off-by: Chanwoo Choi
---
drivers/regulator/of_regulator.c | 76 ++--
1 file changed, 74 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index ee5e67b..cf280ab 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -16,12 +16,20 @@
#include
#include
+const char *const regulator_states[PM_SUSPEND_MAX + 1] = {
+ [PM_SUSPEND_STANDBY]= "regulator-state-standby",
+ [PM_SUSPEND_MEM]= "regulator-state-mem",
+ [PM_SUSPEND_MAX]= "regulator-state-disk",
+};
+
static void of_get_regulation_constraints(struct device_node *np,
struct regulator_init_data **init_data)
{
- const __be32 *min_uV, *max_uV;
+ const __be32 *min_uV, *max_uV, *suspend_uV;
struct regulation_constraints *constraints = &(*init_data)->constraints;
- int ret;
+ struct regulator_state *suspend_state;
+ struct device_node *suspend_np;
+ int ret, i;
u32 pval;
constraints->name = of_get_property(np, "regulator-name", NULL);
@@ -70,6 +78,70 @@ static void of_get_regulation_constraints(struct device_node
*np,
ret = of_property_read_u32(np, "regulator-enable-ramp-delay", );
if (!ret)
constraints->enable_time = pval;
+
+ ret = of_property_read_u32(np, "regulator-initial-state", );
+ if (!ret) {
+ switch (pval) {
+ case PM_SUSPEND_STANDBY:
+ case PM_SUSPEND_MEM:
+ case PM_SUSPEND_MAX:
+ constraints->initial_state = pval;
+ break;
+ default:
+ break;
+ };
+ }
+
+ for (i = 0; i < ARRAY_SIZE(regulator_states); i++) {
+ switch (i) {
+ case PM_SUSPEND_STANDBY:
+ suspend_state = >state_standby;
+ break;
+ case PM_SUSPEND_MEM:
+ suspend_state = >state_mem;
+ break;
+ case PM_SUSPEND_MAX:
+ suspend_state = >state_disk;
+ break;
+ case PM_SUSPEND_ON:
+ case PM_SUSPEND_FREEZE:
+ default:
+ continue;
+ };
+
+ suspend_np = of_get_child_by_name(np, regulator_states[i]);
+ if (!suspend_np || !suspend_state)
+ continue;
+
+ suspend_uV = of_get_property(suspend_np, "regulator-volt",
NULL);
+ if (suspend_uV) {
+ suspend_state->uV = be32_to_cpu(*suspend_uV);
+
+ if (suspend_state->uV < constraints->min_uV)
+ suspend_state->uV = constraints->min_uV;
+ if (suspend_state->uV > constraints->max_uV)
+ suspend_state->uV = constraints->max_uV;
+ }
+
+ ret = of_property_read_u32(suspend_np, "regulator-mode", );
+ if (!ret) {
+ u32 regulator_mode = REGULATOR_MODE_FAST
+ | REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_IDLE
+ | REGULATOR_MODE_STANDBY;
+ if (pval <= regulator_mode)
+ suspend_state->mode = pval;
+ }
+
+ if (of_property_read_bool(suspend_np,
"regulator-on-in-suspend"))
+ suspend_state->enabled = true;
+
+ if (of_property_read_bool(suspend_np,
"regulator-off-in-suspend"))
+ suspend_state->disabled = true;
+
+ suspend_state = NULL;
+ suspend_np = NULL;
+ }
}
/**
--
1.8.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/
[RESEND PATCHv2 0/2] regulator: of: Add support for pasing regulator suspend state
The regulators would set different state/mode according to the kind of suspend
state. So regulation_constraints structure has already regulator suspend state
filed.
This patch parse regulator suspend state from devicetree file.
For example:
ldoX_reg: LDOx {
regulator-name = "VAP_XXX_1.2V";
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
regulator-always-on;
regulator-initial-state = <3>; /* PM_SUSPEND_MEM */
regulator-state-standby {
regulator-volt = <120>;
};
regulator-state-mem {
regulator-volt = <120>;
regulator-off-in-suspend;
};
regulator-state-disk {
regulator-volt = <120>;
regulator-on-in-suspend;
};
};
Changes from v1:
- Check whether regulator-initial-state and regulator-mode is correct or not
- Add more detailed description about regulator-initial-state, regulator-mode
and regulator-state-[standby/mem/disk] for devicetree bindings
- Modify example of regulator suspend state in bindings documentation
Chanwoo Choi (2):
regulator: of: Add support for parsing regulator_state for suspend state
dt-bindings: regulator: Add regulator suspend state for PM state
.../devicetree/bindings/regulator/regulator.txt| 32 +
drivers/regulator/of_regulator.c | 76 +-
2 files changed, 106 insertions(+), 2 deletions(-)
--
1.8.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/
[RESEND PATCHv2 2/2] dt-bindings: regulator: Add regulator suspend state for PM state
This patch add regulator suspend state to constraint in dt file. The regulation_
constraints structure already has regulator suspend state field as following.
The regulator suspend state control the state of regulator according to
PM (Power Management) state.
- struct regulator_state state_disk
- struct regulator_state state_mem
- struct regulator_state state_standby
Signed-off-by: Chanwoo Choi
---
.../devicetree/bindings/regulator/regulator.txt| 32 ++
1 file changed, 32 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 8607433..c4f566a 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -19,6 +19,33 @@ Optional properties:
design requires. This property describes the total system ramp time
required due to the combination of internal ramping of the regulator itself,
and board design issues such as trace capacitance and load on the supply.
+- regulator-initial-state: initial state for suspend state, cnd set initial
+ state among following defined suspend states:
+ <2>: PM_SUSPEND_STANDBY - Setup regulator according to
regulator-state-standby
+ <3>: PM_SUSPEND_MEM - Setup regulator according to regulator-state-mem
+ <4>: PM_SUSPEND_MAX - Setup regulator according to regulator-state-disk
+- regulator-state-standby sub-root node for Standby mode
+ : the device is in a power-saving state, but can also receive certain events,
+ specific behavior depends on the specific device.
+- regulator-state-mem sub-root node for Suspend-to-RAM mode
+ : suspend to memory, the device goes to sleep, but all data stored in memory,
+ only some external interrupt can wake the device.
+- regulator-state-disk sub-root node for Suspend-to-disk mode
+ : suspend to disk, this state operates similarly to Suspend-to-RAM,
+ but includes a final step of writing memory contents to disk.
+- regulator-state-[standby/mem/disk] node has following common properties:
+ - regulator-volt: voltage consumers may set in suspend state.
+ - regulator-mode: voltage mode in suspend state, can set mode among
+ following defined regulator modes:
+ 0x1: REGULATOR_MODE_FAST, Regulator can handle fast changes.
+ 0x2: REGULATOR_MODE_NORMAL, Normal regulator power supply mode.
+ 0x4: REGULATOR_MODE_IDLE, Regulator runs in a more efficient mode.
+ 0x8: REGULATOR_MODE_STANDBY, Regulator runs in the most efficient mode.
+ - regulator-on-in-suspend: regulator should be on in suspend state.
+ - regulator-off-in-suspend: regulator should be off in suspend state.
+ If node don't include regulator-[on/off]-in-suspend, can't change
+ regulator state in suspend mode and only should sustain the regulator
+ state of normal state.
Deprecated properties:
- regulator-compatible: If a regulator chip contains multiple
@@ -34,6 +61,11 @@ Example:
regulator-max-microvolt = <250>;
regulator-always-on;
vin-supply = <>;
+
+ regulator-state-mem {
+ regulator-volt = <100>;
+ regulator-off-in-suspend;
+ };
};
Regulator Consumers:
--
1.8.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] Staging: comedi: check the return value of kobject_set_name
On Wed, Jul 09, 2014 at 08:24:06AM +0400, Anton Protopopov wrote: > 2014-06-09 14:01 GMT+04:00 Ian Abbott : > > On 2014-06-07 14:56, Anton Protopopov wrote: > >> > >> Added a check of the return value of the kobject_set_name function. > >> > >> Signed-off-by: Anton Protopopov > >> --- > >> drivers/staging/comedi/comedi_fops.c | 9 - > >> 1 file changed, 8 insertions(+), 1 deletion(-) > > > > > > Reviewed-by: Ian Abbott > > This patch was lost, I guess? I don't seem to have it anymore in my inbox, please resend. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] staging: lustre: libcfs: nidstrings.c - use ARRAY_SIZE macro
On Wednesday 09 July 2014 05:18 AM, Greg KH wrote: > Someone sent this same patch just before you did, sorry :( > Ah - no worries - sorry for the noise. -- 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: comedi: check the return value of kobject_set_name
2014-06-09 14:01 GMT+04:00 Ian Abbott : > On 2014-06-07 14:56, Anton Protopopov wrote: >> >> Added a check of the return value of the kobject_set_name function. >> >> Signed-off-by: Anton Protopopov >> --- >> drivers/staging/comedi/comedi_fops.c | 9 - >> 1 file changed, 8 insertions(+), 1 deletion(-) > > > Reviewed-by: Ian Abbott This patch was lost, I guess? > > -- > -=( Ian Abbott @ MEV Ltd.E-mail: )=- > -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 2/3] rcu: Add designated reviewers for RCU
On Tue, 2014-07-08 at 15:25 -0700, Paul E. McKenney wrote: > On Tue, Jul 08, 2014 at 03:05:16PM -0700, Joe Perches wrote: [] > > I still think the concept is pretty useless and it's > > just a duplication of "M:", which isn't anything other > > than a list of who should be sent patches. [] > It will be interesting to see how things go. Yes, it might work out fine and maybe might cause some other beneficial changes. > There did seem to be > some people who were comfortable being listed as RCU reviewers, but > not as RCU maintainers. Perhaps the same thing happens elsewhere. Maybe so. I wrote a script to find which maintainer addresses that haven't signed or authored a commit in the last 2 years. I got ~250 entries. That's about 1/4 of all maintainer email addresses. Maybe a dozen of these are false positives though because some maintainers prefer to receive email at one address but ack from another. These are all lowercase for better matching. abhijit mahajan achim leubner adam radford al cho ali akcaagac allan stephens aloisio almeida jr andreas dilger andreas koensgen andrew hendry andrew veliath andries brouwer andy henroid anil ravindranath anil s keshavamurthy antoine jacquet antonino daplas armin schindler artur paszkiewicz "arvind r." ashley lai aurelien jacquiot balbir singh bill metzenthen bradley grove brett rudley brian johnson bruce chang bryan huntsman ceph-de...@vger.kernel.org cesar miquel cezary jackiewicz chaoming li chen liqin chien yen chirag kantharia chris brannon christine caulfield christopher harrer "christopher li" christoph raisch cliff whickman colin leroy corentin labbe daniel drake daniele venzano daniel oliveira nascimento daniel ribeiro dario ballabio david kershner david rowe david safford david täht deepak saxena dirk eibach dirk opfer dmitry tarnyagin dominik brodowski doug gilbert doug thompson doug warzecha duncan sands "ed l. cashin" egor martovetsky eric biederman eric piel erik andren faisal latif ferenc bakonyi florian schilhabel . forest bond frank seidel fujita tomonori gary zambrano gilles muller gleb natapov guillaume ligneul guo-fu tseng gustavo padovan haavard skinnemoen hal rosenstock hansjoerg lipp hans ulli kroll harald welte harald welte henk vergonet henrique de moraes holschuh herton ronaldo krzesinski heungjun kim hideaki yoshifuji hoang-nam nguyen hubert feurstein "hung hing lun, mike" ian campbell ian molton ion badulescu ishizaki kou ivan kokshaysky jakub schmidtke "james e.j. bottomley" "james e.j. bottomley" "james e.j. bottomley" james morris "james r. van zandt" jamie lenehan jan-benedict glaw jan dumon jan harkes jan-simon moeller jarkko lavinen jarod wilson jason uhlenkott jaya kumar jaya kumar jay cliburn jean-paul roubelat jeff dike jens osterkamp jes sorensen jim paris jiri kosina jiri slaby joerg reuter joern engel johan hedberg john mccutchan john ronciak "john w. linville" jonathan buzzard "jon d. mason" jon nettleton josh triplett joshua morris joshua thompson juanjo ciarlante "juergen e. fischer" juergen stuber juerg haefliger kentaro takeda kevin curtis kevin hilman kirk reiser koichi yasutake kristoffer glembo kurt garloff leandro costantino len brown lennert buytenhek liam girdwood liam girdwood lior dotan "luis r. rodriguez" maik broemme manohar vanga marcelo henrique cerri marc hulsman "mark f. brown" martin mares matthew wilcox matt mackall maxim krasnyansky michael hanselmann michael petchkovsky michael reed michal januszewski michal ostrowski miguel ojeda sandonis mikael starvik mike marciniszyn mike rapoport miloslav trmac miroslav zagorac mitchell blank jr muli ben-yehuda nagalakshmi nandigama neela syam kolli nelson castillo nicholas a. bellinger nick piggin olav kongas olivier lorin pantelis antoniou pat gefre paul mackerras pau oliva fora peter chubb peter feuerer philip blundell philip kelleher philip moltmann praveen krishnamoorthy rakesh iyer ranganathan desikan remi denis-courmont riccardo facchetti richard l maliszewski "richard russon (flatcap)" rik faith robert gerlach robert love robert love rob herring roland dreier roland mcgrath ron mercer ron minnich samuel chessman santosh raspatur scott murray sergey lapin shane wang simon arlott simon kelley sorbica shieh srinivas kandagatla stefan eletzhofer stefano brivio steve french steve sakoman steve underwood steve wise subbu seetharaman sudarsana kalluru sujith thomas teddy wang terje bergström thibaut varene thomas dahlmann thomas winischhofer "tigran a. aivazian" tigran aivazian till harbaum tim small tim waugh tony finch tony olech torben mathiasen ulrich kunitz vegard nossum ville syrjala vishwas a deshpande vitaly bordug vitaly bordug wensong zhang willem riede willy tarreau "wong hoi sing, edison" xavier
Re: [PATCH 4/9] perf, tools: Automatically look for event file name for cpu v3
> Is EVENTMAP a new environment variable ? If specific to PERF, should > we prefix it with "PERF_" to avoid collision? It's not perf specific, but shared with other tools (e.g. pmu-tools) > > Would all/many architectures need this "-core" suffix or is that Intel > specific ? You don't need it, just specify a full name. > Is the intent that architectures that don't need this should simply > never set EVENTMAP variable ? Any architecture can use EVENTMAP, it just points to a json file. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] rcu: use true/false instead of 1/0 for a bool type
One more bool type change which I found while reading the code.
Use true/false instead of 0/1 for a bool type
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 1b70cb6..bc7b6f1 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1668,7 +1668,7 @@ static int rcu_gp_fqs(struct rcu_state *rsp, int
fqs_state_in)
if (fqs_state == RCU_SAVE_DYNTICK) {
/* Collect dyntick-idle snapshots. */
if (is_sysidle_rcu_state(rsp)) {
- isidle = 1;
+ isidle = true;
maxj = jiffies - ULONG_MAX / 4;
}
force_qs_rnp(rsp, dyntick_save_progress_counter,
@@ -1677,7 +1677,7 @@ static int rcu_gp_fqs(struct rcu_state *rsp, int
fqs_state_in)
fqs_state = RCU_FORCE_QS;
} else {
/* Handle dyntick-idle and offline CPUs. */
- isidle = 0;
+ isidle = false;
force_qs_rnp(rsp, rcu_implicit_dynticks_qs, , );
}
/* Clear flag to prevent immediate re-entry. */
@@ -2449,7 +2449,7 @@ static void force_qs_rnp(struct rcu_state *rsp,
for (; cpu <= rnp->grphi; cpu++, bit <<= 1) {
if ((rnp->qsmask & bit) != 0) {
if ((rnp->qsmaskinit & bit) != 0)
- *isidle = 0;
+ *isidle = false;
if (f(per_cpu_ptr(rsp->rda, cpu), isidle, maxj))
mask |= bit;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
On Wednesday, July 09, 2014 12:42 PM, Sachin Kamat wrote: > On Tue, Jul 8, 2014 at 9:15 PM, Tomasz Figa wrote: > > On 30.06.2014 10:56, Sachin Kamat wrote: > >> Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, > > > > That's not true. They are also required for USB gadget controller > > supported by the DWC2 gadget driver (formerly s3c-hsotg). Otherwise the > > change makes sense to me. > > Do you propose I amend just the patch description or also add a dependency on > USB_DWC2 along with EHCI and OHCI. I do not have anything to test this. Based > on your input I will re-spin the patch. I agree with Tomasz Figa's statement. Personally, I think that it would be good to amend the commit message and add a dependency on USB_DWC2. :-) Thank you. Best regards, Jingoo Han > > -- > Regards, > Sachin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/intel_drv.h between commit 72f5fd2a9815
("drm/i915/vlv: T12 eDP panel timing enforcement during reboot") from
the drm-intel-fixes tree and commit 6118efe5968c ("drm/i915: move
psr_setup_done to psr struct") from the drm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_drv.h
index f67340ed2c12,5f7c7bd94d90..
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -537,9 -541,6 +541,8 @@@ struct intel_dp
unsigned long last_power_cycle;
unsigned long last_power_on;
unsigned long last_backlight_off;
- bool psr_setup_done;
+ struct notifier_block edp_notifier;
+
bool use_tps3;
struct intel_connector *attached_connector;
signature.asc
Description: PGP signature
[PATCH v7 1/4] ARM: EXYNOS: Add support for mapping PMU base address via DT
Add support for mapping Samsung Power Management Unit (PMU)
base address from device tree.
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/common.h |1 +
arch/arm/mach-exynos/exynos.c | 37 +
2 files changed, 38 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 152b464..f8daa9c 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -113,6 +113,7 @@ IS_SAMSUNG_CPU(exynos5800, EXYNOS5800_SOC_ID,
EXYNOS5_SOC_MASK)
extern void __iomem *sysram_ns_base_addr;
extern void __iomem *sysram_base_addr;
+extern void __iomem *pmu_base_addr;
void exynos_sysram_init(void);
void exynos_firmware_init(void);
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 186f35d..173aac8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -31,6 +32,8 @@
#include "regs-pmu.h"
#include "regs-sys.h"
+void __iomem *pmu_base_addr;
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -253,6 +256,39 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+static const struct of_device_id exynos_dt_pmu_match[] = {
+ { .compatible = "samsung,exynos3250-pmu" },
+ { .compatible = "samsung,exynos4210-pmu" },
+ { .compatible = "samsung,exynos4212-pmu" },
+ { .compatible = "samsung,exynos4412-pmu" },
+ { .compatible = "samsung,exynos5250-pmu" },
+ { .compatible = "samsung,exynos5420-pmu" },
+ { /*sentinel*/ },
+};
+
+static void exynos_map_pmu(void)
+{
+ struct device_node *np;
+
+ np = of_find_matching_node(NULL, exynos_dt_pmu_match);
+ if (np)
+ pmu_base_addr = of_iomap(np, 0);
+
+ if (!pmu_base_addr)
+ panic("failed to find exynos pmu register\n");
+}
+
+static void __init exynos_init_irq(void)
+{
+ irqchip_init();
+ /*
+* Since platsmp.c needs pmu base address by the time
+* DT is not unflatten so we can't use DT APIs before
+* init_irq
+*/
+ exynos_map_pmu();
+}
+
static void __init exynos_dt_machine_init(void)
{
struct device_node *i2c_np;
@@ -336,6 +372,7 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened
Device Tree)")
.smp= smp_ops(exynos_smp_ops),
.map_io = exynos_init_io,
.init_early = exynos_firmware_init,
+ .init_irq = exynos_init_irq,
.init_machine = exynos_dt_machine_init,
.init_late = exynos_init_late,
.dt_compat = exynos_dt_compat,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/4] ARM: Exynos: PMU cleanup and refactoring for using DT
This patch series, modifies Exynos Power Management Unit (PMU) related code for converting it into a platform_driver. This is also preparation for moving PMU related code out of machine folder into a either "drivers/mfd", or "drivers/power" or some other suitable place so that ARM64 based SoC can utilize common piece of code. These patches are created on top of Kukjin Kim's for-next. I have tested this patches on Exynos5250 Snow board for system boot and S2R. This patch series depends on following two patch series: [1]: mfd: syscon: Decouple syscon interface from syscon devices. https://lkml.org/lkml/2014/6/24/188 [2]: Cleanup patches for mach-exynos. http://www.spinics.net/lists/arm-kernel/msg341474.html Patch v6 and discussion can be found here: https://lkml.org/lkml/2014/7/7/22 Change since v6: - Removed NULL check for pmu_data in pmu.c. - Moved pmu_raw_readl and pmu_raw_writel inline helper function into common.h. Change Since v5: - Squashed patch "Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c" into patch "Refactored code for using PMU address via DT". - Addressed review comments from Tomasz Figa. - Using init_irq machine function to initialize PMU mapping instead of init_time. - Rebased on latest Kukjin Kim's for-next branch. Changes Since v4: - Splitted patch series in two parts. Part 1 has code cleanup under mach-exynos and posted as separate patch [2]. Current patchset is part 2 which modified exynos pmu implementation for making it platform driver. - Removed dependency over early_syscon API. - Removed usage of regmap read/write APIs. - Modified probe function to register exynos pmu as syscon provider using Tomasz Figa's syscon patch [1]. - Address various other review comments from Tomasz Figa. - Removed signed-off-by of Young-Gun Jang , as this id is no more valid. Taking ownership of all his patches. Changes Since v3: - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init as suggested by Vikas Sajjan. - Modified syscon_early_regmap_lookup_by_phandle and syscon_regmap_lookup_by_phandle function call to pass property as NULL. Changes Since v2: - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches. - Removed early mapping of PMU base address from exynos.c and removed "get_exynos_pmuaddr" function. Instead of this added code in platsmp.c to get PMU base address using of_iomap as suggested by Tomasz Figa. - Converted PMU implementation into platform_driver by using static platform_device method. Changes Since v1: - Rebased on latest for-next of Kukjin Kim's tree. - Updated patch: Add support for mapping PMU base address via DT - Removed __initdata from declaration of "exynos_pmu_base", as it caused kernel crash as pointed out by Vikas Sajjan. - Added support for Syscon initialization and getting PMU regmap handle as suggested by Sylwester. Since current implementation of early intialization [1] has limitation that "early_syscon_init" requires DT to be unflattened and system should be able to allocate memory, we can't use regmap handles for platsmp.c file as "smp_secondary_init" will be called before DT unflattening. So I have kept both method for accessing PMU base address. platsmp.c will use ioremmaped address where as rest other files can use regmap handle. - Updated patch: Refactored code for PMU register mapping via DT - Modified to use regmap_read/write when using regmap handle. - Added patch: Add device tree based initialization support for PMU. - Convert existing PMU implementation to be a device tree based before moving it to "drivers/mfd" folder. As suggested by Bartlomiej. - Dropped making a platform_driver for PMU, as currently PMU binding has two compatibility strings as "samsung, exynosxxx-pmu", "syscon", once we enable MFD_SYSCON config option, current "syscon" driver probe gets called and PMU probe never gets called. So modified PMU initialization code to scan DT and match against supported compatiblity string in driver code, and once we get matching node use that for accessing PMU regmap handle using "syscon_early_regmap_lookup_by_phandle". If there is any better solution please suggest. Pankaj Dubey (4): ARM: EXYNOS: Add support for mapping PMU base address via DT ARM: EXYNOS: Refactored code for using PMU address via DT ARM: EXYNOS: Add platform driver support for Exynos PMU ARM: EXYNOS: Move PMU specific definitions from common.h arch/arm/mach-exynos/Kconfig |1 + arch/arm/mach-exynos/common.h| 28 +- arch/arm/mach-exynos/exynos-pmu.h| 24 ++ arch/arm/mach-exynos/exynos.c| 49 ++- arch/arm/mach-exynos/include/mach/map.h |3 - arch/arm/mach-exynos/mcpm-exynos.c |8 +-
[PATCH v7 3/4] ARM: EXYNOS: Add platform driver support for Exynos PMU
This patch modifies Exynos Power Management Unit (PMU) initialization
implementation in following way:
- Added platform driver support and probe function where Exynos PMU
driver will register itself as syscon provider with syscon framework.
- Added platform struct exynos_pmu_data to hold platform specific data.
- For each SoC's PMU support now we can add platform data and statically
bind PMU configuration and SoC specific initialization function.
- Separate each SoC's PMU initialization function and make it as part of
platform data.
- It also removes uses of soc_is_exynosXYZ().
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/pmu.c | 185 +-
2 files changed, 146 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 8f9b66c..a2944ac 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -24,6 +24,7 @@ menuconfig ARCH_EXYNOS
select PM_GENERIC_DOMAINS if PM_RUNTIME
select S5P_DEV_MFC
select SRAM
+ select MFD_SYSCON
help
Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index ff9d23f..5b76728 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2012 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2011-2014 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
*
* EXYNOS - CPU PMU(Power Management Unit) support
@@ -10,12 +10,28 @@
*/
#include
-#include
+#include
+#include
+#include
+#include
#include "common.h"
#include "regs-pmu.h"
-static const struct exynos_pmu_conf *exynos_pmu_config;
+struct exynos_pmu_data {
+ const struct exynos_pmu_conf *pmu_config;
+ const struct exynos_pmu_conf *pmu_config_extra;
+
+ void (*pmu_init)(void);
+ void (*powerdown_conf)(enum sys_powerdown);
+};
+
+struct exynos_pmu_context {
+ struct device *dev;
+ const struct exynos_pmu_data *pmu_data;
+};
+
+static struct exynos_pmu_context *pmu_context;
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
@@ -335,7 +351,7 @@ static unsigned int const exynos5_list_diable_wfi_wfe[] = {
EXYNOS5_ISP_ARM_OPTION,
};
-static void exynos5_init_pmu(void)
+static void exynos5_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
unsigned int tmp;
@@ -372,51 +388,140 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
{
unsigned int i;
- if (soc_is_exynos5250())
- exynos5_init_pmu();
+ const struct exynos_pmu_data *pmu_data = pmu_context->pmu_data;
- for (i = 0; (exynos_pmu_config[i].offset != PMU_TABLE_END) ; i++)
- pmu_raw_writel(exynos_pmu_config[i].val[mode],
- exynos_pmu_config[i].offset);
+ if (pmu_data->powerdown_conf)
+ pmu_data->powerdown_conf(mode);
- if (soc_is_exynos4412()) {
- for (i = 0; exynos4412_pmu_config[i].offset != PMU_TABLE_END ;
i++)
- pmu_raw_writel(exynos4412_pmu_config[i].val[mode],
- exynos4412_pmu_config[i].offset);
+ if (pmu_data->pmu_config) {
+ for (i = 0; (pmu_data->pmu_config[i].offset != PMU_TABLE_END) ;
i++)
+ pmu_raw_writel(pmu_data->pmu_config[i].val[mode],
+ pmu_data->pmu_config[i].offset);
+ }
+
+ if (pmu_data->pmu_config_extra) {
+ for (i = 0; pmu_data->pmu_config_extra[i].offset !=
PMU_TABLE_END; i++)
+ pmu_raw_writel(pmu_data->pmu_config_extra[i].val[mode],
+ pmu_data->pmu_config_extra[i].offset);
}
}
-static int __init exynos_pmu_init(void)
+static void exynos5250_pmu_init(void)
{
unsigned int value;
+ /*
+* When SYS_WDTRESET is set, watchdog timer reset request
+* is ignored by power management unit.
+*/
+ value = pmu_raw_readl(EXYNOS5_AUTO_WDTRESET_DISABLE);
+ value &= ~EXYNOS5_SYS_WDTRESET;
+ pmu_raw_writel(value, EXYNOS5_AUTO_WDTRESET_DISABLE);
+
+ value = pmu_raw_readl(EXYNOS5_MASK_WDTRESET_REQUEST);
+ value &= ~EXYNOS5_SYS_WDTRESET;
+ pmu_raw_writel(value, EXYNOS5_MASK_WDTRESET_REQUEST);
+}
+
+static const struct exynos_pmu_data exynos4210_pmu_data = {
+ .pmu_config = exynos4210_pmu_config,
+};
+
+static const struct exynos_pmu_data exynos4212_pmu_data = {
+ .pmu_config = exynos4x12_pmu_config,
+};
+
+static const struct exynos_pmu_data exynos4412_pmu_data = {
+ .pmu_config = exynos4x12_pmu_config,
+ .pmu_config_extra = exynos4412_pmu_config,
+};
+
[PATCH v7 4/4] ARM: EXYNOS: Move PMU specific definitions from common.h
This patch moves PMU specific definitions into a new file
as exynos-pmu.h.
This will help in reducing dependency of common.h in pmu.c.
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/common.h | 17 -
arch/arm/mach-exynos/exynos-pmu.h | 24
arch/arm/mach-exynos/pm.c |1 +
arch/arm/mach-exynos/pmu.c| 20 +++-
4 files changed, 44 insertions(+), 18 deletions(-)
create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 47b904b..9019d86 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -132,23 +132,6 @@ extern struct smp_operations exynos_smp_ops;
extern void exynos_cpu_die(unsigned int cpu);
-/* PMU(Power Management Unit) support */
-
-#define PMU_TABLE_END (-1U)
-
-enum sys_powerdown {
- SYS_AFTR,
- SYS_LPA,
- SYS_SLEEP,
- NUM_SYS_POWERDOWN,
-};
-
-struct exynos_pmu_conf {
- unsigned int offset;
- unsigned int val[NUM_SYS_POWERDOWN];
-};
-
-extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
extern void exynos_cpu_power_down(int cpu);
extern void exynos_cpu_power_up(int cpu);
extern int exynos_cpu_power_state(int cpu);
diff --git a/arch/arm/mach-exynos/exynos-pmu.h
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..a2ab0d5
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+enum sys_powerdown {
+ SYS_AFTR,
+ SYS_LPA,
+ SYS_SLEEP,
+ NUM_SYS_POWERDOWN,
+};
+
+extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index bcb96be..b2efe8c 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -34,6 +34,7 @@
#include
#include "common.h"
+#include "exynos-pmu.h"
#include "regs-pmu.h"
#include "regs-sys.h"
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 5b76728..117f333 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -15,9 +15,16 @@
#include
#include
-#include "common.h"
+#include "exynos-pmu.h"
#include "regs-pmu.h"
+#define PMU_TABLE_END (-1U)
+
+struct exynos_pmu_conf {
+ unsigned int offset;
+ unsigned int val[NUM_SYS_POWERDOWN];
+};
+
struct exynos_pmu_data {
const struct exynos_pmu_conf *pmu_config;
const struct exynos_pmu_conf *pmu_config_extra;
@@ -31,8 +38,19 @@ struct exynos_pmu_context {
const struct exynos_pmu_data *pmu_data;
};
+static void __iomem *pmu_base_addr;
static struct exynos_pmu_context *pmu_context;
+static inline void pmu_raw_writel(u32 val, u32 offset)
+{
+ __raw_writel(val, pmu_base_addr + offset);
+}
+
+static inline u32 pmu_raw_readl(u32 offset)
+{
+ return __raw_readl(pmu_base_addr + offset);
+}
+
static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
/* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
{ S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: + shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch added to -mm tree
On 07/02/2014 03:25 PM, a...@linux-foundation.org wrote:
>
> The patch titled
> Subject: shmem: fix faulting into a hole while it's punched, take 2
> has been added to the -mm tree. Its filename is
> shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch
>
> This patch should soon appear at
>
> http://ozlabs.org/~akpm/mmots/broken-out/shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch
> and later at
>
> http://ozlabs.org/~akpm/mmotm/broken-out/shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch
>
> Before you just go and hit "reply", please:
>a) Consider who else should be cc'ed
>b) Prefer to cc a suitable mailing list as well
>c) Ideally: find the original patch on the mailing list and do a
> reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> --
> From: Hugh Dickins
> Subject: shmem: fix faulting into a hole while it's punched, take 2
>
> Trinity finds that mmap access to a hole while it's punched from shmem can
> prevent the madvise(MADV_REMOVE) or fallocate(FALLOC_FL_PUNCH_HOLE) from
> completing, until the (killable) reader stops; with the puncher's hold on
> i_mutex locking out all other writers until it can complete. This issue
> was tagged with CVE-2014-4171.
>
> It appears that the tmpfs fault path is too light in comparison with its
> hole-punching path, lacking an i_data_sem to obstruct it; but we don't
> want to slow down the common case. It is not a problem in truncation,
> because there the SIGBUS beyond i_size stops pages from being appended.
>
> The origin of this problem is my v3.1 commit d0823576bf4b ("mm: pincer in
> truncate_inode_pages_range"), once it was duplicated into shmem.c. It
> seemed like a nice idea at the time, to ensure (barring RCU lookup
> fuzziness) that there's an instant when the entire hole is empty; but the
> indefinitely repeated scans to ensure that make it vulnerable.
>
> Revert that "enhancement" to hole-punch from shmem_undo_range(), but
> retain the unproblematic rescanning when it's truncating; add a couple of
> comments there.
>
> Remove the "indices[0] >= end" test: that is now handled satisfactorily by
> the inner loop, and mem_cgroup_uncharge_start()/end() are too light to be
> worth avoiding here.
>
> But if we do not always loop indefinitely, we do need to handle the case
> of swap swizzled back to page before shmem_free_swap() gets it: add a
> retry for that case, as suggested by Konstantin Khlebnikov.
>
> Reported-by: Sasha Levin
> Suggested-and-Tested-by: Vlastimil Babka
> Signed-off-by: Hugh Dickins
> Cc: Konstantin Khlebnikov
> Cc: Lukas Czerner
> Cc: Dave Jones
> Cc: [3.1+]
> Signed-off-by: Andrew Morton
I suspect there's something off with this patch, as the shmem_fallocate
hangs are back... Pretty much same as before:
[ 363.600969] INFO: task trinity-c327:9203 blocked for more than 120 seconds.
[ 363.605359] Not tainted
3.16.0-rc4-next-20140708-sasha-00022-g94c7290-dirty #772
[ 363.609730] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 363.615861] trinity-c327D 000b 13496 9203 8559 0x1004
[ 363.620284] 8800b857bce8 0002 9dc11b10
0001
[ 363.624468] 88010486 8800b857bfd8 001d7740
001d7740
[ 363.629118] 880104863000 88010486 8800b857bcd8
8801eaed8868
[ 363.633879] Call Trace:
[ 363.635442] [] schedule+0x65/0x70
[ 363.638638] [] schedule_preempt_disabled+0x18/0x30
[ 363.642833] [] mutex_lock_nested+0x2e5/0x550
[ 363.646599] [] ? shmem_fallocate+0x6c/0x350
[ 363.651319] [] ? get_parent_ip+0x11/0x50
[ 363.654683] [] ? shmem_fallocate+0x6c/0x350
[ 363.658264] [] shmem_fallocate+0x6c/0x350
[ 363.662010] [] ? put_lock_stats.isra.12+0xe/0x30
[ 363.665866] [] do_fallocate+0x153/0x1d0
[ 363.669381] [] SyS_madvise+0x33f/0x970
[ 363.672906] [] tracesys+0xe1/0xe6
[ 363.682900] 2 locks held by trinity-c327/9203:
[ 363.684928] #0: (sb_writers#12){.+.+.+}, at: []
do_fallocate+0x13d/0x1d0
[ 363.715102] #1: (>s_type->i_mutex_key#16){+.+.+.}, at:
[] shmem_fallocate+0x6c/0x350
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/
[PATCH v7 2/4] ARM: EXYNOS: Refactored code for using PMU address via DT
Under "arm/mach-exynos" many files are using PMU register offsets.
Since we have added support for accessing PMU base address via DT,
now we can remove PMU mapping from exynosX_iodesc. Let's convert
all these access using iomapped address.
This will help us in removing static mapping of PMU base address
as well as help in reducing dependency over machine header files.
Thus helping for migration of PMU implementation from machine to
driver folder which can be reused for ARM64 bsed SoC.
Also as we have removed static mappings from "regs-pmu.h" it does
not need map.h anymore. But "platsmp.c" needed this and till now it
got included indirectly. So lets move header inclusion of
"mach/map.h" from "regs-pmu.h" to "platsmp.c".
Signed-off-by: Pankaj Dubey
Reviewed-by: Tomasz Figa
---
arch/arm/mach-exynos/common.h| 14 +-
arch/arm/mach-exynos/exynos.c| 12 +-
arch/arm/mach-exynos/include/mach/map.h |3 -
arch/arm/mach-exynos/mcpm-exynos.c |8 +-
arch/arm/mach-exynos/platsmp.c |4 +-
arch/arm/mach-exynos/pm.c| 76 ++--
arch/arm/mach-exynos/pmu.c | 40 +-
arch/arm/mach-exynos/regs-pmu.h | 522 +-
arch/arm/plat-samsung/include/plat/map-s5p.h |1 -
9 files changed, 339 insertions(+), 341 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index f8daa9c..47b904b 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -134,7 +134,7 @@ extern void exynos_cpu_die(unsigned int cpu);
/* PMU(Power Management Unit) support */
-#define PMU_TABLE_END NULL
+#define PMU_TABLE_END (-1U)
enum sys_powerdown {
SYS_AFTR,
@@ -144,7 +144,7 @@ enum sys_powerdown {
};
struct exynos_pmu_conf {
- void __iomem *reg;
+ unsigned int offset;
unsigned int val[NUM_SYS_POWERDOWN];
};
@@ -160,4 +160,14 @@ extern void exynos_enter_aftr(void);
extern void s5p_init_cpu(void __iomem *cpuid_addr);
extern unsigned int samsung_rev(void);
+static inline void pmu_raw_writel(u32 val, u32 offset)
+{
+ __raw_writel(val, pmu_base_addr + offset);
+}
+
+static inline u32 pmu_raw_readl(u32 offset)
+{
+ return __raw_readl(pmu_base_addr + offset);
+}
+
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 173aac8..d75d3e8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -61,11 +61,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
.length = SZ_4K,
.type = MT_DEVICE,
}, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS4_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
- }, {
.virtual= (unsigned long)S5P_VA_COMBINER_BASE,
.pfn= __phys_to_pfn(EXYNOS4_PA_COMBINER),
.length = SZ_4K,
@@ -139,11 +134,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
.pfn= __phys_to_pfn(EXYNOS5_PA_CMU),
.length = 144 * SZ_1K,
.type = MT_DEVICE,
- }, {
- .virtual= (unsigned long)S5P_VA_PMU,
- .pfn= __phys_to_pfn(EXYNOS5_PA_PMU),
- .length = SZ_64K,
- .type = MT_DEVICE,
},
};
@@ -151,7 +141,7 @@ static void exynos_restart(enum reboot_mode mode, const
char *cmd)
{
struct device_node *np;
u32 val = 0x1;
- void __iomem *addr = EXYNOS_SWRESET;
+ void __iomem *addr = pmu_base_addr + EXYNOS_SWRESET;
if (of_machine_is_compatible("samsung,exynos5440")) {
u32 status;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 963002f..f0b7e92 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -27,9 +27,6 @@
#define EXYNOS4_PA_SYSCON 0x1001
#define EXYNOS5_PA_SYSCON 0x10050100
-#define EXYNOS4_PA_PMU 0x1002
-#define EXYNOS5_PA_PMU 0x1004
-
#define EXYNOS4_PA_CMU 0x1003
#define EXYNOS5_PA_CMU 0x1001
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 9315ba9..70e8ccd 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -55,7 +55,7 @@
"dsb\n\t" \
"ldmfd sp!, {fp, ip}" \
: \
- : "Ir" (S5P_INFORM0) \
+ : "Ir" (pmu_base_addr + S5P_INFORM0) \
: "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", \
"r9", "r10", "lr", "memory")
@@ -337,7 +337,7 @@ static int __init
Re: [RFC PATCH 1/1] rcu: use atomic_read(v) instead of atomic_add_return(0, v)
On Tue, Jul 8, 2014 at 8:07 PM, Paul E. McKenney
wrote:
> On Tue, Jul 08, 2014 at 06:55:45PM -0400, Pranith Kumar wrote:
>> atomic_add_return() invalidates the cache line in other processors where-as
>> atomic_read does not. I don't see why we would need invalidation in this
>> case.
>> If indeed it was need a comment would be helpful for readers. Otherwise
>> doesn't
>> using atomic_read() make more sense here? RFC!
>>
>> replace atomic_add_return(0, v) with atomic_read(v) as the latter is better.
>>
>> Signed-off-by: Pranith Kumar
>
> This will break RCU -- the full memory barriers implied both before
> and after atomic_add_return() are needed in order for RCU to be able to
> avoid death due to memory reordering.
>
> That said, I have considered replacing the atomic_add_return() with:
>
> smp_mb();
> ... = atomic_read(...);
> smp_mb();
>
> However, this is a very ticklish change, and would need serious thought
> and even more serious testing.
>
Thank you for looking at the RFC. I tried understanding the code
deeper and found that the ordering which is needed here is actually on
dynticks_snap.
The ordering currently (by way of atomic_add_return) is on
rdp->dynticks->dynticks which I think is not right.
Looking at the history of the code led me to rev. 23b5c8fa01b723 which
makes me think that the above statement is true. I think providing
ordering guarantees on dynticks_snap should be enough.
I have added an updated patch below. However, it is really hard(and
error prone) to convince oneself that this is right. So I will not
pursue this further if you think this is wrong. You definitely know
better than me :)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 1b70cb6..bbccd0a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -891,7 +891,7 @@ static int rcu_is_cpu_rrupt_from_idle(void)
static int dyntick_save_progress_counter(struct rcu_data *rdp,
bool *isidle, unsigned long *maxj)
{
- rdp->dynticks_snap = atomic_add_return(0, >dynticks->dynticks);
+ smp_store_release(>dynticks_snap,
atomic_read(>dynticks->dynticks));
rcu_sysidle_check_cpu(rdp, isidle, maxj);
if ((rdp->dynticks_snap & 0x1) == 0) {
trace_rcu_fqs(rdp->rsp->name, rdp->gpnum, rdp->cpu, TPS("dti"));
@@ -920,8 +920,8 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
int *rcrmp;
unsigned int snap;
- curr = (unsigned int)atomic_add_return(0, >dynticks->dynticks);
- snap = (unsigned int)rdp->dynticks_snap;
+ curr = (unsigned int)atomic_read(>dynticks->dynticks);
+ snap = (unsigned int)smp_load_acquire(>dynticks_snap);
/*
* If the CPU passed through or entered a dynticks idle phase with
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Regression in 3.15 on POWER8 with multipath SCSI
On 07/08/2014 08:28 PM, Junichi Nomura wrote:
> On 07/02/14 04:39, Mike Snitzer wrote:
>> On Mon, Jun 30 2014 at 6:30am -0400,
>> Paul Mackerras wrote:
>>
>>> I have a machine on which 3.15 usually fails to boot, and 3.14 boots
>>> every time. The machine is a POWER8 2-socket server with 20 cores
>>> (thus 160 CPUs), 128GB of RAM, and 7 SCSI disks connected via a
>>> hardware-RAID-capable adapter which appears as two IPR controllers
>>> which are both connected to each disk. I am booting from a disk that
>>> has Fedora 20 installed on it.
>>>
>>> After over two weeks of bisections, I can finally point to the commits
>>> that cause the problems. The culprits are:
>>>
>>> 3e9f1be1 dm mpath: remove process_queued_ios()
>>> e8099177 dm mpath: push back requests instead of queueing
>>> bcccff93 kobject: don't block for each kobject_uevent
>>>
>>> The interesting thing is that neither e8099177 nor bcccff93 cause
>>> failures on their own, but with both commits in there are failures
>>> where the system will fail to find /home on some occasions.
>>>
>>> With 3e9f1be1 included, the system appears to be prone to a deadlock
>>> condition which typically causes the boot process to hang with this
>>> message showing:
>>>
>>> A start job is running for Monitoring of LVM2 mirror...rogress polling
>>>
>>> (with a [*** ] thing before it where the asterisks move back and
>>> forth).
>>>
>>> If I revert 63d832c3 ("dm mpath: really fix lockdep warning") ,
>>> 4cdd2ad7 ("dm mpath: fix lock order inconsistency in
>>> multipath_ioctl"), 3e9f1be1 and bcccff93, in that order, I get a
>>> kernel that will boot every time. The first two are later commits
>>> that fix some problems with 3e9f1be1 (though not the problems I am
>>> seeing).
>>>
>>> Can anyone see any reason why e8099177 and bcccff93 would interfere
>>> with each other?
>>
>> No, not seeing any obvious relation.
>>
>> But even though you listed e8099177 as a culprit you didn't list it as a
>> commit you reverted. Did you leave e8099177 simply because attempting
>> to revert it fails (if you don't first revert other dm-mpath.c commits)?
>>
>> (btw, Bart Van Assche also has issues with commit e8099177 due to hangs
>> during cable pull testing of mpath devices -- Bart: curious to know if
>> your cable pull tests pass if you just revert bcccff93).
>
> It seems Bart's issue has gone with the attached patch:
> http://www.redhat.com/archives/dm-devel/2014-July/msg00035.html
> Could you try if it makes any difference on your issue?
>
> The problem is dm-mpath's state machine stall due to e8099177
> but ioctl to the device can kick the state machine running again.
> That might be related to why bcccff93 affects the reproducibility.
> Also, 3e9f1be1 integrates some codes into the one which is affected
> by this problem. So it makes sense why the problem becomes easier
> to occur with that.
>
> -
> Jun'ichi Nomura, NEC Corporation
>
>
> pg_ready() checks the current state of the multipath and may return
> false even if a new IO is needed to change the state.
>
> OTOH, if multipath_busy() returns busy, a new IO will not be sent
> to multipath target and the state change won't happen. That results
> in lock up.
>
> The intent of multipath_busy() is to avoid unnecessary cycles of
> dequeue + request_fn + requeue if it is known that multipath device
> will requeue.
>
> Such situation would be:
> - path group is being activated
> - there is no path and the multipath is setup to requeue if no path
>
> This patch should fix the problem introduced as a part of this commit:
> commit e809917735ebf1b9a56c24e877ce0d320baee2ec
> dm mpath: push back requests instead of queueing
>
> diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
> index ebfa411..d58343e 100644
> --- a/drivers/md/dm-mpath.c
> +++ b/drivers/md/dm-mpath.c
> @@ -1620,8 +1620,9 @@ static int multipath_busy(struct dm_target *ti)
>
> spin_lock_irqsave(>lock, flags);
>
> - /* pg_init in progress, requeue until done */
> - if (!pg_ready(m)) {
> + /* pg_init in progress or no paths available */
> + if (m->pg_init_in_progress ||
> + (!m->nr_valid_paths && m->queue_if_no_path)) {
> busy = 1;
> goto out;
> }
This patch fixes IPR SCSI for my POWER8 box, e8099177 was the problem.
--
Alexey
--
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 01/12] sched: fix imbalance flag reset
Hi Vincent,
On 07/08/2014 03:42 PM, Vincent Guittot wrote:
> On 8 July 2014 05:13, Preeti U Murthy wrote:
>> On 06/30/2014 09:35 PM, Vincent Guittot wrote:
>>> The imbalance flag can stay set whereas there is no imbalance.
>>>
>>> Let assume that we have 3 tasks that run on a dual cores /dual cluster
>>> system.
>>> We will have some idle load balance which are triggered during tick.
>>> Unfortunately, the tick is also used to queue background work so we can
>>> reach
>>> the situation where short work has been queued on a CPU which already runs a
>>> task. The load balance will detect this imbalance (2 tasks on 1 CPU and an
>>> idle
>>> CPU) and will try to pull the waiting task on the idle CPU. The waiting
>>> task is
>>> a worker thread that is pinned on a CPU so an imbalance due to pinned task
>>> is
>>> detected and the imbalance flag is set.
>>> Then, we will not be able to clear the flag because we have at most 1 task
>>> on
>>> each CPU but the imbalance flag will trig to useless active load balance
>>> between the idle CPU and the busy CPU.
>>>
>>> We need to reset of the imbalance flag as soon as we have reached a balanced
>>> state.
>>>
>>> Signed-off-by: Vincent Guittot
>>> ---
>>> kernel/sched/fair.c | 14 +++---
>>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index d3c73122..0c48dff 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -6615,10 +6615,8 @@ more_balance:
>>> if (sd_parent) {
>>> int *group_imbalance =
>>> _parent->groups->sgc->imbalance;
>>>
>>> - if ((env.flags & LBF_SOME_PINNED) && env.imbalance >
>>> 0) {
>>> + if ((env.flags & LBF_SOME_PINNED) && env.imbalance >
>>> 0)
>>> *group_imbalance = 1;
>>> - } else if (*group_imbalance)
>>> - *group_imbalance = 0;
>>> }
>>>
>>> /* All tasks on this runqueue were pinned by CPU affinity */
>>> @@ -6703,6 +6701,16 @@ more_balance:
>>> goto out;
>>>
>>> out_balanced:
>>> + /*
>>> + * We reach balance although we may have faced some affinity
>>> + * constraints. Clear the imbalance flag if it was set.
>>> + */
>>> + if (sd_parent) {
>>> + int *group_imbalance = _parent->groups->sgc->imbalance;
>>> + if (*group_imbalance)
>>> + *group_imbalance = 0;
>>> + }
>>> +
>>> schedstat_inc(sd, lb_balanced[idle]);
>>>
>>> sd->nr_balance_failed = 0;
>>>
>> I am not convinced that we can clear the imbalance flag here. Lets take
>> a simple example. Assume at a particular level of sched_domain, there
>> are two sched_groups with one cpu each. There are 2 tasks on the source
>> cpu, one of which is running(t1) and the other thread(t2) does not have
>> the dst_cpu in the tsk_allowed_mask. Now no task can be migrated to the
>> dst_cpu due to affinity constraints. Note that t2 is *not pinned, it
>> just cannot run on the dst_cpu*. In this scenario also we reach the
>> out_balanced tag right? If we set the group_imbalance flag to 0, we are
>
> No we will not. If we have 2 tasks on 1 CPU in one sched_group and the
> other group with an idle CPU, we are not balanced so we will not go
> to out_balanced and the group_imbalance will staty set until we reach
> a balanced state (by migrating t1).
In the example that I mention above, t1 and t2 are on the rq of cpu0;
while t1 is running on cpu0, t2 is on the rq but does not have cpu1 in
its cpus allowed mask. So during load balance, cpu1 tries to pull t2,
cannot do so, and hence LBF_ALL_PINNED flag is set and it jumps to
out_balanced. Note that there are only two sched groups at this level of
sched domain.one with cpu0 and the other with cpu1. In this scenario we
do not try to do active load balancing, atleast thats what the code does
now if LBF_ALL_PINNED flag is set.
>
>> ruling out the possibility of migrating t2 to any other cpu in a higher
>> level sched_domain by saying that all is well, there is no imbalance.
>> This is wrong, isn't it?
>>
>> My point is that by clearing the imbalance flag in the out_balanced
>> case, you might be overlooking the fact that the tsk_cpus_allowed mask
>> of the tasks on the src_cpu may not be able to run on the dst_cpu in
>> *this* level of sched_domain, but can potentially run on a cpu at any
>> higher level of sched_domain. By clearing the flag, we are not
>
> The imbalance flag is per sched_domain level so we will not clear
> group_imbalance flag of other levels if the imbalance is also detected
> at a higher level it will migrate t2
Continuing with the above explanation; when LBF_ALL_PINNED flag is
set,and we jump to out_balanced, we clear the imbalance flag for the
sched_group comprising of cpu0 and cpu1,although there is actually an
imbalance. t2 could still be migrated to say
Re: linux-next: build failure after merge of the net-next tree
Hi David, On Tue, 08 Jul 2014 20:47:51 -0700 (PDT) David Miller wrote: > > From: Stephen Rothwell > Date: Wed, 9 Jul 2014 13:26:19 +1000 > > > After merging the net-next tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > This got fixed 5 minutes ago. Thanks, I guess that will be picked up tomorrow. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH V8 1/6] power: reset: Add generic SYSCON register mapped reset
On 07/08/2014 07:15 PM, Feng Kan wrote: Add a generic SYSCON register mapped reset mechanism. Signed-off-by: Feng Kan --- drivers/power/reset/Kconfig | 6 +++ drivers/power/reset/Makefile| 1 + drivers/power/reset/syscon-reboot.c | 91 + 3 files changed, 98 insertions(+) create mode 100644 drivers/power/reset/syscon-reboot.c diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig index bdcf517..5877b38 100644 --- a/drivers/power/reset/Kconfig +++ b/drivers/power/reset/Kconfig @@ -80,3 +80,9 @@ config POWER_RESET_KEYSTONE help Reboot support for the KEYSTONE SoCs. +config POWER_RESET_SYSCON + bool "Generic SYSCON regmap reset driver" + depends on ARM || ARM64 || COMPILE_TEST As written, this driver is really not generic but very arm specific. I don't think COMPILE_TEST is a good idea either, since arm_pm_restart is only defined for the arm architecture. Did you try compiling allmodconfig or allyesconfig for, say, x86_64 with this patch applied ? I think this might benefit from using [1], which would make it really generic. Guenter [1] http://www.spinics.net/lists/kernel/msg1780939.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: [PATCH net-next v2] netpoll: fix use after free
From: David Decotigny Date: Tue, 8 Jul 2014 15:14:41 -0700 > After a bonding master reclaims the netpoll info struct, slaves could > still hold a pointer to the reclaimed data. This patch fixes it: as > soon as netpoll_async_cleanup is called for a slave (eg. when > un-enslaved), we make sure that this slave doesn't point to the data. > > Signed-off-by: David Decotigny Applied, thank you. -- 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] pinctrl: msm: Add msm8960 definitions
On Tue, Jun 24, 2014 at 5:17 PM, Andreas Färber wrote:
> Am 24.06.2014 20:16, schrieb Bjorn Andersson:
>> diff --git
>> a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
>> b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
>> new file mode 100644
>> index 000..6e79eea
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt
> [...]
>> +Example:
>> +
>> + msmgpio: pinctrl@80 {
>> + compatible = "qcom,msm8960-pinctrl";
>> + reg = <0x80 0x4000>;
>> +
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> +interrupts = <0 32 0x4>;
>
> This line seems space-indented while surrounding ones are tab-indented.
>
Thanks, not only is it incorrectly indented, it's also a bad example
as it's the wrong IRQ for msm8960...
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_uart>;
>> +
>> + debug_uart: debug_uart {
>
> While at it, might debug-uart be a better node name? That seems the
> predominant convention and distinguishes from the label.
>
You're right and reference design does not use gsbi8 as uart, so I'll update it.
Thanks for the review.
Regards,
Bjorn
--
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 v4] xen-netback: Adding debugfs "io_ring_qX" files
From: Zoltan Kiss Date: Tue, 8 Jul 2014 19:49:14 +0100 > This patch adds debugfs capabilities to netback. There used to be a similar > patch floating around for classic kernel, but it used procfs. It is based on a > very similar blkback patch. > It creates xen-netback/[vifname]/io_ring_q[queueno] files, reading them output > various ring variables etc. Writing "kick" into it imitates an interrupt > happened, it can be useful to check whether the ring is just stalled due to a > missed interrupt. > > Signed-off-by: Zoltan Kiss Applied, but like others I consider those ifdefs hella ugly. Provide stubs in an #else block, then you don't have to crap up the main code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell Date: Wed, 9 Jul 2014 13:26:19 +1000 > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: This got fixed 5 minutes ago. -- 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 6/7] regulator: tps65218: Add get_voltage ops for dcdc5 and dcdc6
On Tuesday 08 July 2014 07:41 PM, Mark Brown wrote:
On Tue, Jul 08, 2014 at 03:46:36PM +0530, Keerthy wrote:
+static int tps65218_pmic_dcdc56_get_voltage(struct regulator_dev *dev)
+{
+ struct tps65218 *tps = rdev_get_drvdata(dev);
+ unsigned int rid = rdev_get_id(dev);
+
+ return tps->info[rid]->min_uV;
+}
Set fixed_uV in the descriptor.
Okay. I will do that. Thanks for the review.
Regards,
Keerthy
--
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 V2] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()
From: ethan zhao Date: Wed, 09 Jul 2014 10:41:23 +0800 >Please help to review and confirm this patch. It's not in patchwork, therefore it's not in my queue. It is also not my responsibility to review all patches, that's a joint responsibility of everyone on this mailing list. So asking me specifically to review a patch is really not generally inappropriate. 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/2] phy: Kconfig: Re-organize Exynos USB 2.0 PHY configs
Hi Tomasz, On Tue, Jul 8, 2014 at 9:15 PM, Tomasz Figa wrote: > On 30.06.2014 10:56, Sachin Kamat wrote: >> Since the USB 2.0 PHYs are required only with EHCI/OHCI USB drivers, > > That's not true. They are also required for USB gadget controller > supported by the DWC2 gadget driver (formerly s3c-hsotg). Otherwise the > change makes sense to me. Do you propose I amend just the patch description or also add a dependency on USB_DWC2 along with EHCI and OHCI. I do not have anything to test this. Based on your input I will re-spin the patch. -- Regards, Sachin. -- 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/3] PCI: designware: use untranslated address while programming ATU
Hello Kishon,
> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Tuesday, July 08, 2014 6:01 PM
> To: devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> p...@vger.kernel.org; jg1@samsung.com; bhelg...@google.com; Mohit
> KUMAR DCG; linux-kernel@vger.kernel.org
> Cc: grant.lik...@linaro.org; Jason Gunthorpe; Marek Vasut; Arnd Bergmann
> Subject: Re: [PATCH 2/3] PCI: designware: use untranslated address while
> programming ATU
>
> Hi Mohit, Jingoo,
>
> On Wednesday 25 June 2014 11:26 PM, Kishon Vijay Abraham I wrote:
> > In DRA7, the cpu sees 32bit address, but the pcie controller can see
> > only 28bit address. So whenever the cpu issues a read/write request,
> > the 4 most significant bits are used by L3 to determine the target
> > controller.
> > For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe
> > controller but the PCIe controller will see only (0x000_ -
> > 0xFFF_FFF). So for programming the outbound translation window the
> *base* should be programmed as 0x000_.
> > Whenever we try to write to say 0x2000_, it will be translated to
> > whatever we have programmed in the translation window with base as
> 0x000_.
> >
> > This is needed when the dt node is modelled something like below axi {
> > compatible = "simple-bus";
> > #size-cells = <1>;
> > #address-cells = <1>;
> > ranges = <0x00x2000 0x1000 // 28-bit bus
> > 0x5100 0x5100 0x3000>;
> > pcie@5100 {
> > reg = <0x1000 0x2000>, <0x51002000 0x14c>, <0x5100
> 0x2000>;
> > reg-names = "config", "ti_conf", "rc_dbics";
> > #address-cells = <3>;
> > #size-cells = <2>;
> > ranges = <0x8100 0 0 0x03000 0 0x0001
> > 0x8200 0 0x20013000 0x13000 0 0xffed000>;
> > };
> > };
> >
> > Here the CPU address for configuration space is 0x20013000 and the
> > controller address for configuration space is 0x13000. The controller
> > address should be used while programming the ATU (in order for
> > translation to happen properly in DRA7xx).
>
> Are you okay with this patch? Can you give your Reviewed-by/Acked-by?
>
- looks fine to me.
Reviewed-by: Mohit Kumar
Thanks
Mohit
> Cheers
> Kishon
> >
> > Cc: Jason Gunthorpe
> > Cc: Bjorn Helgaas
> > Cc: Mohit Kumar
> > Cc: Jingoo Han
> > Cc: Marek Vasut
> > Cc: Arnd Bergmann
> > Signed-off-by: Kishon Vijay Abraham I
> > ---
> > drivers/pci/host/pcie-designware.c | 49
>
> > drivers/pci/host/pcie-designware.h |4 +++
> > 2 files changed, 42 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-designware.c
> > b/drivers/pci/host/pcie-designware.c
> > index 0b7b455..11aba6d 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -401,8 +401,15 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> > struct of_pci_range range;
> > struct of_pci_range_parser parser;
> > struct resource *cfg_res;
> > - u32 val;
> > - int i;
> > + u32 val, na, ns;
> > + const __be32 *addrp;
> > + int i, index;
> > +
> > + /* Find the address cell size and the number of cells in order to get
> > +* the untranslated address.
> > +*/
> > + of_property_read_u32(np, "#address-cells", );
> > + ns = of_n_size_cells(np);
> >
> > cfg_res = platform_get_resource_byname(pdev,
> IORESOURCE_MEM, "config");
> > if (cfg_res) {
> > @@ -410,6 +417,12 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> > pp->config.cfg1_size = resource_size(cfg_res)/2;
> > pp->cfg0_base = cfg_res->start;
> > pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
> > +
> > + /* Find the untranslated configuration space address */
> > + index = of_property_match_string(np, "reg-names",
> "config");
> > + addrp = of_get_address(np, index, false, false);
> > + pp->cfg0_mod_addr = of_read_number(addrp, ns);
> > + pp->cfg1_mod_addr = pp->cfg0_mod_addr + pp-
> >config.cfg0_size;
> > } else {
> > dev_err(pp->dev, "missing *config* reg space\n");
> > }
> > @@ -435,12 +448,20 @@ int __init dw_pcie_host_init(struct pcie_port
> *pp)
> > pp->config.io_size = resource_size(>io);
> > pp->config.io_bus_addr = range.pci_addr;
> > pp->io_base = range.cpu_addr;
> > +
> > + /* Find the untranslated IO space address */
> > + pp->io_mod_addr = of_read_number(parser.range -
> > +parser.np + na, ns);
> > }
> > if (restype == IORESOURCE_MEM) {
> > of_pci_range_to_resource(, np, >mem);
> > pp->mem.name = "MEM";
> > pp->config.mem_size =
Re: [dm-devel] [PATCH] md/dm-ioctl.c: optimize memory allocation in copy_params
于 2014年07月09日 10:01, Zhang, Yanmin 写道:
> On 2014/7/9 6:39, Mikulas Patocka wrote:
>
>> Hi
>
> Mikulas,
>
> Thanks for your kind comments.
>
>> I don't really know what is the purpose of this patch. In existing device
>> mapper code, if kmalloc fails, the allocation is retried with __vmalloc.
>> So there is no need to avoid kmalloc aritifically.
>>
>> kmalloc doesn't cause memory fragmentation. If the memory is too
>> fragmented, kmalloc fails. If it isn't, it succeeds. But it doesn't cause
>> memory being fragmented.
>
> I agree with you. The patch's original description is not appropriate.
> Basically, memory fragmentation is not caused by this kmalloc.
>
> The right description is: When memory is fragmented and most memory is used
> up,
> kmalloc a big memory might cause lots of OutOFMemory and system might kill
> lots of processes. Then, system might hang.
>
> We are enabling Android on mobiles and tablets. We hit OOM often at
> Monkey and other stress testing. Sometimes, kernel prints big memory
> allocation
> warning.
>
> Theoretically, it's a good idea to call kmalloc firstly. If it fails, use
> vmalloc.
> However, kernel assumes drivers do the right thing. When drivers call kmalloc
> to
> allocate a big memory, memory management would do the best to fulfill it.
> When memory
> is fragmented and most memory is used up, such allocation would cause big
> memory
> recollection. Some processes might be killed. The worse scenario is after a
> process
> is killed, it is restarted and allocates memory again. That causes system
> hang,
> or mobile users feel a big stall. We did fix a similar issue in one of our
> drivers.
>
> Usually, kernel and drivers can allocate big continuous memory at booting or
> initialization stage. After that, they need allocate small order memory. The
> best
> is to just allocate order-0 memory.
>
>
>>
>> If you have some other driver that fails because of large kmalloc failure,
>> you should fix it to use scatter-gather DMA or (if the hardware can't do
>> it) preallocate the memory when the driver is loaded.
>
> I agree with you. Here the patch fixes the issue, where dm might allocate
> big continuous memory after booting. Monkey testing triggers it by operating
> menu Setting=>Security=>InstallfromSDcard.
>
hi, Yanmin && Mikulas
Thanks for your nice comments. And sorry for confusing you as my
comment is not clear enough.
In android, there is a command "dumpstate", it run many other commands to
collect information. In our scenario,
it run command "vdc dump", and vdc uses socket to pass some parameters to
"vold", then vold generates ioctl.
thanks.
> We are catching all places in kernel where big memory allocation happens.
> This patch is just to fix one case.
>
> Thanks,
> Yanmin
>
>>
>> Mikulas
>>
>>
>>
>> On Fri, 4 Jul 2014, xinhui.pan wrote:
>>
>>> KMALLOC_MAX_SIZE is too big, it easily cause memory fragmented and low
>>> memory when param_kernel->data_size
>>> is also big. That's not nice. So use vmalloc instead of kmalloc when size
>>> is larger than (PAGE_SIZE << 2).
>>> There are other drivers using kmalloc to gain a big size memory. And that
>>> cause our devices to hit hang and
>>> many worse issues. We don't benefit much when using kmalloc in such
>>> scenario.
>>>
>>> Signed-off-by: xinhui.pan
>>> Signed-off-by: yanmin.zhang
>>> ---
>>> drivers/md/dm-ioctl.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
>>> index 5152142..31c3af9 100644
>>> --- a/drivers/md/dm-ioctl.c
>>> +++ b/drivers/md/dm-ioctl.c
>>> @@ -1709,7 +1709,7 @@ static int copy_params(struct dm_ioctl __user *user,
>>> struct dm_ioctl *param_kern
>>> * Use kmalloc() rather than vmalloc() when we can.
>>> */
>>> dmi = NULL;
>>> - if (param_kernel->data_size <= KMALLOC_MAX_SIZE) {
>>> + if (param_kernel->data_size <= (PAGE_SIZE << 2)) {
>>> dmi = kmalloc(param_kernel->data_size, GFP_NOIO |
>>> __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN);
>>> if (dmi)
>>> *param_flags |= DM_PARAMS_KMALLOC;
>>> --
>>> 1.7.9.5
>>>
>>> --
>>> dm-devel mailing list
>>> dm-de...@redhat.com
>>> https://www.redhat.com/mailman/listinfo/dm-devel
>>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/7] kernel: Add support for restart notifier call chain
Various drivers implement architecture and/or device specific means
to restart (reset) the system. Various mechanisms have been implemented
to support those schemes. The best known mechanism is arm_pm_restart,
which is a function pointer to be set either from platform specific code
or from drivers. Another mechanism is to use hardware watchdogs to issue
a reset; this mechanism is used if there is no other method available
to reset a board or system. Two examples are alim7101_wdt, which currently
uses the reboot notifier to trigger a reset, and moxart_wdt, which registers
the arm_pm_restart function.
The existing mechanisms have a number of drawbacks. Typically only one scheme
to restart the system is supported (at least if arm_pm_restart is used).
At least in theory there can be mutliple means to restart the system, some of
which may be less desirable (for example one mechanism may only reset the CPU,
while another may reset the entire system). Using arm_pm_restart can also be
racy if the function pointer is set from a driver, as the driver may be in
the process of being unloaded when arm_pm_restart is called.
Using the reboot notifier is always racy, as it is unknown if and when
other functions using the reboot notifier have completed execution
by the time the watchdog fires.
To solve the problem, introduce a system restart notifier. This notifier
is expected to be called from the architecture specific machine_restart()
function. Drivers providing system restart functionality (such as the watchdog
drivers mentioned above) are expected to register with this notifier.
Signed-off-by: Guenter Roeck
---
v3: Add kernel_restart_notify wrapper function to execute notifier.
Improve documentation.
Move restart_notifier_list into kernel/reboot.c and make it static.
v2: No change.
include/linux/reboot.h | 3 +++
kernel/reboot.c| 71 ++
2 files changed, 74 insertions(+)
diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 48bf152..120db73 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -38,6 +38,9 @@ extern int reboot_force;
extern int register_reboot_notifier(struct notifier_block *);
extern int unregister_reboot_notifier(struct notifier_block *);
+extern int register_restart_notifier(struct notifier_block *);
+extern int unregister_restart_notifier(struct notifier_block *);
+extern void kernel_restart_notify(char *cmd);
/*
* Architecture-specific implementations of sys_reboot commands.
diff --git a/kernel/reboot.c b/kernel/reboot.c
index a3a9e24..7bd6575 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -104,6 +104,77 @@ int unregister_reboot_notifier(struct notifier_block *nb)
}
EXPORT_SYMBOL(unregister_reboot_notifier);
+/*
+ * Notifier list for kernel code which wants to be called
+ * to restart the system.
+ */
+static BLOCKING_NOTIFIER_HEAD(restart_notifier_list);
+
+/**
+ * register_restart_notifier - Register function to be called to reset
+ * the system
+ * @nb: Info about notifier function to be called
+ *
+ * Registers a function with the list of functions
+ * to be called to restart the system.
+ *
+ * Registered functions will be called from machine_restart as last
+ * step of the restart sequence (if the architecture specific
+ * machine_restart function calls kernel_restart_notify - see below
+ * for details).
+ * Registered functions are expected to restart the system immediately.
+ * If more than one function is registered, the notifier priority
+ * selects which function will be called first.
+ *
+ * Restart notifiers are expected to be registered from non-architecture
+ * code, typically from drivers. A typical use case would be a system
+ * where restart functionality is provided through a watchdog. Multiple
+ * restart handlers may exist; for example, one restart handler might
+ * restart the entire system, while another only restarts the CPU.
+ * In such cases, the restart handler which only restarts part of the
+ * hardware is expected to register with low priority to ensure that
+ * it only runs if no other means to restart the system is available.
+ *
+ * Currently always returns zero, as blocking_notifier_chain_register()
+ * always returns zero.
+ */
+int register_restart_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(_notifier_list, nb);
+}
+EXPORT_SYMBOL(register_restart_notifier);
+
+/**
+ * unregister_restart_notifier - Unregister previously registered
+ * restart notifier
+ * @nb: Hook to be unregistered
+ *
+ * Unregisters a previously registered restart notifier function.
+ *
+ * Returns zero on success, or %-ENOENT on failure.
+ */
+int unregister_restart_notifier(struct notifier_block *nb)
+{
+ return
[PATCH v3 4/7] power/restart: Call machine_restart instead of arm_pm_restart
machine_restart is supported on non-ARM platforms, and and ultimately calls
arm_pm_restart, so dont call arm_pm_restart directly but use the more
generic function.
Cc: Russell King
Signed-off-by: Guenter Roeck
---
v3: No change.
v2: Added patch.
drivers/power/reset/restart-poweroff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/power/reset/restart-poweroff.c
b/drivers/power/reset/restart-poweroff.c
index 5758033..47f10eb 100644
--- a/drivers/power/reset/restart-poweroff.c
+++ b/drivers/power/reset/restart-poweroff.c
@@ -20,7 +20,8 @@
static void restart_poweroff_do_poweroff(void)
{
- arm_pm_restart(REBOOT_HARD, NULL);
+ reboot_mode = REBOOT_HARD;
+ machine_restart(NULL);
}
static int restart_poweroff_probe(struct platform_device *pdev)
--
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 v3 5/7] watchdog: moxart: Register restart handler with restart notifier
The kernel now provides an API to trigger a system restart.
Register with it instead of setting arm_pm_restart.
Signed-off-by: Guenter Roeck
---
v3: Move struct notifier_block into struct moxart_wdt_dev.
Drop static variable previously needed to access struct moxart_wdt_dev
from notifier function; use container_of instead.
v2: No change.
drivers/watchdog/moxart_wdt.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
index 4aa3a8a..5aed8b98 100644
--- a/drivers/watchdog/moxart_wdt.c
+++ b/drivers/watchdog/moxart_wdt.c
@@ -15,12 +15,12 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
-#include
-
#define REG_COUNT 0x4
#define REG_MODE 0x8
#define REG_ENABLE 0xC
@@ -29,17 +29,22 @@ struct moxart_wdt_dev {
struct watchdog_device dev;
void __iomem *base;
unsigned int clock_frequency;
+ struct notifier_block restart_notifier;
};
-static struct moxart_wdt_dev *moxart_restart_ctx;
-
static int heartbeat;
-static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd)
+static int moxart_restart_notify(struct notifier_block *this,
+unsigned long mode, void *cmd)
{
- writel(1, moxart_restart_ctx->base + REG_COUNT);
- writel(0x5ab9, moxart_restart_ctx->base + REG_MODE);
- writel(0x03, moxart_restart_ctx->base + REG_ENABLE);
+ struct moxart_wdt_dev *moxart_wdt = container_of(this,
+struct moxart_wdt_dev,
+restart_notifier);
+ writel(1, moxart_wdt->base + REG_COUNT);
+ writel(0x5ab9, moxart_wdt->base + REG_MODE);
+ writel(0x03, moxart_wdt->base + REG_ENABLE);
+
+ return NOTIFY_DONE;
}
static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
@@ -136,8 +141,10 @@ static int moxart_wdt_probe(struct platform_device *pdev)
if (err)
return err;
- moxart_restart_ctx = moxart_wdt;
- arm_pm_restart = moxart_wdt_restart;
+ moxart_wdt->restart_notifier.notifier_call = moxart_restart_notify;
+ err = register_restart_notifier(_wdt->restart_notifier);
+ if (err)
+ dev_err(dev, "cannot register restart notifier (err=%d)\n",
err);
dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
moxart_wdt->dev.timeout, nowayout);
@@ -149,9 +156,8 @@ static int moxart_wdt_remove(struct platform_device *pdev)
{
struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
- arm_pm_restart = NULL;
+ unregister_restart_notifier(_wdt->restart_notifier);
moxart_wdt_stop(_wdt->dev);
- watchdog_unregister_device(_wdt->dev);
return 0;
}
--
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 v3 0/7] kernel: Add support for restart notifier call chain
Various drivers implement architecture and/or device specific means to restart (reset) the system. Various mechanisms have been implemented to support those schemes. The best known mechanism is arm_pm_restart, which is a function pointer to be set either from platform specific code or from drivers. Another mechanism is to use hardware watchdogs to issue a reset; this mechanism is used if there is no other method available to reset a board or system. Two examples are alim7101_wdt, which currently uses the reboot notifier to trigger a reset, and moxart_wdt, which registers the arm_pm_restart function. Several other restart drivers for arm, all directly calling arm_pm_restart, are in the process of being integrated into the kernel. All those drivers would benefit from the new API. The existing mechanisms have a number of drawbacks. Typically only one scheme to restart the system is supported (at least if arm_pm_restart is used). At least in theory there can be mutliple means to restart the system, some of which may be less desirable (for example one mechanism may only reset the CPU, while another may reset the entire system). Using arm_pm_restart can also be racy if the function pointer is set from a driver, as the driver may be in the process of being unloaded when arm_pm_restart is called. Using the reboot notifier is always racy, as it is unknown if and when other functions using the reboot notifier have completed execution by the time the watchdog fires. To solve the problem, introduce a system restart notifier. This notifier is expected to be called from the architecture specific machine_restart() function. Drivers providing system restart functionality (such as the watchdog drivers mentioned above) are expected to register with this notifier. Patch 1 of this series implements the notifier function. Patches 2 and 3 implement calling the notifier chain from arm and arm64 restart code. Patch 4 modifies the restart-poweroff driver to no longer call arm_pm_restart directly but machine_restart. This is done to avoid calling arm_pm_restart from more than one place. The change makes the driver architecture independent, so it would be possible to drop the arm dependency from its Kconfig entry. Patch 5 and 6 convert existing restart handlers in the watchdog subsystem to use the restart notifier. Patch 7 unexports arm_pm_restart to ensure that no one gets the idea to implement a restart handler as module. --- v3: Drop RFC. Add kernel_restart_notify wrapper function to execute notifier Improve documentation. Move restart_notifier_list into kernel/reboot.c and make it static. v2: Add patch 4. Only call blocking notifier call chain if arm_pm_restart was not set. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/7] watchdog: alim7101: Register restart handler with restart notifier
The kernel core now provides an API to trigger a system restart.
Register with it to restart the system instead of misusing the
reboot notifier.
Signed-off-by: Guenter Roeck
---
v3: No change
v2: No change
drivers/watchdog/alim7101_wdt.c | 41 +++--
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/alim7101_wdt.c b/drivers/watchdog/alim7101_wdt.c
index 996b2f7..239d6b2 100644
--- a/drivers/watchdog/alim7101_wdt.c
+++ b/drivers/watchdog/alim7101_wdt.c
@@ -301,6 +301,27 @@ static struct miscdevice wdt_miscdev = {
.fops = _fops,
};
+static int wdt_restart_notify(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+ /*
+* Cobalt devices have no way of rebooting themselves other
+* than getting the watchdog to pull reset, so we restart the
+* watchdog on reboot with no heartbeat.
+*/
+ wdt_change(WDT_ENABLE);
+
+ /* loop until the watchdog fires */
+ while (true)
+ ;
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block wdt_restart_notifier = {
+ .notifier_call = wdt_restart_notify,
+};
+
/*
* Notifier for system down
*/
@@ -311,15 +332,6 @@ static int wdt_notify_sys(struct notifier_block *this,
if (code == SYS_DOWN || code == SYS_HALT)
wdt_turnoff();
- if (code == SYS_RESTART) {
- /*
-* Cobalt devices have no way of rebooting themselves other
-* than getting the watchdog to pull reset, so we restart the
-* watchdog on reboot with no heartbeat
-*/
- wdt_change(WDT_ENABLE);
- pr_info("Watchdog timer is now enabled with no heartbeat -
should reboot in ~1 second\n");
- }
return NOTIFY_DONE;
}
@@ -338,6 +350,7 @@ static void __exit alim7101_wdt_unload(void)
/* Deregister */
misc_deregister(_miscdev);
unregister_reboot_notifier(_notifier);
+ unregister_restart_notifier(_restart_notifier);
pci_dev_put(alim7101_pmu);
}
@@ -390,11 +403,17 @@ static int __init alim7101_wdt_init(void)
goto err_out;
}
+ rc = register_restart_notifier(_restart_notifier);
+ if (rc) {
+ pr_err("cannot register reboot notifier (err=%d)\n", rc);
+ goto err_out_reboot;
+ }
+
rc = misc_register(_miscdev);
if (rc) {
pr_err("cannot register miscdev on minor=%d (err=%d)\n",
wdt_miscdev.minor, rc);
- goto err_out_reboot;
+ goto err_out_restart;
}
if (nowayout)
@@ -404,6 +423,8 @@ static int __init alim7101_wdt_init(void)
timeout, nowayout);
return 0;
+err_out_restart:
+ unregister_restart_notifier(_restart_notifier);
err_out_reboot:
unregister_reboot_notifier(_notifier);
err_out:
--
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 v3 7/7] arm/arm64: Unexport restart handlers
Implementing a restart handler in a module don't make sense as there would be no guarantee that the module is loaded when a restart is needed. Unexport arm_pm_restart to ensure that no one gets the idea to do it anyway. Signed-off-by: Guenter Roeck --- v3: No change v2: No change arch/arm/kernel/process.c | 1 - arch/arm64/kernel/process.c | 1 - 2 files changed, 2 deletions(-) diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c index 5d191e3..25c7f00 100644 --- a/arch/arm/kernel/process.c +++ b/arch/arm/kernel/process.c @@ -125,7 +125,6 @@ void (*pm_power_off)(void); EXPORT_SYMBOL(pm_power_off); void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd) = null_restart; -EXPORT_SYMBOL_GPL(arm_pm_restart); /* * This is our default idle handler. diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index b2da6d5..5b07396 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -92,7 +92,6 @@ void (*pm_power_off)(void); EXPORT_SYMBOL_GPL(pm_power_off); void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd); -EXPORT_SYMBOL_GPL(arm_pm_restart); /* * This is our default idle handler. -- 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 v3 3/7] arm: Support restart through restart notifier call chain
The kernel core now supports a notifier call chain for system restart functions. With this change, the arm_pm_restart callback is now optional, so check if it is set before calling it. Only call the notifier functions if arm_pm_restart is not set. Signed-off-by: Guenter Roeck --- v3: Use wrapper function to execute notifier call chain. v2: Only call notifier call chain if arm_pm_restart is not set. Do not include linux/watchdog.h. arch/arm/kernel/process.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c index 81ef686..5d191e3 100644 --- a/arch/arm/kernel/process.c +++ b/arch/arm/kernel/process.c @@ -230,7 +230,10 @@ void machine_restart(char *cmd) local_irq_disable(); smp_send_stop(); - arm_pm_restart(reboot_mode, cmd); + if (arm_pm_restart) + arm_pm_restart(reboot_mode, cmd); + else + kernel_restart_notify(cmd); /* Give a grace period for failure to restart of 1s */ mdelay(1000); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] sched: fix imbalance flag reset
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2014 11:05 PM, Rik van Riel wrote: > On 06/30/2014 12:05 PM, Vincent Guittot wrote: >> The imbalance flag can stay set whereas there is no imbalance. > >> Let assume that we have 3 tasks that run on a dual cores /dual >> cluster system. We will have some idle load balance which are >> triggered during tick. Unfortunately, the tick is also used to >> queue background work so we can reach the situation where short >> work has been queued on a CPU which already runs a task. The >> load balance will detect this imbalance (2 tasks on 1 CPU and an >> idle CPU) and will try to pull the waiting task on the idle CPU. >> The waiting task is a worker thread that is pinned on a CPU so >> an imbalance due to pinned task is detected and the imbalance >> flag is set. Then, we will not be able to clear the flag because >> we have at most 1 task on each CPU but the imbalance flag will >> trig to useless active load balance between the idle CPU and the >> busy CPU. > >> We need to reset of the imbalance flag as soon as we have reached >> a balanced state. > >> Signed-off-by: Vincent Guittot > > Acked-by: Rik van Riel Never mind that, Preeti explained the failure mode in more detail on irc, and I am no longer convinced this change is a good idea. - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvLi6AAoJEM553pKExN6DEAUH/A+dwZ4MYW1JafoKN3iaFzgr FqUzDayZ5NO2fSKNoa35CqvPhyZzAjeQn4H2yh0u/EhNI+1MzIqMY4i8l6dmB3QO woOj8pf6O5lB1+iWk9F2moEJRX2y3X8mhhysO3ujR8211Ic7t12Z195+SH7qD2OD xDjmRd/hTyNtn8mHOpcC2A69jaac8ZHKL6zNJcE9ax0IQxLTxZ+BzQnJhCtILEbD a2eYe/Dm039bvgZjIRmy0ht+GkTtUuA6Yn7/SxLbQMQ0eSolan0DC3M7TSB3SkDB z6lczf4lrMbyJdPhq1MX+C9YfbUAsICE2XQZYhpn/nopem0MTKBfQoLG4W3fWOg= =6eQR -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/
[PATCH v3 2/7] arm64: Support restart through restart notifier call chain
The kernel core now supports a notifier call chain to restart the system. Call it if arm_pm_restart is not set. Signed-off-by: Guenter Roeck --- v3: Use wrapper function to execute notifier call chain. v2: Only call notifier call chain if arm_pm_restart is not set. Do not include linux/watchdog.h. arch/arm64/kernel/process.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 43b7c34..b2da6d5 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -174,6 +174,8 @@ void machine_restart(char *cmd) /* Now call the architecture specific reboot code. */ if (arm_pm_restart) arm_pm_restart(reboot_mode, cmd); + else + kernel_restart_notify(cmd); /* * Whoops - the architecture was unable to reboot. -- 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/
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/tcp.h:23:0,
from include/linux/ipv6.h:63,
from include/net/ipv6.h:16,
from include/linux/sunrpc/clnt.h:27,
from include/linux/nfs_fs.h:30,
from init/do_mounts.c:32:
include/net/ipv6.h: In function 'ip6_set_txhash':
include/net/sock.h:327:33: error: 'struct sock_common' has no member named
'skc_v6_daddr'
#define sk_v6_daddr __sk_common.skc_v6_daddr
^
include/net/ipv6.h:695:49: note: in expansion of macro 'sk_v6_daddr'
keys.dst = (__force __be32)ipv6_addr_hash(>sk_v6_daddr);
^
In file included from include/linux/sunrpc/clnt.h:27:0,
from include/linux/nfs_fs.h:30,
from init/do_mounts.c:32:
include/net/ipv6.h: In function 'ip6_make_flowlabel':
include/net/ipv6.h:705:37: error: 'struct net' has no member named 'ipv6'
if (!flowlabel && (autolabel || net->ipv6.sysctl.auto_flowlabels)) {
^
And lots more ...
Caused by commits b73c3d0e4f0e ("net: Save TX flow hash in sock and set
in skbuf on xmit") and cb1ce2ef387b ("ipv6: Implement automatic flow
label generation on transmit"). This build has CONFIG_IPV6 unset.
I have used the net-next tree from next-20140708 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH 3.2 000/125] 3.2.61-rc1 review
On 07/08/2014 12:01 PM, Ben Hutchings wrote: This is the start of the stable review cycle for the 3.2.61 release. There are 125 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu Jul 10 19:01:49 UTC 2014. Anything received after that time might be too late. Looks better now, with the additional fix. Build results: total: 109 pass: 100 fail: 9 Failed builds: alpha:allmodconfig microblaze:mmu_defconfig microblaze:nommu_defconfig mips:allmodconfig score:defconfig sparc64:allmodconfig unicore32:defconfig xtensa:defconfig xtensa:allmodconfig Qemu tests all passed. Results are as expected. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 07/12] sched: test the cpu's capacity in wake affine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2014 12:05 PM, Vincent Guittot wrote: > Currently the task always wakes affine on this_cpu if the latter is > idle. Before waking up the task on this_cpu, we check that this_cpu > capacity is not significantly reduced because of RT tasks or irq > activity. > > Use case where the number of irq and/or the time spent under irq is > important will take benefit of this because the task that is woken > up by irq or softirq will not use the same CPU than irq (and > softirq) but a idle one which share its cache. > > Signed-off-by: Vincent Guittot Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvLMXAAoJEM553pKExN6DGwcIAIDInqWSTMPG1SpNPIgrDB4g YILWx6pFhv1ZSVEiJ05jxNpDKHeAKaEFR9NrSA/Psd+0p1zZ0pazioXyVhhr92PO 2C/xnIDsxNp7Qf+Yz1OvAHdoZiBM/uOI60JU+xL3bF/npjrw6DWe4WitikAookRR Yjwhtyj4KiVgXBYDWuES5HS5s61W+ol1F3as6KKMurfwU6JYXqJYMRZGQoymi144 5oV9enFgN3u6kXhXUMgC3vfzVW2xMr7SNDTvEDO0vqrvlIRsv07u63G0YppoMFbI Mht3ARLZKOwR6paiju1IkBdy/4nZeAuO461hDKwb/bB5q3JdeUtXw89xbelJD1Y= =H6O5 -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 03/12] sched: fix avg_load computation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2014 12:05 PM, Vincent Guittot wrote: > The computation of avg_load and avg_load_per_task should only takes > into account the number of cfs tasks. The non cfs task are already > taken into account by decreasing the cpu's capacity (cpu_power) and > they will be tracked in the CPU's utilization (group_utilization) > of the next patches > > Signed-off-by: Vincent Guittot Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvLKrAAoJEM553pKExN6Dcz4H/2lJUVmEEzBOxc23cbYSXJcR E1shwcwfbGe/0GwHwWOB4+9UyDuxp6pO6PaQ581nZZZ3sWSifjrViJqtoBheoERY yIH3zbnpPVBD3JNOVA/5XjHSdnYye/Qf23TVsaC/Jd2O8MH3oilJFJTbOoeU+ns7 DREwq0T4T7RnLo9oVc6eLyWf9Ouc3FufAH41u48y702Ppbw1qnOU/ZSRhTLWpgoR PjybIcEaNBugMHxv4CCjcU74VkYGoMupN93QZeuG71MwOjbkUQIIRwp4De9MW0Rw 59eO97StrE6o3oLcNaoqHPM3OzyvejF03soW6jROQJsTq3Ck7nD9jjGwav+TwO4= =TC6D -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 04/12] sched: Allow all archs to set the power_orig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2014 12:05 PM, Vincent Guittot wrote: > power_orig is only changed for system with a SMT sched_domain level > in order to reflect the lower capacity of CPUs. Heterogenous system > also have to reflect an original capacity that is different from > the default value. > > Create a more generic function arch_scale_cpu_power that can be > also used by non SMT platform to set power_orig. > > The weak behavior of arch_scale_cpu_power is the previous SMT one > in order to keep backward compatibility in the use of power_orig. > > Signed-off-by: Vincent Guittot Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvLLLAAoJEM553pKExN6D/bAH/3bwSpTQUfp37uMHo42JEwHV +GiMv+Q8dnVi6/b14UEYaRa0T7ELBOfbAvn7MjUDJVTGDOhCptXuE1Xedz+fKh01 FaVA5sJmCtyhH6v1n8q0PM5D/HcL6WRCBuf91Mx+3aSJhHcULRgN22wajYfxFOEy IBPQjwwxjbWOBsN4l8UevMnzOVLV3S9I/+NHHTRmIcPpc/gdREO31ey4LX4E1y4U sni6exOmhjYGiWgYwt9x5+Fmio0EwqVbSsdygWrSJykjW5dcUfM5A6ACp44u7keK L2tb/eiZthGGd+ct4J08nF51BLrXUAIBcyXM3wxWNFCIQkwhbnVxYapkfmSfe48= =ucGA -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 06/12] sched: add per rq cpu_power_orig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2014 12:05 PM, Vincent Guittot wrote: > This new field cpu_power_orig reflects the available capacity of a > CPUs unlike the cpu_power which reflects the current capacity that > can be altered by frequency and rt tasks. > > Signed-off-by: Vincent Guittot Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvLLxAAoJEM553pKExN6DKHsIALFlj278vKIifriFbVOOYgDf RppA21YTjzYP8YE00h0INatqPeIBRn5u1ifHUzlAtGIIV8dWy5q8QKu3D5zxNPfH hTxqyX/vMYcLTJOC9yXPS+mM/wcOx1JEpNnuRtF3UZgjG+70boPuGLvlecy+mxz9 mtW6StYOxX0/WgHgbWHMYaVDCKGdn5P2ey6azD2Hrvmp6XsVat8T9+ChdmRJ0/t+ 0D7QrEo56h+YSU3l0TqoHFwT/8l8pyGGyYOi1ABeZIaY13W2SJu2Ec4cYhK6qqmN uz69QWwTPa1gOPTqpj1f8g64/ckBjwKaA7hB9GLCqqk1cuI6PK22B5QJEg/9BpE= =wa9A -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 05/12] ARM: topology: use new cpu_power interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2014 12:05 PM, Vincent Guittot wrote: > Use the new arch_scale_cpu_power in order to reflect the original > capacity of a CPU instead of arch_scale_freq_power which is more > linked to a scaling of the capacity linked to the frequency. > > Signed-off-by: Vincent Guittot Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvLLgAAoJEM553pKExN6DZ40H/38CjOJQjRY4WZ+2UxlXSXfU V7gcMwHCNIJvJQ0fG3IfxVacdlJsK8LsQMgPL5sYCeJpLKYrQHPIQ2dIdkmz2W9I lcpr5dBq1AAB+PAbkywV2wtQBlDd0AMMQNrPqL6FdK92M4ML3iweJluA4qp0K1ip AtZM90ku4SQ52RyQR3ePIb396CeT1TRqihDnpWxbcZt53DkqWW3SCVE68qL1SIEO YKKlZyFXxLJDBZfM2kk90L8NPSmXzTa9xdsu+3CQKiyukqhgJoNe6J9E11CjlKBx BQggFRRTliIUat7IGlkgcyWLhXhhMLrfoXJN/sEdrWG2T2rApnI4u2Q4PM02/zU= =hHGQ -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: [RFC PATCH 2/2] ACPI/Wakup: Enable button wakeup GPEs if these GPEs have associated GPE methods.
On 2014年07月08日 21:26, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 02:57:58 PM Lan Tianyu wrote:
>> The button wakeup GPEs are enabled unconditionally in the current world by
>> commit 2a5d24(ACPI / Wakeup: Enable button GPEs unconditionally during
>> initialization). Because button's GPE methods needs to be run to clear
>> GPE status on some machines when there is GPE interrupt. If not, it will
>> cause machines resume immediately after being suspended since GPE status
>> isn't cleared correctly.
>>
>> But if there is no GPE method for button wakeup GPE, these GPEs should not
>> be enabled since nothing needs to be done when they are triggered and this
>> also causes LID GPE storm on Lenovo Ideapad y560p.
>>
>> This patch is to check Button GPE method and enable it if there is associated
>> GPE method.
>
> Part of the problem is that we call acpi_setup_gpe_for_wake() for buttons too
> and it sets ACPI_GPE_DISPATCH_NOTIFY unconditionally.
Yes, this is why the GPE wasn't disabled by CA. From my opinion,
original reason of enabling button wakeup GPE in the runtime is that it
may have associated GPE method and the method will notify button driver
and clear some hardware status. But if it didn't have GPE method, I
don't why we need to enable the GPE. I check some machines and they use
EC Query event to notify button driver.
> While we could address
> this the way you're proposing, it seems a bit less than straightforward so to
> speak.
>
> Let me think more about how to address that.
Ok. I get it.
>
>> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=61051
>> Reported-by: James Tocknell
>> Signed-off-by: Lan Tianyu
>> ---
>> drivers/acpi/wakeup.c | 11 ---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c
>> index 1638401..5b20ae4 100644
>> --- a/drivers/acpi/wakeup.c
>> +++ b/drivers/acpi/wakeup.c
>> @@ -86,9 +86,14 @@ int __init acpi_wakeup_device_init(void)
>> struct acpi_device,
>> wakeup_list);
>> if (device_can_wakeup(>dev)) {
>> -/* Button GPEs are supposed to be always enabled. */
>> -acpi_enable_gpe(dev->wakeup.gpe_device,
>> -dev->wakeup.gpe_number);
>> +/*
>> + * Button GPEs are supposed to be always enabled if
>> + * they have associated GPE methods.
>> + */
>> +if (ACPI_SUCCESS(acpi_check_gpe_method(
>> +dev->wakeup.gpe_device, dev->wakeup.gpe_number)))
>> +acpi_enable_gpe(dev->wakeup.gpe_device,
>> +dev->wakeup.gpe_number);
>> device_set_wakeup_enable(>dev, true);
>> }
>> }
>>
>
--
Best regards
Tianyu Lan
--
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: [f2fs-dev] f2fs: Add f2fs_balance_fs for direct IO
Hi Huang,
> -Original Message-
> From: Huang Ying [mailto:ying.hu...@intel.com]
> Sent: Tuesday, July 08, 2014 4:17 PM
> To: Jaegeuk Kim
> Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] f2fs: Add f2fs_balance_fs for direct IO
>
> Hi, Jaegeuk,
>
> On Tue, 2014-07-08 at 00:58 -0700, Jaegeuk Kim wrote:
> > Hi Huang,
> >
> > It occurs a merge conflict.
> > Please check the patch.
>
> Sorry, my fault. I think I need to base my patch on f2fs tree instead
> of latest Linus' tree?
I think you patch is not conflict to both latest linux's tree and f2fs dev tree.
but conflict to this patch
"f2fs: introduce f2fs_write_failed to handle error case when write" which
maybe in Jaegeuk's local tree, not update to f2fs dev tree.
If possible, you could wait for Jaegeuk to update f2fs tree, or merge this
patch,
then apply your new patch.
Thanks,
Yu
>
> > Anyway, IMO, it needs to place f2fs_balance_fs somewhere in get_data_block.
>
> Yes. I think so too. So you prefer to add f2fs_balance_fs in both
> f2fs_direct_IO and get_data_block, or just add f2fs_blance_fs in
> get_data_block only?
>
> Best Regards,
> Huang, Ying
>
> > Thanks,
> >
> > On Mon, Jul 07, 2014 at 01:46:28PM +0800, Huang Ying wrote:
> > > Otherwise, if a large amount of direct IO writes were done, the
> > > segment allocation may be failed because no enough segments are gced.
> > >
> > > Signed-off-by: Huang, Ying
> > > ---
> > > fs/f2fs/data.c |6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > --- a/fs/f2fs/data.c
> > > +++ b/fs/f2fs/data.c
> > > @@ -1038,6 +1038,7 @@ static ssize_t f2fs_direct_IO(int rw, st
> > > {
> > > struct file *file = iocb->ki_filp;
> > > struct inode *inode = file->f_mapping->host;
> > > + struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
> > >
> > > /* Let buffer I/O handle the inline data case. */
> > > if (f2fs_has_inline_data(inode))
> > > @@ -1046,8 +1047,11 @@ static ssize_t f2fs_direct_IO(int rw, st
> > > if (check_direct_IO(inode, rw, iter, offset))
> > > return 0;
> > >
> > > + if (rw == WRITE)
> > > + f2fs_balance_fs(sbi);
> > > +
> > > /* clear fsync mark to recover these blocks */
> > > - fsync_mark_clear(F2FS_SB(inode->i_sb), inode->i_ino);
> > > + fsync_mark_clear(sbi, inode->i_ino);
> > >
> > > return blockdev_direct_IO(rw, iocb, inode, iter, offset,
> > > get_data_block);
> >
>
>
>
> --
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/12] sched: remove a wake_affine condition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2014 12:05 PM, Vincent Guittot wrote: > I have tried to understand the meaning of the condition : > (this_load <= load && this_load + target_load(prev_cpu, idx) <= > tl_per_task) but i failed to find a use case that can take > advantage of it and i haven't found clear description in the > previous commits' log. Futhermore, the comment of the condition > refers to the task_hot function that was used before being replaced > by the current condition: /* * This domain has SD_WAKE_AFFINE and * > p is cache cold in this domain, and * there is no bad imbalance. > */ > > If we look more deeply the below condition this_load + > target_load(prev_cpu, idx) <= tl_per_task > > When sync is clear, we have : tl_per_task = runnable_load_avg / > nr_running this_load = max(runnable_load_avg, cpuload[idx]) > target_load = max(runnable_load_avg', cpuload'[idx]) > > It implies that runnable_load_avg' == 0 and nr_running <= 1 in > order to match the condition. This implies that runnable_load_avg > == 0 too because of the condition: this_load <= load but if this > _load is null, balanced is already set and the test is redundant. > > If sync is set, it's not as straight forward as above (especially > if cgroup are involved) but the policy should be similar as we have > removed a task that's going to sleep in order to get a more > accurate load and this_load values. > > The current conclusion is that these additional condition don't > give any benefit so we can remove them. > > Signed-off-by: Vincent Guittot Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvLG+AAoJEM553pKExN6DfhMH/iYJAS/nCq1teCNm39zZg1bF MIp2iWwnB5VTQvwVLQ3FaGU80oWScUez8zjn26LjPp5SnxyDEwG0YVM3/57EyJme PgffmP8xsVJwRkKnO4VRR0Go2EMXl9cdf9exe6lFjRyv4/Z15o9NZsDmX8JcLmG+ JPKq4DnMpJ3LiMiVuwwYtYSLk/tCHCPLnie4Z/WznlHk220WciVXFZG7AQI2AHXj pMkZ5TWQODW7PEec+8dGzDnFcdXPftRYWCKLXG+9NM92YQpIsK8nZdC8rJeXhjBC 9VNb8QNZ6yVd0lvOSxy0drOV9BFXUImF6lsLxA12oHE6TLm6FeiHTG9X4xGOhN0= =XlY9 -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 01/12] sched: fix imbalance flag reset
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2014 12:05 PM, Vincent Guittot wrote: > The imbalance flag can stay set whereas there is no imbalance. > > Let assume that we have 3 tasks that run on a dual cores /dual > cluster system. We will have some idle load balance which are > triggered during tick. Unfortunately, the tick is also used to > queue background work so we can reach the situation where short > work has been queued on a CPU which already runs a task. The load > balance will detect this imbalance (2 tasks on 1 CPU and an idle > CPU) and will try to pull the waiting task on the idle CPU. The > waiting task is a worker thread that is pinned on a CPU so an > imbalance due to pinned task is detected and the imbalance flag is > set. Then, we will not be able to clear the flag because we have at > most 1 task on each CPU but the imbalance flag will trig to useless > active load balance between the idle CPU and the busy CPU. > > We need to reset of the imbalance flag as soon as we have reached a > balanced state. > > Signed-off-by: Vincent Guittot Acked-by: Rik van Riel - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvLFvAAoJEM553pKExN6DUcYIAJkj0fl4DIpx/7ywqSSCo4Da 1IpJI5Hz2zb+NunG8M/4kugDSYvMmiuNhFgG1ET7me11jxTcTqg0e8UZ4zJbW55u i14IVyXLW+AVhJNQc1Umu3c6tTnjawOIzLa4wJ5JCVFVTj/5AhHyJjbKfQJnew1q XlYm8+FPGmXQgJ0G3itmpx3gAYsrQIQXtIhM9wwgmKiysF4s+HZZppyZKtGbOtm4 ia408LsmjOYYp4vGSTa4F4IWx1K0fJVpz33TsCLb2pwKy6t/4hKf9tOn/wXPSLVc NbWrP7zYYJ8EaXgo/RV9OJnPXq0h0Tbp9eMtd4u/hRCrcHw1dUZBpDMIRkS5NzI= =uoh0 -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/
[PATCHv2] ARM: dts: Add I2S dt node for Exynos3250
From: Tomasz Figa
This patch add I2S (Inter-IC Sound) dt node which supports 1-port stereo
(1 channels) IIS-bus for audio interface with DMA-based operation.
Signed-off-by: Tomasz Figa
Signed-off-by: Inha Song
Tested-by: Inha Song
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
Changes from v1:
- Fix wrong name of property (pinctrl-names)
- Change phanle name (i2s->i2s2)
arch/arm/boot/dts/exynos3250.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 3e678fa..77a06df 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -425,6 +425,19 @@
status = "disabled";
};
+ i2s2: i2s@1397 {
+ compatible = "samsung,s3c6410-i2s";
+ reg = <0x1397 0x100>;
+ interrupts = <0 126 0>;
+ clocks = < CLK_I2S>, < CLK_SCLK_I2S>;
+ clock-names = "iis", "i2s_opclk0";
+ dmas = < 14>, < 13>;
+ dma-names = "tx", "rx";
+ pinctrl-0 = <_bus>;
+ pinctrl-names = "default";
+ status = "disabled";
+ };
+
pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
--
1.8.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] thermal: samsung: Add TMU support for Exynos3250 SoC
On 07/01/2014 09:33 AM, Chanwoo Choi wrote:
> This patch add registers, bit fields and compatible strings for Exynos3250 TMU
> (Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
> a target speed of 1.0 GHz.
>
> Signed-off-by: Chanwoo Choi
> [Add MUX address setting bits by Jonghwa Lee]
> Signed-off-by: Jonghwa Lee
> Acked-by: Kyungmin Park
> ---
> .../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
> drivers/thermal/samsung/exynos_tmu.c | 7 +-
> drivers/thermal/samsung/exynos_tmu.h | 3 +-
> drivers/thermal/samsung/exynos_tmu_data.c | 89
> ++
> drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
> 5 files changed, 105 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index c949092..ae738f5 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -3,6 +3,7 @@
> ** Required properties:
>
> - compatible : One of the following:
> +"samsung,exynos3250-tmu"
> "samsung,exynos4412-tmu"
> "samsung,exynos4210-tmu"
> "samsung,exynos5250-tmu"
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 2412090..97ebc1e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -501,6 +501,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>
> static const struct of_device_id exynos_tmu_match[] = {
> {
> + .compatible = "samsung,exynos3250-tmu",
> + .data = (void *)EXYNOS3250_TMU_DRV_DATA,
> + },
> + {
> .compatible = "samsung,exynos4210-tmu",
> .data = (void *)EXYNOS4210_TMU_DRV_DATA,
> },
> @@ -675,7 +679,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
> goto err_clk_sec;
> }
>
> - if (pdata->type == SOC_ARCH_EXYNOS4210 ||
> + if (pdata->type == SOC_ARCH_EXYNOS3250 ||
> + pdata->type == SOC_ARCH_EXYNOS4210 ||
> pdata->type == SOC_ARCH_EXYNOS4412 ||
> pdata->type == SOC_ARCH_EXYNOS5250 ||
> pdata->type == SOC_ARCH_EXYNOS5260 ||
> diff --git a/drivers/thermal/samsung/exynos_tmu.h
> b/drivers/thermal/samsung/exynos_tmu.h
> index edd08cf..1b4a644 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -40,7 +40,8 @@ enum calibration_mode {
> };
>
> enum soc_type {
> - SOC_ARCH_EXYNOS4210 = 1,
> + SOC_ARCH_EXYNOS3250 = 1,
> + SOC_ARCH_EXYNOS4210,
> SOC_ARCH_EXYNOS4412,
> SOC_ARCH_EXYNOS5250,
> SOC_ARCH_EXYNOS5260,
> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
> b/drivers/thermal/samsung/exynos_tmu_data.c
> index c1d81dc..aa8e0de 100644
> --- a/drivers/thermal/samsung/exynos_tmu_data.c
> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
> @@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
> exynos4210_default_tmu_data = {
> };
> #endif
>
> +#if defined(CONFIG_SOC_EXYNOS3250)
> +static const struct exynos_tmu_registers exynos3250_tmu_registers = {
> + .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
> + .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
> + .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
> + .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
> + .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
> + .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
> + .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
> + .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
> + .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
> + .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
> + .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
> + .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
> + .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
> + .tmu_status = EXYNOS_TMU_REG_STATUS,
> + .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
> + .threshold_th0 = EXYNOS_THD_TEMP_RISE,
> + .threshold_th1 = EXYNOS_THD_TEMP_FALL,
> + .tmu_inten = EXYNOS_TMU_REG_INTEN,
> + .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
> + .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
> + .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
> + .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
> + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
> + .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
> + .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
> + .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
> + .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
> + .intclr_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
> + .emul_con = EXYNOS_EMUL_CON,
> + .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
> + .emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
> +
RE: [f2fs-dev] [PATCH] f2fs: do checkpoint for the renamed inode
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, July 08, 2014 2:37 PM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH] f2fs: do checkpoint for the renamed inode
>
> On Mon, Jul 07, 2014 at 11:17:35AM +0800, Chao Yu wrote:
> > Hi Jaegeuk,
> >
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > > Sent: Wednesday, July 02, 2014 6:35 PM
> > > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > > linux-f2fs-de...@lists.sourceforge.net
> > > Cc: Jaegeuk Kim
> > > Subject: [f2fs-dev] [PATCH] f2fs: do checkpoint for the renamed inode
> > >
> > > If an inode is renamed, it should be registered as file_lost_pino to
> > > conduct
> > > checkpoint at f2fs_sync_file.
> > > Otherwise, the inode cannot be recovered due to no dent_mark in the
> > > following
> > > scenario.
> > >
> > > Note that, this scenario is from xfstests/322.
> > >
> > > 1. create "a"
> > > 2. fsync "a"
> > > 3. rename "a" to "b"
> > > 4. fsync "b"
> > > 5. Sudden power-cut
> > >
> > > After recovery is done, "b" should be seen.
> > > However, the result shows "a", since the recovery procedure does not enter
> > > recover_dentry due to no dent_mark.
> >
> > As we know CP is expensive, how about modifying checkpointed value directly
> > in nat cache at step #3? So "b" could be fsynced with dent_mark at step #4.
>
> Yes, I also thought about that.
> But, when handling the nat cache, one of my concerns was the lock granularity.
> Basically each nat cache entry should be covered by its node page lock, so it
> is a little bit complicate to do something easily in f2fs_rename.
>
> So, this patch was to fix the bug with a naive approach.
> And we can write additional patch to enhance this too.
Thanks for your explanation! :)
Regards,
Yu
>
> Thanks,
>
> >
> > >
> > > The reason is like below.
> > > - The nid of "a" is checkpointed during #2, f2fs_sync_file.
> > > - The inode page for "b" produced by #3 is written without dent_mark by
> > > sync_node_pages.
> > >
> > > So, this patch fixes this bug by assinging file_lost_pino to the "a"'s
> > > inode.
> > > If the pino is lost, f2fs_sync_file conducts checkpoint, and then recovers
> > > the latest pino and its dentry information for further recovery.
> > >
> > > Signed-off-by: Jaegeuk Kim
> > > ---
> > > fs/f2fs/namei.c | 10 --
> > > 1 file changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> > > index 96f1dd1..1b3cae0 100644
> > > --- a/fs/f2fs/namei.c
> > > +++ b/fs/f2fs/namei.c
> > > @@ -411,9 +411,6 @@ static int f2fs_rename(struct inode *old_dir, struct
> > > dentry *old_dentry,
> > > }
> > >
> > > f2fs_set_link(new_dir, new_entry, new_page, old_inode);
> > > - down_write(_I(old_inode)->i_sem);
> > > - F2FS_I(old_inode)->i_pino = new_dir->i_ino;
> > > - up_write(_I(old_inode)->i_sem);
> > >
> > > new_inode->i_ctime = CURRENT_TIME;
> > > down_write(_I(new_inode)->i_sem);
> > > @@ -446,6 +443,10 @@ static int f2fs_rename(struct inode *old_dir, struct
> > > dentry *old_dentry,
> > > }
> > > }
> > >
> > > + down_write(_I(old_inode)->i_sem);
> > > + file_lost_pino(old_inode);
> > > + up_write(_I(old_inode)->i_sem);
> > > +
> > > old_inode->i_ctime = CURRENT_TIME;
> > > mark_inode_dirty(old_inode);
> > >
> > > @@ -455,9 +456,6 @@ static int f2fs_rename(struct inode *old_dir, struct
> > > dentry *old_dentry,
> > > if (old_dir != new_dir) {
> > > f2fs_set_link(old_inode, old_dir_entry,
> > > old_dir_page, new_dir);
> > > - down_write(_I(old_inode)->i_sem);
> > > - F2FS_I(old_inode)->i_pino = new_dir->i_ino;
> > > - up_write(_I(old_inode)->i_sem);
> > > update_inode_page(old_inode);
> > > } else {
> > > kunmap(old_dir_page);
> > > --
> > > 1.8.5.2 (Apple Git-48)
> > >
> > >
> > > --
> > > Open source business process management suite built on Java and Eclipse
> > > Turn processes into business applications with Bonita BPM Community
> > > Edition
> > > Quickly connect people, data, and systems into organized workflows
> > > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > > http://p.sf.net/sfu/Bonitasoft
> > > ___
> > > Linux-f2fs-devel mailing list
> > > linux-f2fs-de...@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
> --
> Jaegeuk Kim
--
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
Re: [PATCH net] r8169: disable L23
From: Hayes Wang Date: Tue, 8 Jul 2014 16:26:10 +0800 > For RTL8411, RTL8111G, RTL8402, RTL8105, and RTL8106, the nic couldn't > leave the power saving mode of L23 for certain situation. This causes > the device lost for the system. Disable the L23 mode to avoid it. > > Signed-off-by: Hayes Wang I agree with Francois, you need to provide a more detailed changelog for this patch. -- 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: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to prevent from deadloop
Hi,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, July 08, 2014 1:56 PM
> To: Chao Yu
> Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net;
> linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to
> prevent from deadloop
>
> On Mon, Jul 07, 2014 at 09:24:05AM +0800, Chao Yu wrote:
> > Hi Jaegeuk,
> >
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > > Sent: Saturday, July 05, 2014 2:43 PM
> > > To: Chao Yu
> > > Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net;
> > > linux-fsde...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to
> > > prevent from deadloop
> > >
> > > Hi Chao,
> > >
> > > On Wed, Jul 02, 2014 at 01:23:47PM +0800, Chao Yu wrote:
> > > > We assume that modification of some special application could result in
> > > > zeroed
> > > > name_len, or it is consciously made by somebody. We will deadloop in
> > > > find_in_block when name_len of dir entry is zero.
> > >
> > > Could you explain this a little bit more?
> > > I'm not sure how it can happen.
> >
> > IMO,
> > On one hand, programs like mkfs/fsck/img2simg and f2fs could directly
> > operate
> > the raw device, so bugs of these software may be triggered to generate the
> > corrupt data such as zeroed name_len.
>
> Well...
> If such the programs try to corrupt the f2fs image crucially, the bug should
> be
> fixed inside the programs, not from the workaround through f2fs.
IMO, software should have ability of self fault-tolerant, but not depend on
correctness
of other related software. And I will hope there are no more other software
which could
directly operate the raw device, to provide us such corrupted data as input.
How about swifting to BUG_ON here?
>
> As I mentioned, even though f2fs avoids such the dead loop whatever at that
> moment, it will be operating with inconsistent file system status, resulting
> in system crash in the near furture finally.
Agreed, we should avoid this. Previous solution with "break" is not suitable
here.
Thanks for you reminder.
>
> Why should we avoid this specific case only?
Hmm... I just found this case could cause some issue when I review Gu's last
patch.
As I check, several error cases of find_data_page in find_in_level could also
cause
inconsistent status of fs as you said.
> It seems that it is a kinda intentional user-made case.
> Is it really normal?
It's really rare.
>
> > On the other hand, it' could be treated as a potential security problem,
> > because
> > user could crafted such a malicious image include zeroed name_len for
> > hacking purpose.
>
> If user can try to do something like that, why do they write zeroed name_len
> only?
> To crash the system, they can do everything.
If they have the whole right to access the system, certainly they do not have
to do such
thing. I just assume that they only have the right to upload the crafted image,
then use
social engineering in next "do mount" step. Or it's no need to worry about this?
Thanks,
Yu
>
> Thanks,
>
> > Once such special image is being mounted, deadloop could be triggered,
> > finally will
> > result in effecting on linux system's running.
> >
> > Thanks,
> > Yu
> >
> > > I think the zeroed name_len would cause some problems in f2fs_add_link.
> > >
> > > Thanks,
> > >
> > > >
> > > > This patch is added for preventing deadloop in above scenario.
> > > >
> > > > Signed-off-by: Chao Yu
> > > > ---
> > > > fs/f2fs/dir.c | 10 ++
> > > > 1 file changed, 10 insertions(+)
> > > >
> > > > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > > > index be8c7af..4316ec5 100644
> > > > --- a/fs/f2fs/dir.c
> > > > +++ b/fs/f2fs/dir.c
> > > > @@ -121,6 +121,16 @@ static struct f2fs_dir_entry *find_in_block(struct
> > > > page *dentry_page,
> > > > }
> > > > }
> > > >
> > > > + /* check name_len to prevent from deadloop here */
> > > > + if (unlikely(de->name_len == 0)) {
> > > > + struct inode *inode =
> > > > dentry_page->mapping->host;
> > > > +
> > > > + f2fs_msg(inode->i_sb, KERN_ERR,
> > > > + "zero-length dir entry, ino = %lu, name
> > > > = %s",
> > > > + (unsigned long)inode->i_ino,
> > > > name->name);
> > > > + break;
> > > > + }
> > > > +
> > > > bit_start = bit_pos
> > > > +
> > > > GET_DENTRY_SLOTS(le16_to_cpu(de->name_len));
> > > > }
> > > > --
> > > > 1.7.9.5
> > >
> > > --
> > > Jaegeuk Kim
>
> --
> Jaegeuk Kim
--
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
Re: [PATCH net] r8152: wake up the device before dumping the hw counter
From: Hayes Wang Date: Tue, 8 Jul 2014 14:49:28 +0800 > The device should be waked up from runtime suspend before dumping > the hw counter. > > Signed-off-by: Hayes Wang Applied, 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] thermal: exynos: fix ordering in exynos_tmu_remove()
On Tue, Jul 8, 2014 at 6:39 PM, Bartlomiej Zolnierkiewicz
wrote:
> It might not be a problem currently but unregister/uninitialize things
> in the reverse order that they are registered/initialized.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> Acked-by: Kyungmin Park
Changes look fine,
Reviewed-by: Amit Daniel Kachhap
> ---
> drivers/thermal/samsung/exynos_tmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index d7ca9f4..6243ba0 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -759,10 +759,10 @@ static int exynos_tmu_remove(struct platform_device
> *pdev)
> {
> struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>
> - exynos_tmu_control(pdev, false);
> -
> exynos_unregister_thermal(data->reg_conf);
>
> + exynos_tmu_control(pdev, false);
> +
> clk_unprepare(data->clk);
> if (!IS_ERR(data->clk_sec))
> clk_unprepare(data->clk_sec);
> --
> 1.8.2.3
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.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: [PATCH NET-NEXT V2] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()
David,
Please help to review and confirm this patch.
Thanks,
Ethan
On 2014/7/8 21:57, Ethan Zhao wrote:
netxen driver has implemented netxen_nic_get_ethtool_stats() interface,
but it doesn't collect stats.rxdropped in driver, so we will get
different rx_dropped statistic information while using ifconfig and ethtool.
this patch fills stats.rxdropped field with data from net core
with dev_get_stats() just as ixgbe driver did for some of its stats.
V2: only fix the stats.rxdropped field.
Tested with last netxen 4.0.82
Compiled with net-next branch 3.16-rc2
Signed-off-by: Ethan Zhao
Tested-by: Sriharsha Yadagudde
---
.../ethernet/qlogic/netxen/netxen_nic_ethtool.c| 34 +---
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
index 4ca2c19..49e6a1b 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
@@ -33,22 +33,30 @@
#include "netxen_nic.h"
#include "netxen_nic_hw.h"
+enum {NETDEV_STATS, NETXEN_STATS};
+
struct netxen_nic_stats {
char stat_string[ETH_GSTRING_LEN];
+ int type;
int sizeof_stat;
int stat_offset;
};
-#define NETXEN_NIC_STAT(m) sizeof(((struct netxen_adapter *)0)->m), \
+#define NETXEN_NIC_STAT(m) NETXEN_STATS, \
+ sizeof(((struct netxen_adapter *)0)->m), \
offsetof(struct netxen_adapter, m)
+#define NETXEN_NETDEV_STAT(m) NETDEV_STATS, \
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
+
#define NETXEN_NIC_PORT_WINDOW 0x1
#define NETXEN_NIC_INVALID_DATA 0xDEADBEEF
static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
{"xmit_called", NETXEN_NIC_STAT(stats.xmitcalled)},
{"xmit_finished", NETXEN_NIC_STAT(stats.xmitfinished)},
- {"rx_dropped", NETXEN_NIC_STAT(stats.rxdropped)},
+ {"rx_dropped", NETXEN_NETDEV_STAT(rx_dropped)},
{"tx_dropped", NETXEN_NIC_STAT(stats.txdropped)},
{"csummed", NETXEN_NIC_STAT(stats.csummed)},
{"rx_pkts", NETXEN_NIC_STAT(stats.rx_pkts)},
@@ -679,11 +687,27 @@ netxen_nic_get_ethtool_stats(struct net_device *dev,
{
struct netxen_adapter *adapter = netdev_priv(dev);
int index;
+ struct rtnl_link_stats64 temp;
+ const struct rtnl_link_stats64 *net_stats;
+ char *p = NULL;
+ net_stats = dev_get_stats(dev, );
for (index = 0; index < NETXEN_NIC_STATS_LEN; index++) {
- char *p =
- (char *)adapter +
- netxen_nic_gstrings_stats[index].stat_offset;
+
+ switch (netxen_nic_gstrings_stats[index].type) {
+ case NETDEV_STATS:
+ p = (char *)net_stats +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ case NETXEN_STATS:
+ p = (char *)adapter +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ default:
+ data[index] = 0;
+ continue;
+ }
+
data[index] =
(netxen_nic_gstrings_stats[index].sizeof_stat ==
sizeof(u64)) ? *(u64 *) p : *(u32 *) p;
--
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] appletalk: Fix socket referencing in skb
From: Andrey Utkin Date: Mon, 7 Jul 2014 23:22:50 +0300 > Setting just skb->sk without taking its reference and setting a > destructor is invalid. However, in the places where this was done, skb > is used in a way not requiring skb->sk setting. So dropping the setting > of skb->sk. > Thanks to Eric Dumazet for correct solution. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79441 > Reported-by: Ed Martin > Signed-off-by: Andrey Utkin Applied and queued up for -stable. -- 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] ip_tunnel: fix ip_tunnel_lookup
From: Dmitry Popov Date: Wed, 9 Jul 2014 04:47:59 +0400 > How I see ip_tunnel_lookup logic: > 1) try to find exact match (and if found return this tunnel): > tunnel.saddr == iph.daddr && tunnel.daddr == iph.saddr && key_matched() > 2) try to find matched (local) wildcard tunnel: > tunnel.saddr == any && tunnel.daddr == iph.saddr && key_matched() > 3) try to find matched (remote) wildcard tunnel: > tunnel.saddr == iph.daddr && tunnel.daddr == any && key_matched() > (there is also a test for multicast tunnel, but let's skip it for simplicity) > 4) try to find matched (full) wildcard tunnel: > tunnel.saddr == any && tunnel.daddr == any && key_matched() > 5) if nothing found return default tunnel. > > According to this logic, in 4th loop (the one you quoted) we have to test that > tunnel.daddr == any && tunnel.saddr == any. In my opinion those two new lines > are the best way to achieve it. Now it makes sense, thanks for explaining. Applied and queued up for -stable, thanks again. -- 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/
TIckless Timers On Laptops and Battery Enabled Devices
I am been thinking , this is just a idea but can we enable the kernel to be tick less for laptops when they are on battery. I don't have any laptop on me to test but if someone can test the battery on a tick less kernel versus non tick less to see if it increases battery. It would be good if we can test when it's in standby , high cpu usage and average work to see if it's a good idea to enable a tick less kernel for default when a user is on battery for laptops and perhaps even get into the embedded boards that run on battery and/or cellphones if it's a great help in increasing battery. I will also be glad to help these features into the mainline kernel if they are of use to saving battery. Cheers 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/
[PATCH V8 3/6] Documentation: arm64: add SCU dts binding documentation to linux kernel
This add documentation for the SCU system clock unit device tree binding
to the kernel.
Signed-off-by: Feng Kan
---
Documentation/devicetree/bindings/arm/apm/scu.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt
diff --git a/Documentation/devicetree/bindings/arm/apm/scu.txt
b/Documentation/devicetree/bindings/arm/apm/scu.txt
new file mode 100644
index 000..b45be06
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/apm/scu.txt
@@ -0,0 +1,17 @@
+APM X-GENE SoC series SCU Registers
+
+This system clock unit contain various register that control block resets,
+clock enable/disables, clock divisors and other deepsleep registers.
+
+Properties:
+ - compatible : should contain two values. First value must be:
+ - "apm,xgene-scu"
+ second value must be always "syscon".
+
+ - reg : offset and length of the register set.
+
+Example :
+ scu: system-clk-controller@1700 {
+ compatible = "apm,xgene-scu","syscon";
+ reg = <0x0 0x1700 0x0 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 V8 0/6] Add X-Gene platform reboot mechanism
Enable reboot driver for the X-Gene platform. Add generic syscon reboot driver. V8 Change: - change Kconfig to depend on ARM || ARM64 || COMPILE_TEST V7 Change: - Seem V3 on, the patches were not making in to the mailinglist. - Fix build error produced by other ARCH while including this driver. Set to depend on arm64 ARCH for now. V6 Change: - Add documentation for scu node. V5 Change: - Documentation update, endian and access size. V4 Change: - Remove old X-Gene reboot driver - Add generic syscon reboot driver - Add DTS and Kconfig for X-Gene reboot using syscon method V3 Change: - Remove the reboot driver's use of acpi resource patch. - Change the reboot driver to use syscon to parse out system clock register. Remove the old method of getting register from the reboot driver directly. - Remove documentation since its now simple. V2 Change: - Add support for using ACPI resource. Feng Kan (6): power: reset: Add generic SYSCON register mapped reset Documentation: power: reset: Add documentation for generic SYSCON reboot driver Documentation: arm64: add SCU dts binding documentation to linux kernel arm64: dts: Add X-Gene reboot driver dts node arm64: Select reboot driver for X-Gene platform power: reset: Remove X-Gene reboot driver Documentation/devicetree/bindings/arm/apm/scu.txt | 17 .../bindings/power/reset/syscon-reboot.txt | 23 + arch/arm64/Kconfig | 2 + arch/arm64/boot/dts/apm-storm.dtsi | 12 +++ drivers/power/reset/Kconfig| 13 ++- drivers/power/reset/Makefile | 2 +- drivers/power/reset/syscon-reboot.c| 91 ++ drivers/power/reset/xgene-reboot.c | 103 - 8 files changed, 152 insertions(+), 111 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt create mode 100644 drivers/power/reset/syscon-reboot.c delete mode 100644 drivers/power/reset/xgene-reboot.c -- 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 V8 5/6] arm64: Select reboot driver for X-Gene platform
Select reboot driver for X-Gene platform. Signed-off-by: Feng Kan --- arch/arm64/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index a474de34..91a2e25 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -140,6 +140,8 @@ config ARCH_VEXPRESS config ARCH_XGENE bool "AppliedMicro X-Gene SOC Family" + select MFD_SYSCON + select POWER_RESET_SYSCON help This enables support for AppliedMicro X-Gene SOC Family -- 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 V8 2/6] Documentation: power: reset: Add documentation for generic SYSCON reboot driver
Add documentation for generic SYSCON reboot driver.
Signed-off-by: Feng Kan
---
.../bindings/power/reset/syscon-reboot.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
new file mode 100644
index 000..1190631
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
@@ -0,0 +1,23 @@
+Generic SYSCON mapped register reset driver
+
+This is a generic reset driver using syscon to map the reset register.
+The reset is generally performed with a write to the reset register
+defined by the register map pointed by syscon reference plus the offset
+with the mask defined in the reboot node.
+
+Required properties:
+- compatible: should contain "syscon-reboot"
+- regmap: this is phandle to the register map node
+- offset: offset in the register map for the reboot register (in bytes)
+- mask: the reset value written to the reboot register (32 bit access)
+
+Default will be little endian mode, 32 bit access only.
+
+Examples:
+
+ reboot {
+ compatible = "syscon-reboot";
+ regmap = <>;
+ offset = <0x0>;
+ mask = <0x1>;
+ };
--
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 V8 1/6] power: reset: Add generic SYSCON register mapped reset
Add a generic SYSCON register mapped reset mechanism.
Signed-off-by: Feng Kan
---
drivers/power/reset/Kconfig | 6 +++
drivers/power/reset/Makefile| 1 +
drivers/power/reset/syscon-reboot.c | 91 +
3 files changed, 98 insertions(+)
create mode 100644 drivers/power/reset/syscon-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index bdcf517..5877b38 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -80,3 +80,9 @@ config POWER_RESET_KEYSTONE
help
Reboot support for the KEYSTONE SoCs.
+config POWER_RESET_SYSCON
+ bool "Generic SYSCON regmap reset driver"
+ depends on ARM || ARM64 || COMPILE_TEST
+ depends on POWER_RESET && MFD_SYSCON && OF
+ help
+ Reboot support for generic SYSCON mapped register reset.
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index dde2e8b..b1b5ab3 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
+obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/syscon-reboot.c
b/drivers/power/reset/syscon-reboot.c
new file mode 100644
index 000..9c15ba5
--- /dev/null
+++ b/drivers/power/reset/syscon-reboot.c
@@ -0,0 +1,91 @@
+/*
+ * Generic Syscon Reboot Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Author: Feng Kan
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that 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.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct syscon_reboot_context {
+ struct regmap *map;
+ u32 offset;
+ u32 mask;
+};
+
+static struct syscon_reboot_context *syscon_reboot_ctx;
+
+static void syscon_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+ struct syscon_reboot_context *ctx = syscon_reboot_ctx;
+ unsigned long timeout;
+
+ /* Issue the reboot */
+ if (ctx->map)
+ regmap_write(ctx->map, ctx->offset, ctx->mask);
+
+ timeout = jiffies + HZ;
+ while (time_before(jiffies, timeout))
+ cpu_relax();
+
+ pr_emerg("Unable to restart system\n");
+}
+
+static int syscon_reboot_probe(struct platform_device *pdev)
+{
+ struct syscon_reboot_context *ctx;
+ struct device *dev = >dev;
+
+ ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx) {
+ dev_err(>dev, "out of memory for context\n");
+ return -ENOMEM;
+ }
+
+ ctx->map = syscon_regmap_lookup_by_phandle(dev->of_node, "regmap");
+ if (IS_ERR(ctx->map))
+ return PTR_ERR(ctx->map);
+
+ if (of_property_read_u32(pdev->dev.of_node, "offset", >offset))
+ return -EINVAL;
+
+ if (of_property_read_u32(pdev->dev.of_node, "mask", >mask))
+ return -EINVAL;
+
+ arm_pm_restart = syscon_restart;
+ syscon_reboot_ctx = ctx;
+
+ return 0;
+}
+
+static struct of_device_id syscon_reboot_of_match[] = {
+ { .compatible = "syscon-reboot" },
+ {}
+};
+
+static struct platform_driver syscon_reboot_driver = {
+ .probe = syscon_reboot_probe,
+ .driver = {
+ .name = "syscon-reboot",
+ .of_match_table = syscon_reboot_of_match,
+ },
+};
+module_platform_driver(syscon_reboot_driver);
--
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 V8 6/6] power: reset: Remove X-Gene reboot driver
Remove X-Gene reboot driver.
Signed-off-by: Feng Kan
---
drivers/power/reset/Kconfig| 7 ---
drivers/power/reset/Makefile | 1 -
drivers/power/reset/xgene-reboot.c | 103 -
3 files changed, 111 deletions(-)
delete mode 100644 drivers/power/reset/xgene-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 5877b38..f548f72 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -66,13 +66,6 @@ config POWER_RESET_VEXPRESS
Power off and reset support for the ARM Ltd. Versatile
Express boards.
-config POWER_RESET_XGENE
- bool "APM SoC X-Gene reset driver"
- depends on ARM64
- depends on POWER_RESET
- help
- Reboot support for the APM SoC X-Gene Eval boards.
-
config POWER_RESET_KEYSTONE
bool "Keystone reset driver"
depends on ARCH_KEYSTONE
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index b1b5ab3..62088d8 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -6,6 +6,5 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
-obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/xgene-reboot.c
b/drivers/power/reset/xgene-reboot.c
deleted file mode 100644
index ecd55f8..000
--- a/drivers/power/reset/xgene-reboot.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/*
- * AppliedMicro X-Gene SoC Reboot Driver
- *
- * Copyright (c) 2013, Applied Micro Circuits Corporation
- * Author: Feng Kan
- * Author: Loc Ho
- *
- * 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.
- *
- * This program is distributed in the hope that 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- *
- * This driver provides system reboot functionality for APM X-Gene SoC.
- * For system shutdown, this is board specify. If a board designer
- * implements GPIO shutdown, use the gpio-poweroff.c driver.
- */
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-struct xgene_reboot_context {
- struct platform_device *pdev;
- void *csr;
- u32 mask;
-};
-
-static struct xgene_reboot_context *xgene_restart_ctx;
-
-static void xgene_restart(char str, const char *cmd)
-{
- struct xgene_reboot_context *ctx = xgene_restart_ctx;
- unsigned long timeout;
-
- /* Issue the reboot */
- if (ctx)
- writel(ctx->mask, ctx->csr);
-
- timeout = jiffies + HZ;
- while (time_before(jiffies, timeout))
- cpu_relax();
-
- dev_emerg(>pdev->dev, "Unable to restart system\n");
-}
-
-static int xgene_reboot_probe(struct platform_device *pdev)
-{
- struct xgene_reboot_context *ctx;
-
- ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
- if (!ctx) {
- dev_err(>dev, "out of memory for context\n");
- return -ENODEV;
- }
-
- ctx->csr = of_iomap(pdev->dev.of_node, 0);
- if (!ctx->csr) {
- devm_kfree(>dev, ctx);
- dev_err(>dev, "can not map resource\n");
- return -ENODEV;
- }
-
- if (of_property_read_u32(pdev->dev.of_node, "mask", >mask))
- ctx->mask = 0x;
-
- ctx->pdev = pdev;
- arm_pm_restart = xgene_restart;
- xgene_restart_ctx = ctx;
-
- return 0;
-}
-
-static struct of_device_id xgene_reboot_of_match[] = {
- { .compatible = "apm,xgene-reboot" },
- {}
-};
-
-static struct platform_driver xgene_reboot_driver = {
- .probe = xgene_reboot_probe,
- .driver = {
- .name = "xgene-reboot",
- .of_match_table = xgene_reboot_of_match,
- },
-};
-
-static int __init xgene_reboot_init(void)
-{
- return platform_driver_register(_reboot_driver);
-}
-device_initcall(xgene_reboot_init);
--
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/
