[PATCH v9 07/14] clk: tegra: Add new fields and PLL types for Tegra114

[Peter De Schrijver]

Tegra114 introduces new PLL types. This requires new clocktypes as well
as some new fields in the pll structure.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-pll.c |  839 +++
 drivers/clk/tegra/clk.h |   50 +++-
 2 files changed, 888 insertions(+), 1 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 0b96352..17c2cc0 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -79,6 +79,48 @@
 #define PLLE_SS_CTRL 0x68
 #define PLLE_SS_DISABLE (7 << 10)
 
+#define PLLE_AUX_PLLP_SEL  BIT(2)
+#define PLLE_AUX_ENABLE_SWCTL  BIT(4)
+#define PLLE_AUX_SEQ_ENABLEBIT(24)
+#define PLLE_AUX_PLLRE_SEL BIT(28)
+
+#define PLLE_MISC_PLLE_PTS BIT(8)
+#define PLLE_MISC_IDDQ_SW_VALUEBIT(13)
+#define PLLE_MISC_IDDQ_SW_CTRL BIT(14)
+#define PLLE_MISC_VREG_BG_CTRL_SHIFT   4
+#define PLLE_MISC_VREG_BG_CTRL_MASK(3 << PLLE_MISC_VREG_BG_CTRL_SHIFT)
+#define PLLE_MISC_VREG_CTRL_SHIFT  2
+#define PLLE_MISC_VREG_CTRL_MASK   (2 << PLLE_MISC_VREG_CTRL_SHIFT)
+
+#define PLLCX_MISC_STROBE  BIT(31)
+#define PLLCX_MISC_RESET   BIT(30)
+#define PLLCX_MISC_SDM_DIV_SHIFT 28
+#define PLLCX_MISC_SDM_DIV_MASK (0x3 << PLLCX_MISC_SDM_DIV_SHIFT)
+#define PLLCX_MISC_FILT_DIV_SHIFT 26
+#define PLLCX_MISC_FILT_DIV_MASK (0x3 << PLLCX_MISC_FILT_DIV_SHIFT)
+#define PLLCX_MISC_ALPHA_SHIFT 18
+#define PLLCX_MISC_DIV_LOW_RANGE \
+   ((0x1 << PLLCX_MISC_SDM_DIV_SHIFT) | \
+   (0x1 << PLLCX_MISC_FILT_DIV_SHIFT))
+#define PLLCX_MISC_DIV_HIGH_RANGE \
+   ((0x2 << PLLCX_MISC_SDM_DIV_SHIFT) | \
+   (0x2 << PLLCX_MISC_FILT_DIV_SHIFT))
+#define PLLCX_MISC_COEF_LOW_RANGE \
+   ((0x14 << PLLCX_MISC_KA_SHIFT) | (0x38 << PLLCX_MISC_KB_SHIFT))
+#define PLLCX_MISC_KA_SHIFT 2
+#define PLLCX_MISC_KB_SHIFT 9
+#define PLLCX_MISC_DEFAULT (PLLCX_MISC_COEF_LOW_RANGE | \
+   (0x19 << PLLCX_MISC_ALPHA_SHIFT) | \
+   PLLCX_MISC_DIV_LOW_RANGE | \
+   PLLCX_MISC_RESET)
+#define PLLCX_MISC1_DEFAULT 0x000d2308
+#define PLLCX_MISC2_DEFAULT 0x30211200
+#define PLLCX_MISC3_DEFAULT 0x200
+
+#define PMC_PLLM_WB0_OVERRIDE  0x1dc
+#define PMC_PLLM_WB0_OVERRIDE_20x2b0
+#define PMC_PLLM_WB0_OVERRIDE_2_DIVP_MASK BIT(27)
+
 #define PMC_SATA_PWRGT 0x1ac
 #define PMC_SATA_PWRGT_PLLE_IDDQ_VALUE BIT(5)
 #define PMC_SATA_PWRGT_PLLE_IDDQ_SWCTL BIT(4)
@@ -101,6 +143,24 @@
 #define divn_max(p) (divn_mask(p))
 #define divp_max(p) (1 << (divp_mask(p)))
 
+
+#ifdef CONFIG_ARCH_TEGRA_114_SOC
+/* PLLXC has 4-bit PDIV, but entry 15 is not allowed in h/w */
+#define PLLXC_PDIV_MAX 14
+
+/* non-monotonic mapping below is not a typo */
+static u8 pllxc_p[PLLXC_PDIV_MAX + 1] = {
+   /* PDIV: 0, 1, 2, 3, 4, 5, 6,  7,  8,  9, 10, 11, 12, 13, 14 */
+   /* p: */ 1, 2, 3, 4, 5, 6, 8, 10, 12, 16, 12, 16, 20, 24, 32
+};
+
+#define PLLCX_PDIV_MAX 7
+static u8 pllcx_p[PLLCX_PDIV_MAX + 1] = {
+   /* PDIV: 0, 1, 2, 3, 4, 5,  6,  7 */
+   /* p: */ 1, 2, 3, 4, 6, 8, 12, 16
+};
+#endif
+
 static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
 {
u32 val;
@@ -646,6 +706,520 @@ const struct clk_ops tegra_clk_plle_ops = {
.enable = clk_plle_enable,
 };
 
+#ifdef CONFIG_ARCH_TEGRA_114_SOC
+
+static int _pll_fixed_mdiv(struct tegra_clk_pll_params *pll_params,
+  unsigned long parent_rate)
+{
+   if (parent_rate > pll_params->cf_max)
+   return 2;
+   else
+   return 1;
+}
+
+static int clk_pll_iddq_enable(struct clk_hw *hw)
+{
+   struct tegra_clk_pll *pll = to_clk_pll(hw);
+   unsigned long flags = 0;
+
+   u32 val;
+   int ret;
+
+   if (pll->lock)
+   spin_lock_irqsave(pll->lock, flags);
+
+   val = pll_readl(pll->params->iddq_reg, pll);
+   val &= ~BIT(pll->params->iddq_bit_idx);
+   pll_writel(val, pll->params->iddq_reg, pll);
+   udelay(2);
+
+   _clk_pll_enable(hw);
+
+   ret = clk_pll_wait_for_lock(pll);
+
+   if (pll->lock)
+   spin_unlock_irqrestore(pll->lock, flags);
+
+   return 0;
+}
+
+static void clk_pll_iddq_disable(struct clk_hw *hw)
+{
+   struct tegra_clk_pll *pll = to_clk_pll(hw);
+   unsigned long flags = 0;
+   u32 val;
+
+   if (pll->lock)
+   spin_lock_irqsave(pll->lock, flags);
+
+   _clk_pll_disable(hw);
+
+   val = pll_readl(pll->params->iddq_reg, pll);
+   val |= BIT(pll->params->iddq_bit_idx);
+   pll_writel(val, pll->params->iddq_reg, pll);
+   udelay(2);
+
+   if (pll->lock)
+   spin_unlock_irqrestore(pll->lock, flags);
+}
+
+static int _calc_dynamic_ramp_rate(struct clk_hw *hw,
+   struct tegra_clk_pll_freq_table *cfg,
+   unsigned long rate, unsigned long parent_rate)
+{
+   struct tegra_clk_pll 

Re: [PATCH] x86: fix rebuild with EFI_STUB enabled

[H. Peter Anvin]

This looks awesome for 3.10, but getting a minimal fix for 3.9/stable would be 
good, too.

Jan Beulich  wrote:

>eboot.o and efi_stub_$(BITS).o didn't get added to "targets", and hence
>their .cmd files don't get included by the build machinery, leading to
>the files always getting rebuilt.
>
>Rather than adding the two files individually, take the opportunity and
>add $(VMLINUX_OBJS) to "targets" instead, thus allowing the assignment
>at the top of the file to be shrunk quite a bit.
>
>At the same time, remove a pointless flags override line - the variable
>assigned to was misspelled anyway, and the options added are
>meaningless for assembly sources.
>
>Signed-off-by: Jan Beulich 
>Cc: Matthew Garrett 
>Cc: Matt Fleming 
>---
> arch/x86/boot/compressed/Makefile |5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
>--- 3.9-rc5/arch/x86/boot/compressed/Makefile
>+++ 3.9-rc5-x86-EFI-stub-rebuild/arch/x86/boot/compressed/Makefile
>@@ -4,7 +4,7 @@
> # create a compressed vmlinux image from the original vmlinux
> #
> 
>-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz
>vmlinux.bin.bz2 vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo
>head_$(BITS).o misc.o string.o cmdline.o early_serial_console.o piggy.o
>+targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2
>vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo
> 
> KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2
> KBUILD_CFLAGS += -fno-strict-aliasing -fPIC
>@@ -29,7 +29,6 @@ VMLINUX_OBJS = $(obj)/vmlinux.lds $(obj)
>   $(obj)/piggy.o
> 
> $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
>-$(obj)/efi_stub_$(BITS).o: KBUILD_CLFAGS += -fshort-wchar
>-mno-red-zone
> 
> ifeq ($(CONFIG_EFI_STUB), y)
>   VMLINUX_OBJS += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o
>@@ -43,7 +42,7 @@ OBJCOPYFLAGS_vmlinux.bin :=  -R .comment
> $(obj)/vmlinux.bin: vmlinux FORCE
>   $(call if_changed,objcopy)
> 
>-targets += vmlinux.bin.all vmlinux.relocs
>+targets += $(patsubst $(obj)/%,%,$(VMLINUX_OBJS)) vmlinux.bin.all
>vmlinux.relocs
> 
> CMD_RELOCS = arch/x86/tools/relocs
> quiet_cmd_relocs = RELOCS  $@

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 05/12] ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC

[Thierry Reding]

The PMC code already accesses to PMC registers so it makes sense to
move this function there as well. While at it, rename the function to
tegra_pmc_pcie_xclk_clamp() for consistency.

Signed-off-by: Thierry Reding 
Acked-by: Stephen Warren 
---
 arch/arm/mach-tegra/pcie.c | 30 --
 arch/arm/mach-tegra/pmc.c  | 16 
 arch/arm/mach-tegra/pmc.h  |  1 +
 3 files changed, 21 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
index 46144a1..6c1989b 100644
--- a/arch/arm/mach-tegra/pcie.c
+++ b/arch/arm/mach-tegra/pcie.c
@@ -41,6 +41,7 @@
 
 #include "board.h"
 #include "iomap.h"
+#include "pmc.h"
 
 /* Hack - need to parse this from DT */
 #define INT_PCIE_INTR 130
@@ -147,17 +148,6 @@
 #define  PADS_PLL_CTL_TXCLKREF_DIV10   (0 << 20)
 #define  PADS_PLL_CTL_TXCLKREF_DIV5(1 << 20)
 
-/* PMC access is required for PCIE xclk (un)clamping */
-#define PMC_SCRATCH42  0x144
-#define PMC_SCRATCH42_PCX_CLAMP(1 << 0)
-
-static void __iomem *reg_pmc_base = IO_ADDRESS(TEGRA_PMC_BASE);
-
-#define pmc_writel(value, reg) \
-   __raw_writel(value, reg_pmc_base + (reg))
-#define pmc_readl(reg) \
-   __raw_readl(reg_pmc_base + (reg))
-
 /*
  * Tegra2 defines 1GB in the AXI address map for PCIe.
  *
@@ -639,18 +629,6 @@ static int tegra_pcie_enable_controller(void)
return 0;
 }
 
-static void tegra_pcie_xclk_clamp(bool clamp)
-{
-   u32 reg;
-
-   reg = pmc_readl(PMC_SCRATCH42) & ~PMC_SCRATCH42_PCX_CLAMP;
-
-   if (clamp)
-   reg |= PMC_SCRATCH42_PCX_CLAMP;
-
-   pmc_writel(reg, PMC_SCRATCH42);
-}
-
 static void tegra_pcie_power_off(void)
 {
tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
@@ -658,7 +636,7 @@ static void tegra_pcie_power_off(void)
tegra_periph_reset_assert(tegra_pcie.pex_clk);
 
tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
-   tegra_pcie_xclk_clamp(true);
+   tegra_pmc_pcie_xclk_clamp(true);
 }
 
 static int tegra_pcie_power_regate(void)
@@ -667,7 +645,7 @@ static int tegra_pcie_power_regate(void)
 
tegra_pcie_power_off();
 
-   tegra_pcie_xclk_clamp(true);
+   tegra_pmc_pcie_xclk_clamp(true);
 
tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
tegra_periph_reset_assert(tegra_pcie.afi_clk);
@@ -681,7 +659,7 @@ static int tegra_pcie_power_regate(void)
 
tegra_periph_reset_deassert(tegra_pcie.afi_clk);
 
-   tegra_pcie_xclk_clamp(false);
+   tegra_pmc_pcie_xclk_clamp(false);
 
clk_prepare_enable(tegra_pcie.afi_clk);
clk_prepare_enable(tegra_pcie.pex_clk);
diff --git a/arch/arm/mach-tegra/pmc.c b/arch/arm/mach-tegra/pmc.c
index b30e921..f82284c 100644
--- a/arch/arm/mach-tegra/pmc.c
+++ b/arch/arm/mach-tegra/pmc.c
@@ -44,6 +44,10 @@ static DEFINE_SPINLOCK(tegra_powergate_lock);
 static void __iomem *tegra_pmc_base;
 static bool tegra_pmc_invert_interrupt;
 
+/* PMC access is required for PCIE xclk (un)clamping */
+#define PMC_SCRATCH42  0x144
+#define PMC_SCRATCH42_PCX_CLAMP(1 << 0)
+
 static inline u32 tegra_pmc_readl(u32 reg)
 {
return readl(tegra_pmc_base + reg);
@@ -166,3 +170,15 @@ void __init tegra_pmc_init(void)
val &= ~PMC_CTRL_INTR_LOW;
tegra_pmc_writel(val, PMC_CTRL);
 }
+
+void tegra_pmc_pcie_xclk_clamp(bool clamp)
+{
+   u32 reg;
+
+   reg = tegra_pmc_readl(PMC_SCRATCH42) & ~PMC_SCRATCH42_PCX_CLAMP;
+
+   if (clamp)
+   reg |= PMC_SCRATCH42_PCX_CLAMP;
+
+   tegra_pmc_writel(reg, PMC_SCRATCH42);
+}
diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index 7d44710..c778451 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -23,5 +23,6 @@ int tegra_pmc_cpu_power_on(int cpuid);
 int tegra_pmc_cpu_remove_clamping(int cpuid);
 
 void tegra_pmc_init(void);
+void tegra_pmc_pcie_xclk_clamp(bool clamp);
 
 #endif
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 06/14] clk: tegra: move from a lock bit idx to a lock mask

[Peter De Schrijver]

PLLC2 and PLLC3 on Tegra114 have separate phaselock and frequencylock bits.
So switch to a lock mask to be able to test both at the same time.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-pll.c |6 +++---
 drivers/clk/tegra/clk-tegra20.c |   20 ++--
 drivers/clk/tegra/clk-tegra30.c |   22 +++---
 drivers/clk/tegra/clk.h |2 +-
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index ccb367e..0b96352 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -119,7 +119,7 @@ static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
 static int clk_pll_wait_for_lock(struct tegra_clk_pll *pll)
 {
int i;
-   u32 val, lock_bit;
+   u32 val, lock_mask;
void __iomem *lock_addr;
 
if (!(pll->flags & TEGRA_PLL_USE_LOCK)) {
@@ -133,11 +133,11 @@ static int clk_pll_wait_for_lock(struct tegra_clk_pll 
*pll)
else
lock_addr += pll->params->base_reg;
 
-   lock_bit = BIT(pll->params->lock_bit_idx);
+   lock_mask = pll->params->lock_mask;
 
for (i = 0; i < pll->params->lock_delay; i++) {
val = readl_relaxed(lock_addr);
-   if (val & lock_bit) {
+   if ((val & lock_mask) == lock_mask) {
udelay(PLL_POST_LOCK_DELAY);
return 0;
}
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index b1a49cb..b6a747f 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -86,8 +86,8 @@
 #define PLLE_BASE 0xe8
 #define PLLE_MISC 0xec
 
-#define PLL_BASE_LOCK 27
-#define PLLE_MISC_LOCK 11
+#define PLL_BASE_LOCK BIT(27)
+#define PLLE_MISC_LOCK BIT(11)
 
 #define PLL_MISC_LOCK_ENABLE 18
 #define PLLDU_MISC_LOCK_ENABLE 22
@@ -380,7 +380,7 @@ static struct tegra_clk_pll_params pll_c_params = {
.vco_max = 14,
.base_reg = PLLC_BASE,
.misc_reg = PLLC_MISC,
-   .lock_bit_idx = PLL_BASE_LOCK,
+   .lock_mask = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
 };
@@ -394,7 +394,7 @@ static struct tegra_clk_pll_params pll_m_params = {
.vco_max = 12,
.base_reg = PLLM_BASE,
.misc_reg = PLLM_MISC,
-   .lock_bit_idx = PLL_BASE_LOCK,
+   .lock_mask = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
 };
@@ -408,7 +408,7 @@ static struct tegra_clk_pll_params pll_p_params = {
.vco_max = 14,
.base_reg = PLLP_BASE,
.misc_reg = PLLP_MISC,
-   .lock_bit_idx = PLL_BASE_LOCK,
+   .lock_mask = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
 };
@@ -422,7 +422,7 @@ static struct tegra_clk_pll_params pll_a_params = {
.vco_max = 14,
.base_reg = PLLA_BASE,
.misc_reg = PLLA_MISC,
-   .lock_bit_idx = PLL_BASE_LOCK,
+   .lock_mask = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
 };
@@ -436,7 +436,7 @@ static struct tegra_clk_pll_params pll_d_params = {
.vco_max = 10,
.base_reg = PLLD_BASE,
.misc_reg = PLLD_MISC,
-   .lock_bit_idx = PLL_BASE_LOCK,
+   .lock_mask = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
 };
@@ -456,7 +456,7 @@ static struct tegra_clk_pll_params pll_u_params = {
.vco_max = 96000,
.base_reg = PLLU_BASE,
.misc_reg = PLLU_MISC,
-   .lock_bit_idx = PLL_BASE_LOCK,
+   .lock_mask = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
.pdiv_tohw = pllu_p,
@@ -471,7 +471,7 @@ static struct tegra_clk_pll_params pll_x_params = {
.vco_max = 12,
.base_reg = PLLX_BASE,
.misc_reg = PLLX_MISC,
-   .lock_bit_idx = PLL_BASE_LOCK,
+   .lock_mask = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
.lock_delay = 300,
 };
@@ -485,7 +485,7 @@ static struct tegra_clk_pll_params pll_e_params = {
.vco_max = 0,
.base_reg = PLLE_BASE,
.misc_reg = PLLE_MISC,
-   .lock_bit_idx = PLLE_MISC_LOCK,
+   .lock_mask = PLLE_MISC_LOCK,
.lock_enable_bit_idx = PLLE_MISC_LOCK_ENABLE,
.lock_delay = 0,
 };
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 102bcbb..9c43bb4 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -116,8 +116,8 @@
 #define PLLDU_MISC_LOCK_ENABLE 22
 #define PLLE_MISC_LOCK_ENABLE 9
 
-#define PLL_BASE_LOCK 27
-#define PLLE_MISC_LOCK 11
+#define PLL_BASE_LOCK BIT(27)
+#define PLLE_MISC_LOCK BIT(11)
 
 #define PLLE_AUX 0x48c
 #define PLLC_OUT 0x84
@@ -559,7 +559,7 @@ static struct 

[PATCH v3 04/12] PCI: Introduce new MSI chip infrastructure

[Thierry Reding]

The new struct msi_chip is used to associated an MSI controller with a
PCI bus. It is automatically handed down from the root to its children
during bus enumeration.

This patch provides default (weak) implementations for the architecture-
specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
and arch_msi_check_device()) which check if a PCI device's bus has an
attached MSI chip and forward the call appropriately.

Signed-off-by: Thierry Reding 
---
 drivers/pci/msi.c   | 35 +++
 drivers/pci/probe.c |  1 +
 include/linux/msi.h | 10 ++
 include/linux/pci.h |  1 +
 4 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 00cc78c..fce3549 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -26,14 +26,41 @@
 
 static int pci_msi_enable = 1;
 
-/* Arch hooks */
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+{
+   struct msi_chip *chip = dev->bus->msi;
+
+   if (chip && chip->setup_irq) {
+   int err;
+
+   err = chip->setup_irq(chip, dev, desc);
+   if (err < 0)
+   return err;
+
+   irq_set_chip_data(desc->irq, chip);
+   return err;
+   }
+
+   return -EINVAL;
+}
 
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+void __weak arch_teardown_msi_irq(unsigned int irq)
 {
+   struct msi_chip *chip = irq_get_chip_data(irq);
+
+   if (chip && chip->teardown_irq)
+   chip->teardown_irq(chip, irq);
+}
+
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+   struct msi_chip *chip = dev->bus->msi;
+
+   if (chip && chip->check_device)
+   return chip->check_device(chip, dev, nvec, type);
+
return 0;
 }
-#endif
 
 #ifndef arch_setup_msi_irqs
 # define arch_setup_msi_irqs default_setup_msi_irqs
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b494066..9307550 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus 
*parent,
 
child->parent = parent;
child->ops = parent->ops;
+   child->msi = parent->msi;
child->sysdata = parent->sysdata;
child->bus_flags = parent->bus_flags;
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ce93a34..ea4a5be 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -58,5 +58,15 @@ extern int arch_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type);
 extern void arch_teardown_msi_irqs(struct pci_dev *dev);
 extern int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
 
+struct msi_chip {
+   struct module *owner;
+   struct device *dev;
+
+   int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
+struct msi_desc *desc);
+   void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
+   int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
+   int nvec, int type);
+};
 
 #endif /* LINUX_MSI_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index f42cdc6..7e44085 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -431,6 +431,7 @@ struct pci_bus {
struct resource busn_res;   /* bus numbers routed to this bus */
 
struct pci_ops  *ops;   /* configuration access functions */
+   struct msi_chip *msi;   /* MSI controller */
void*sysdata;   /* hook for sys-specific extension */
struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
 
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 06/12] ARM: tegra: Move pmc.h to include/linux/tegra-pmc.h

[Thierry Reding]

In preparation for moving the PCIe driver into the drivers/pci/host
directory, this header, which contains prototypes that are required by
the PCIe driver, needs to be moved to a globally visible location.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- keep tegra_pmc_init() prototype in arch/arm/mach-tegra/pmc.h
- move pmc.h to includex/linux/tegra-pmc.h

Changes in v3:
- update subject to match new location

 arch/arm/mach-tegra/pmc.h |  1 -
 include/linux/tegra-pmc.h | 23 +++
 2 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/tegra-pmc.h

diff --git a/arch/arm/mach-tegra/pmc.h b/arch/arm/mach-tegra/pmc.h
index c778451..7d44710 100644
--- a/arch/arm/mach-tegra/pmc.h
+++ b/arch/arm/mach-tegra/pmc.h
@@ -23,6 +23,5 @@ int tegra_pmc_cpu_power_on(int cpuid);
 int tegra_pmc_cpu_remove_clamping(int cpuid);
 
 void tegra_pmc_init(void);
-void tegra_pmc_pcie_xclk_clamp(bool clamp);
 
 #endif
diff --git a/include/linux/tegra-pmc.h b/include/linux/tegra-pmc.h
new file mode 100644
index 000..b6296bf
--- /dev/null
+++ b/include/linux/tegra-pmc.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2012 NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+
+#ifndef __LINUX_TEGRA_PMC_H
+#define __LINUX_TEGRA_PMC_H
+
+void tegra_pmc_pcie_xclk_clamp(bool clamp);
+
+#endif
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 05/14] clk: tegra: Add PLL post divider table

[Peter De Schrijver]

Some PLLs in Tegra114 don't use a power of 2 mapping for the post divider.
Introduce a table based approach and switch PLLU to it.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-pll.c |   38 --
 drivers/clk/tegra/clk-tegra20.c |7 +++
 drivers/clk/tegra/clk-tegra30.c |7 +++
 drivers/clk/tegra/clk.h |   13 +
 4 files changed, 59 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index eaab060..ccb367e 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -266,6 +266,7 @@ static int _calc_rate(struct clk_hw *hw, struct 
tegra_clk_pll_freq_table *cfg,
  unsigned long rate, unsigned long parent_rate)
 {
struct tegra_clk_pll *pll = to_clk_pll(hw);
+   struct pdiv_map *p_tohw = pll->params->pdiv_tohw;
unsigned long cfreq;
u32 p_div = 0;
 
@@ -299,7 +300,6 @@ static int _calc_rate(struct clk_hw *hw, struct 
tegra_clk_pll_freq_table *cfg,
 cfg->output_rate <<= 1)
p_div++;
 
-   cfg->p = p_div;
cfg->m = parent_rate / cfreq;
cfg->n = cfg->output_rate / cfreq;
cfg->cpcon = OUT_OF_TABLE_CPCON;
@@ -312,8 +312,19 @@ static int _calc_rate(struct clk_hw *hw, struct 
tegra_clk_pll_freq_table *cfg,
return -EINVAL;
}
 
-   if (pll->flags & TEGRA_PLLU)
-   cfg->p ^= 1;
+   if (p_tohw) {
+   p_div = 1 << p_div;
+   while (p_tohw->pdiv) {
+   if (p_div <= p_tohw->pdiv) {
+   cfg->p = p_tohw->hw_val;
+   break;
+   }
+   p_tohw++;
+   }
+   if (!p_tohw->pdiv)
+   return -EINVAL;
+   } else
+   cfg->p = p_div;
 
return 0;
 }
@@ -460,8 +471,10 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
 {
struct tegra_clk_pll *pll = to_clk_pll(hw);
struct tegra_clk_pll_freq_table cfg;
+   struct pdiv_map *p_tohw = pll->params->pdiv_tohw;
u32 val;
u64 rate = parent_rate;
+   int pdiv;
 
val = pll_readl_base(pll);
 
@@ -480,10 +493,23 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw 
*hw,
 
_get_pll_mnp(pll, );
 
-   if (pll->flags & TEGRA_PLLU)
-   cfg.p ^= 1;
+   if (p_tohw) {
+   while (p_tohw->pdiv) {
+   if (cfg.p == p_tohw->hw_val) {
+   pdiv = p_tohw->pdiv;
+   break;
+   }
+   p_tohw++;
+   }
+
+   if (!p_tohw->pdiv) {
+   WARN_ON(1);
+   pdiv = 1;
+   }
+   } else
+   pdiv = 1 << cfg.p;
 
-   cfg.m *= 1 << cfg.p;
+   cfg.m *= pdiv;
 
rate *= cfg.n;
do_div(rate, cfg.m);
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 13efdfb..b1a49cb 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -441,6 +441,12 @@ static struct tegra_clk_pll_params pll_d_params = {
.lock_delay = 1000,
 };
 
+static struct pdiv_map pllu_p[] = {
+   { .pdiv = 1, .hw_val = 1 },
+   { .pdiv = 2, .hw_val = 0 },
+   { .pdiv = 0, .hw_val = 0 },
+};
+
 static struct tegra_clk_pll_params pll_u_params = {
.input_min = 200,
.input_max = 4000,
@@ -453,6 +459,7 @@ static struct tegra_clk_pll_params pll_u_params = {
.lock_bit_idx = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
+   .pdiv_tohw = pllu_p,
 };
 
 static struct tegra_clk_pll_params pll_x_params = {
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index a7b955c..102bcbb 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -467,6 +467,12 @@ static struct tegra_clk_pll_freq_table pll_d_freq_table[] 
= {
{ 0, 0, 0, 0, 0, 0 },
 };
 
+static struct pdiv_map pllu_p[] = {
+   { .pdiv = 1, .hw_val = 1 },
+   { .pdiv = 2, .hw_val = 0 },
+   { .pdiv = 0, .hw_val = 0 },
+};
+
 static struct tegra_clk_pll_freq_table pll_u_freq_table[] = {
{ 1200, 48000, 960, 12, 0, 12},
{ 1300, 48000, 960, 13, 0, 12},
@@ -640,6 +646,7 @@ static struct tegra_clk_pll_params pll_u_params = {
.lock_bit_idx = PLL_BASE_LOCK,
.lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
.lock_delay = 1000,
+   .pdiv_tohw = pllu_p,
 };
 
 static struct tegra_clk_pll_params pll_x_params = {
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 17ddb22..925da45 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -117,6 +117,17 @@ struct tegra_clk_pll_freq_table {
 };
 
 /**

[PATCH v9 04/14] clk: tegra: introduce TEGRA_PLL_HAS_LOCK_ENABLE

[Peter De Schrijver]

Tegra114 PLLC2 and PLLC3 don't have a lock enable bit. The lock bits are
always functional.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-pll.c |5 +
 drivers/clk/tegra/clk.h |2 ++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 4ee6d03..eaab060 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -108,6 +108,9 @@ static void clk_pll_enable_lock(struct tegra_clk_pll *pll)
if (!(pll->flags & TEGRA_PLL_USE_LOCK))
return;
 
+   if (!(pll->flags & TEGRA_PLL_HAS_LOCK_ENABLE))
+   return;
+
val = pll_readl_misc(pll);
val |= BIT(pll->params->lock_enable_bit_idx);
pll_writel_misc(val, pll);
@@ -675,6 +678,7 @@ struct clk *tegra_clk_register_pll(const char *name, const 
char *parent_name,
struct clk *clk;
 
pll_flags |= TEGRA_PLL_BYPASS;
+   pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
  freq_table, lock);
if (IS_ERR(pll))
@@ -698,6 +702,7 @@ struct clk *tegra_clk_register_plle(const char *name, const 
char *parent_name,
struct clk *clk;
 
pll_flags |= TEGRA_PLL_LOCK_MISC | TEGRA_PLL_BYPASS;
+   pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
  freq_table, lock);
if (IS_ERR(pll))
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index fff520a..17ddb22 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -185,6 +185,7 @@ struct tegra_clk_pll_params {
  * TEGRA_PLL_LOCK_MISC - Lock bit is in the misc register instead of the
  * base register.
  * TEGRA_PLL_BYPASS - PLL has bypass bit
+ * TEGRA_PLL_HAS_LOCK_ENABLE - PLL has bit to enable lock monitoring
  */
 struct tegra_clk_pll {
struct clk_hw   hw;
@@ -215,6 +216,7 @@ struct tegra_clk_pll {
 #define TEGRA_PLLE_CONFIGURE BIT(7)
 #define TEGRA_PLL_LOCK_MISC BIT(8)
 #define TEGRA_PLL_BYPASS BIT(9)
+#define TEGRA_PLL_HAS_LOCK_ENABLE BIT(10)
 
 extern const struct clk_ops tegra_clk_pll_ops;
 extern const struct clk_ops tegra_clk_plle_ops;
-- 
1.7.7.rc0.72.g4b5ea.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen

[Stefano Stabellini]

On Wed, 3 Apr 2013, Nicolas Pitre wrote:
> On Wed, 3 Apr 2013, Stefano Stabellini wrote:
> 
> > On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> > > On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> > > 
> > > > @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int 
> > > > cpu)
> > > > return 0;
> > > >  }
> > > >  
> > > > +static void __init xen_smp_init(void)
> > > > +{
> > > > +   if (psci_smp_available())
> > > > +   smp_set_ops(_smp_ops);
> > > > +}
> > > > +
> > > 
> > > I still don't understand why you need to do this.  Why can't you just 
> > > rely on the next priority which is to set PSCI ops by default if 
> > > available?  Using this hook for Xen doesn't look justified. As it is, 
> > > you break MCPM.
> > > 
> > > As I explained to you, MCPM will end up using PSCI as well when 
> > > available, which I think should be sufficient for your concern.
> > 
> > The smp_init hook is not limited to MCPM or the versatile express
> > platform. It's a generic hook that can be used by any platform and can
> > override the platform smp_ops or the psci_smp_ops depending on platform
> > specific configurations.
> > 
> > Configurations that I am pretty sure won't be available on Xen anyway,
> > while I am certain that using psci_smp_ops would work.
> > 
> > It seems to me that relying on the fact that only versatile express and
> > only MCPM use smp_init, even though it might work today, it's very
> > fragile and could break tomorrow without any of us noticing.
> 
> I claim: this breaks MCPM today.
>
> You claim: the alternative _could_ break with Xen tomorrow.
> 
> Could we please wait until there is an actual problem with Xen before 
> being overly defensive in the code?

Sorry, I realized that I should have explained myself better.

The smp_init patch together with the MCPM patch series
(http://marc.info/?l=linux-arm-kernel=136004188122492) breaks Xen Dom0
SMP support on versatile express *today* (ifndef CONFIG_CLUSTER_PM):
smp_init is not NULL on versatile express anymore therefore smp_init is
going to be called, causing vexpress_smp_ops to be selected even if psci
is on device tree.

On the other hand if this patch was applied, xen_smp_init would override
smp_init making sure that psci_smp_ops is used on Xen and everything
would work as expected.


So as it stands today, we need this patch for regular Xen Dom0 SMP
support.


BTW I have actually tried it on my versatile express machine to make
sure that it is correct :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.8-stable] thermal: return an error on failure to register thermal

[Luis Henriques]

On Wed, Apr 03, 2013 at 09:38:55AM +0900, Jonghwan Choi wrote:
> 3.8-stable review patch.  If anyone has any objections, please let me know.

I believe this is applicable to all the other stable kernels.

Cheers,
--
Luis

> 
> --
> 
> From: "Richard Guy Briggs "
> 
> commit da28d966f6aa942ae836d09729f76a1647932309 upstream.
> 
> The return code from the registration of the thermal class is used to
> unallocate resources, but this failure isn't passed back to the caller of
> thermal_init.  Return this failure back to the caller.
> 
> This bug was introduced in changeset 4cb18728 which overwrote the return
> code
> when the variable was re-used to catch the return code of the registration
> of
> the genetlink thermal socket family.
> 
> Signed-off-by: Richard Guy Briggs 
> Signed-off-by: Zhang Rui 
> ---
>  drivers/thermal/thermal_sys.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c
> index 6472e7e..1a19a2f 100644
> --- a/drivers/thermal/thermal_sys.c
> +++ b/drivers/thermal/thermal_sys.c
> @@ -1875,6 +1875,7 @@ static int __init thermal_init(void)
>   idr_destroy(_cdev_idr);
>   mutex_destroy(_idr_lock);
>   mutex_destroy(_list_lock);
> + return result;
>   }
>   result = genetlink_init();
>   return result;
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" 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/

[PATCH] x86: fix rebuild with EFI_STUB enabled

[Jan Beulich]

eboot.o and efi_stub_$(BITS).o didn't get added to "targets", and hence
their .cmd files don't get included by the build machinery, leading to
the files always getting rebuilt.

Rather than adding the two files individually, take the opportunity and
add $(VMLINUX_OBJS) to "targets" instead, thus allowing the assignment
at the top of the file to be shrunk quite a bit.

At the same time, remove a pointless flags override line - the variable
assigned to was misspelled anyway, and the options added are
meaningless for assembly sources.

Signed-off-by: Jan Beulich 
Cc: Matthew Garrett 
Cc: Matt Fleming 
---
 arch/x86/boot/compressed/Makefile |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- 3.9-rc5/arch/x86/boot/compressed/Makefile
+++ 3.9-rc5-x86-EFI-stub-rebuild/arch/x86/boot/compressed/Makefile
@@ -4,7 +4,7 @@
 # create a compressed vmlinux image from the original vmlinux
 #
 
-targets := vmlinux.lds vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 
vmlinux.bin.lzma vmlinux.bin.xz vmlinux.bin.lzo head_$(BITS).o misc.o string.o 
cmdline.o early_serial_console.o piggy.o
+targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma 
vmlinux.bin.xz vmlinux.bin.lzo
 
 KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2
 KBUILD_CFLAGS += -fno-strict-aliasing -fPIC
@@ -29,7 +29,6 @@ VMLINUX_OBJS = $(obj)/vmlinux.lds $(obj)
$(obj)/piggy.o
 
 $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
-$(obj)/efi_stub_$(BITS).o: KBUILD_CLFAGS += -fshort-wchar -mno-red-zone
 
 ifeq ($(CONFIG_EFI_STUB), y)
VMLINUX_OBJS += $(obj)/eboot.o $(obj)/efi_stub_$(BITS).o
@@ -43,7 +42,7 @@ OBJCOPYFLAGS_vmlinux.bin :=  -R .comment
 $(obj)/vmlinux.bin: vmlinux FORCE
$(call if_changed,objcopy)
 
-targets += vmlinux.bin.all vmlinux.relocs
+targets += $(patsubst $(obj)/%,%,$(VMLINUX_OBJS)) vmlinux.bin.all 
vmlinux.relocs
 
 CMD_RELOCS = arch/x86/tools/relocs
 quiet_cmd_relocs = RELOCS  $@



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: Check all MSRs before passing hw check

[George Dunlap]

check_hw_exists has a number of checks which go to two exit paths:
msr_fail and bios_fail.  Checks classified as msr_fail will cause
check_hw_exists() to return false, causing the PMU not to be used;
bios_fail checks will only cause a warning to be printed, but will
return true.

The problem is that if there are both msr failures and bios failures,
and the routine hits a bios_fail check first, it will exit early and
return true, not finishing the rest of the msr checks.  If those msrs
are in fact broken, it will cause them to be used erroneously.

In the case of a Xen PV VM, the guest OS has read access to all the
MSRs, but write access is white-listed to supported features.  Writes
to unsupported MSRs have no effect.  The PMU MSRs are not (typically)
supported, because they are expensive to save and restore on a VM
context switch.  One of the "msr_fail" checks is supposed to detect
this circumstance (ether for Xen or KVM) and disable the harware PMU.

However, on one of my AMD boxen, there is (apparently) a broken BIOS
which triggers one of the bios_fail checks.  In particular,
MSR_K7_EVNTSEL0 has the ARCH_PERFMON_EVENTSEL_ENABLE bit set.  The
guest kernel detects this because it has read access to all MSRs, and
causes it to skip the rest of the checks and try to use the
non-existent hardware PMU.  This minimally causes a lot of useless
instruction emulation and Xen console spam; it may cause other issues
with the watchdog as well.

This changset causes check_hw_exists() to go through all of the msr
checks, failing and returning false if any of them fail.  This makes
sure that a guest running under Xen without a virtual PMU will detect
that there is no functioning PMU and not attempt to use it.

This problem affects kernels as far back as 3.2, and should thus be
considered for backport.

v3:
 - Save the register and value which failed, and print them once at the end.
v2:
 - Print the warning when the event happens so the reg,val make sense
 - But print it only for the first such instance
 - Update changelog to include details of failing system

Signed-off-by: George Dunlap 
CC: Konrad Wilk 
CC: Thomas Gleixner 
CC: "H. Peter Anvin" 
CC: Ingo Molnar 
CC: x...@kernel.org
CC: Ian Campbell 
CC: David Vrabel 
CC: Andrew Cooper 
---
 arch/x86/kernel/cpu/perf_event.c |   30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 6774c17..2456bae 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -180,8 +180,9 @@ static void release_pmc_hardware(void) {}
 
 static bool check_hw_exists(void)
 {
-   u64 val, val_new = ~0;
-   int i, reg, ret = 0;
+   u64 val, val_fail, val_new= ~0;
+   int i, reg, reg_fail, ret = 0;
+   int bios_fail = 0;
 
/*
 * Check to see if the BIOS enabled any of the counters, if so
@@ -192,8 +193,11 @@ static bool check_hw_exists(void)
ret = rdmsrl_safe(reg, );
if (ret)
goto msr_fail;
-   if (val & ARCH_PERFMON_EVENTSEL_ENABLE)
-   goto bios_fail;
+   if (val & ARCH_PERFMON_EVENTSEL_ENABLE) {
+   bios_fail = 1;
+   val_fail = val;
+   reg_fail = reg;
+   }
}
 
if (x86_pmu.num_counters_fixed) {
@@ -202,8 +206,11 @@ static bool check_hw_exists(void)
if (ret)
goto msr_fail;
for (i = 0; i < x86_pmu.num_counters_fixed; i++) {
-   if (val & (0x03 << i*4))
-   goto bios_fail;
+   if (val & (0x03 << i*4)) {
+   bios_fail = 1;
+   val_fail = val;
+   reg_fail = reg;
+   }
}
}
 
@@ -221,14 +228,13 @@ static bool check_hw_exists(void)
if (ret || val != val_new)
goto msr_fail;
 
-   return true;
-
-bios_fail:
/*
 * We still allow the PMU driver to operate:
-*/
-   printk(KERN_CONT "Broken BIOS detected, complain to your hardware 
vendor.\n");
-   printk(KERN_ERR FW_BUG "the BIOS has corrupted hw-PMU resources (MSR %x 
is %Lx)\n", reg, val);
+*/ 
+   if (bios_fail) {
+   printk(KERN_CONT "Broken BIOS detected, complain to your 
hardware vendor.\n");
+   printk(KERN_ERR FW_BUG "the BIOS has corrupted hw-PMU resources 
(MSR %x is %Lx)\n", reg_fail, val_fail);
+   }
 
return true;
 
-- 
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 11/12] ARM: tegra: trimslice: Initialize PCIe from DT

[Thierry Reding]

With the device tree support in place, probe the PCIe controller from
the device tree and remove the corresponding workaround in the board
file.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- add missing dummy regulator nodes by Stephen Warren
- rename port 0 DT node and disable unused port 1

 arch/arm/boot/dts/tegra20-trimslice.dts | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts 
b/arch/arm/boot/dts/tegra20-trimslice.dts
index 955bf49..dc081c3 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -300,6 +300,16 @@
};
};
 
+   pcie-controller {
+   status = "okay";
+   pex-clk-supply = <_clk_reg>;
+   vdd-supply = <_vdd_reg>;
+
+   pci@1,0 {
+   status = "okay";
+   };
+   };
+
usb@c500 {
status = "okay";
nvidia,vbus-gpio = < 170 0>; /* gpio PV2 */
@@ -357,6 +367,24 @@
regulator-max-microvolt = <180>;
regulator-always-on;
};
+
+   pci_clk_reg: regulator@2 {
+   compatible = "regulator-fixed";
+   reg = <2>;
+   regulator-name = "pci_clk";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   pci_vdd_reg: regulator@3 {
+   compatible = "regulator-fixed";
+   reg = <3>;
+   regulator-name = "pci_vdd";
+   regulator-min-microvolt = <105>;
+   regulator-max-microvolt = <105>;
+   regulator-always-on;
+   };
};
 
sound {
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 03/12] of/pci: Add of_pci_parse_bus_range() function

[Thierry Reding]

This function can be used to parse a bus-range property as specified by
device nodes representing PCI bridges.

Signed-off-by: Thierry Reding 
---
 drivers/of/of_pci.c| 25 +
 include/linux/of_pci.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 4dd7b9b..42c687a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -64,3 +64,28 @@ int of_pci_get_devfn(struct device_node *np)
return (be32_to_cpup(reg) >> 8) & 0xff;
 }
 EXPORT_SYMBOL_GPL(of_pci_get_devfn);
+
+/**
+ * of_pci_parse_bus_range() - parse the bus-range property of a PCI device
+ * @node: device node
+ * @res: address to a struct resource to return the bus-range
+ *
+ * Returns 0 on success or a negative error-code on failure.
+ */
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
+{
+   const __be32 *values;
+   int len;
+
+   values = of_get_property(node, "bus-range", );
+   if (!values || len < sizeof(*values) * 2)
+   return -EINVAL;
+
+   res->name = node->name;
+   res->start = be32_to_cpup(values++);
+   res->end = be32_to_cpup(values);
+   res->flags = IORESOURCE_BUS;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 91ec484..7a04826 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -11,5 +11,6 @@ struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 unsigned int devfn);
 int of_pci_get_devfn(struct device_node *np);
+int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 
 #endif
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen: Don't call arch_trigger_all_cpu_backtrace in dom0(pvm)

[Konrad Rzeszutek Wilk]

On Wed, Apr 03, 2013 at 08:00:37PM +0800, Zhenzhong Duan wrote:
> 
> On 2013-04-01 20:41, Konrad Rzeszutek Wilk wrote:
> >On Mon, Apr 01, 2013 at 01:26:34PM +0800, Zhenzhong Duan wrote:
> >>On 2013-03-29 21:46, Konrad Rzeszutek Wilk wrote:
> >>>On Fri, Mar 29, 2013 at 03:22:38PM +0800, Zhenzhong Duan wrote:
> >>The problem is even without overwrite, like xapic system,
> >>xen_send_IPI_all doesn't work for nmi vector.
> >Can you tweak the x2apic_mode = 0 in enligthen.c for example?
> >Or clear the X86_FEATURE_X2APIC in the enlighten.c ? (Similar
> >to how the other features are cleared) Wouldn't
> >that stop x2apic_enabled from detecting x2APIC?
> Hi Konrad,
> I used the second method. x2apic is totally masked in dom0. Thanks
> Tamon to do the test.
> 
> Testing result:
> 
> The server didn't get crashed by "echo l > /proc/sysrq-trigger". On this 
> machine, VT-d is enabled in BIOS.
> However, no backtrace was shown.
> 
> [root@x4470m2-bur09-b ~]# uname -a
> Linux x4470m2-bur09-b.us.oracle.com 2.6.39-200.1.14.el5uek.bug16372098.test 
> #1 SMP Tue Apr 2 21:09:27 PDT 2013 x86_64 x86_64 x86_64 GNU/Linux
> [root@x4470m2-bur09-b ~]# cat /proc/cpuinfo | grep x2apic
> [root@x4470m2-bur09-b ~]# dmesg | grep x2apic
> [root@x4470m2-bur09-b ~]# cat /proc/cmdline
> ro root=UUID=486fc42b-3383-462f-aca3-b1340fbd4ad9 console=tty1 
> console=ttyS0,9600n8
> [root@x4470m2-bur09-b ~]# echo l > /proc/sysrq-trigger
> [root@x4470m2-bur09-b ~]#
> 
> /var/log/messages:
> (snip)
> Apr  3 14:14:33 x4470m2-bur09-b kernel: SysRq : Show backtrace of all active 
> CPUs
> Apr  3 14:14:33 x4470m2-bur09-b kernel: sending NMI to all CPUs:
> (EOF)
> 
> On the console, no backtrace either. I did it twice, and got the same results.

Great.
Zhenzhong, do you want to prep a patch with a nice git commit description 
mentioning
your findings of the x2APIC over-write and also include the crach that would
appear?

And send it to xen-devel + LKML and to me so I can put it on my v3.9 branch?

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 v9 03/14] clk: tegra: Add TEGRA_PLL_BYPASS flag

[Peter De Schrijver]

Not all PLLs in Tegra114 have a bypass bit. Adapt the common code to only use
this bit when available.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-pll.c |   12 
 drivers/clk/tegra/clk.h |2 ++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 3feefb1..4ee6d03 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -171,7 +171,8 @@ static void _clk_pll_enable(struct clk_hw *hw)
clk_pll_enable_lock(pll);
 
val = pll_readl_base(pll);
-   val &= ~PLL_BASE_BYPASS;
+   if (pll->flags & TEGRA_PLL_BYPASS)
+   val &= ~PLL_BASE_BYPASS;
val |= PLL_BASE_ENABLE;
pll_writel_base(val, pll);
 
@@ -188,7 +189,9 @@ static void _clk_pll_disable(struct clk_hw *hw)
u32 val;
 
val = pll_readl_base(pll);
-   val &= ~(PLL_BASE_BYPASS | PLL_BASE_ENABLE);
+   if (pll->flags & TEGRA_PLL_BYPASS)
+   val &= ~PLL_BASE_BYPASS;
+   val &= ~PLL_BASE_ENABLE;
pll_writel_base(val, pll);
 
if (pll->flags & TEGRA_PLLM) {
@@ -459,7 +462,7 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
 
val = pll_readl_base(pll);
 
-   if (val & PLL_BASE_BYPASS)
+   if ((pll->flags & TEGRA_PLL_BYPASS) && (val & PLL_BASE_BYPASS))
return parent_rate;
 
if ((pll->flags & TEGRA_PLL_FIXED) && !(val & PLL_BASE_OVERRIDE)) {
@@ -671,6 +674,7 @@ struct clk *tegra_clk_register_pll(const char *name, const 
char *parent_name,
struct tegra_clk_pll *pll;
struct clk *clk;
 
+   pll_flags |= TEGRA_PLL_BYPASS;
pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
  freq_table, lock);
if (IS_ERR(pll))
@@ -692,8 +696,8 @@ struct clk *tegra_clk_register_plle(const char *name, const 
char *parent_name,
 {
struct tegra_clk_pll *pll;
struct clk *clk;
-   pll_flags |= TEGRA_PLL_LOCK_MISC;
 
+   pll_flags |= TEGRA_PLL_LOCK_MISC | TEGRA_PLL_BYPASS;
pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
  freq_table, lock);
if (IS_ERR(pll))
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index b9691dd..fff520a 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -184,6 +184,7 @@ struct tegra_clk_pll_params {
  * TEGRA_PLLE_CONFIGURE - Configure PLLE when enabling.
  * TEGRA_PLL_LOCK_MISC - Lock bit is in the misc register instead of the
  * base register.
+ * TEGRA_PLL_BYPASS - PLL has bypass bit
  */
 struct tegra_clk_pll {
struct clk_hw   hw;
@@ -213,6 +214,7 @@ struct tegra_clk_pll {
 #define TEGRA_PLL_FIXED BIT(6)
 #define TEGRA_PLLE_CONFIGURE BIT(7)
 #define TEGRA_PLL_LOCK_MISC BIT(8)
+#define TEGRA_PLL_BYPASS BIT(9)
 
 extern const struct clk_ops tegra_clk_pll_ops;
 extern const struct clk_ops tegra_clk_plle_ops;
-- 
1.7.7.rc0.72.g4b5ea.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/12] ARM: tegra: tec: Add PCIe support

[Thierry Reding]

Enable the first PCIe root port which is connected to an FPGA on the
Tamonten Evaluation Carrier and add device nodes for each of the PCI
endpoints available in the standard configuration.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- remove duplicate nodes and properties defined in tegra20-tamonten.dtsi

Changes in v3:
- remove PCIe endpoint device tree nodes, all devices can be discovered
  via standard PCI enumeration

 arch/arm/boot/dts/tegra20-tec.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20-tec.dts 
b/arch/arm/boot/dts/tegra20-tec.dts
index 1ae37ba..e396cb2 100644
--- a/arch/arm/boot/dts/tegra20-tec.dts
+++ b/arch/arm/boot/dts/tegra20-tec.dts
@@ -64,6 +64,14 @@
};
};
 
+   pcie-controller {
+   status = "okay";
+
+   pci@1,0 {
+   status = "okay";
+   };
+   };
+
sound {
compatible = "ad,tegra-audio-wm8903-tec",
 "nvidia,tegra-audio-wm8903";
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 02/12] of/pci: Add of_pci_get_devfn() function

[Thierry Reding]

This function can be used to parse the device and function number from a
standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
the returned value obtain the device and function numbers respectively.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- rename devfn and err variables for clarity

 drivers/of/of_pci.c| 34 +-
 include/linux/of_pci.h |  1 +
 2 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13e37e2..4dd7b9b 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -5,14 +5,15 @@
 #include 
 
 static inline int __of_pci_pci_compare(struct device_node *node,
-  unsigned int devfn)
+  unsigned int data)
 {
-   unsigned int size;
-   const __be32 *reg = of_get_property(node, "reg", );
+   int devfn;
 
-   if (!reg || size < 5 * sizeof(__be32))
+   devfn = of_pci_get_devfn(node);
+   if (devfn < 0)
return 0;
-   return ((be32_to_cpup([0]) >> 8) & 0xff) == devfn;
+
+   return devfn == data;
 }
 
 struct device_node *of_pci_find_child_device(struct device_node *parent,
@@ -40,3 +41,26 @@ struct device_node *of_pci_find_child_device(struct 
device_node *parent,
return NULL;
 }
 EXPORT_SYMBOL_GPL(of_pci_find_child_device);
+
+/**
+ * of_pci_get_devfn() - Get device and function numbers for a device node
+ * @np: device node
+ *
+ * Parses a standard 5-cell PCI resource and returns an 8-bit value that can
+ * be passed to the PCI_SLOT() and PCI_FUNC() macros to extract the device
+ * and function numbers respectively. On error a negative error code is
+ * returned.
+ */
+int of_pci_get_devfn(struct device_node *np)
+{
+   unsigned int size;
+   const __be32 *reg;
+
+   reg = of_get_property(np, "reg", );
+
+   if (!reg || size < 5 * sizeof(__be32))
+   return -EINVAL;
+
+   return (be32_to_cpup(reg) >> 8) & 0xff;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_devfn);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index bb115de..91ec484 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -10,5 +10,6 @@ int of_irq_map_pci(const struct pci_dev *pdev, struct of_irq 
*out_irq);
 struct device_node;
 struct device_node *of_pci_find_child_device(struct device_node *parent,
 unsigned int devfn);
+int of_pci_get_devfn(struct device_node *np);
 
 #endif
-- 
1.8.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 01/12] of/pci: Provide support for parsing PCI DT ranges property

[Thierry Reding]

From: Andrew Murray 

This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host 
bridge
drivers and mitigate against further duplication of DT parsing code.

This patch can be used in the following way:

struct of_pci_range_parser parser;
struct of_pci_range range;

if (of_pci_range_parser(, np))
; //no ranges property

for_each_of_pci_range(, ) {

/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags

alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(, np, );
*/
}

Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).

The modifications to microblaze, mips and powerpc have not been tested.

Signed-off-by: Andrew Murray 
Signed-off-by: Liviu Dudau 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Thierry Reding 
---
 arch/microblaze/pci/pci-common.c | 110 ++-
 arch/mips/pci/pci.c  |  50 ++
 arch/powerpc/kernel/pci-common.c |  99 ---
 drivers/of/address.c |  63 ++
 include/linux/of_address.h   |  42 +++
 5 files changed, 194 insertions(+), 170 deletions(-)

diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index bdb8ea1..11dd9ac 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -657,67 +657,43 @@ void pci_resource_to_user(const struct pci_dev *dev, int 
bar,
 void pci_process_bridge_OF_ranges(struct pci_controller *hose,
  struct device_node *dev, int primary)
 {
-   const u32 *ranges;
-   int rlen;
-   int pna = of_n_addr_cells(dev);
-   int np = pna + 5;
int memno = 0, isa_hole = -1;
-   u32 pci_space;
-   unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
unsigned long long isa_mb = 0;
struct resource *res;
+   struct of_pci_range range;
+   struct of_pci_range_parser parser;
+   u32 res_type;
 
pr_info("PCI host bridge %s %s ranges:\n",
   dev->full_name, primary ? "(primary)" : "");
 
-   /* Get ranges property */
-   ranges = of_get_property(dev, "ranges", );
-   if (ranges == NULL)
+   /* Check for ranges property */
+   if (of_pci_range_parser(, dev))
return;
 
-   /* Parse it */
pr_debug("Parsing ranges property...\n");
-   while ((rlen -= np * 4) >= 0) {
+   for_each_of_pci_range(, ) {
/* Read next ranges element */
-   pci_space = ranges[0];
-   pci_addr = of_read_number(ranges + 1, 2);
-   cpu_addr = of_translate_address(dev, ranges + 3);
-   size = of_read_number(ranges + pna + 3, 2);
-
-   pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-   pci_space, pci_addr);
-   pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
-   cpu_addr, size);
-
-   ranges += np;
+   pr_debug("pci_space: 0x%08x pci_addr: 0x%016llx ",
+   range.pci_space, range.pci_addr);
+   pr_debug("cpu_addr: 0x%016llx size: 0x%016llx\n",
+   range.cpu_addr, range.size);
 
/* If we failed translation or got a zero-sized region
 * (some FW try to feed us with non sensical zero sized regions
 * such as power3 which look like some kind of attempt
 * at exposing the VGA memory hole)
 */
-   if (cpu_addr == OF_BAD_ADDR || size == 0)
+   if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
continue;
 
-   /* Now consume following elements while they are contiguous */
-   for (; rlen >= np * sizeof(u32);
-ranges += np, rlen -= np * 4) {
-   if (ranges[0] != pci_space)
-   break;
-   pci_next = of_read_number(ranges + 1, 2);
-   cpu_next = of_translate_address(dev, ranges + 3);
-   if (pci_next != pci_addr + size ||
-   cpu_next != cpu_addr + size)
-   break;
-   size += 

Re: systemtap broken by removal of register_timer_hook

[Frank Ch. Eigler]

Hi -

On Wed, Apr 03, 2013 at 02:49:53PM +0200, Frederic Weisbecker wrote:

> Sounds good, would you like to propose a version? We are also
> interested in a timer tick event tracepoint for dynticks debugging.

How about this?

Author: Frank Ch. Eigler 
Date:   Wed Apr 3 10:35:21 2013 -0400

profiling: add profile_tick tracepoint

Commit ba6fdda4 removed the timer_hook mechanism for modules to listen
to profiling timer ticks (without having to set up more complicated
perf mechanisms).  To reduce the impact on out-of-tree users, a
TRACE_EVENT-flavoured tracepoint is added in its place.  Tested with
perf and systemtap.

Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Mel Gorman 
Signed-off-by: Frank Ch. Eigler 

diff --git a/include/trace/events/profile.h b/include/trace/events/profile.h
new file mode 100644
index 000..b48b6fe
--- /dev/null
+++ b/include/trace/events/profile.h
@@ -0,0 +1,35 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM profile
+
+#if !defined(_TRACE_PROFILE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_PROFILE_H
+
+#include 
+
+
+struct pt_regs;
+
+/**
+ * profile_tick - called when the profiling timer ticks
+ * @regs:  pointer to struct pt_regs*
+ */
+
+TRACE_EVENT(profile_tick,
+   TP_PROTO(int type, struct pt_regs *regs),
+   TP_ARGS(type, regs),
+   TP_STRUCT__entry(
+   __field( int,   type)
+   __field( struct pt_regs*,   regs)
+   ),
+   TP_fast_assign(
+   __entry->type   = type;
+   __entry->regs   = regs;
+   ),
+   TP_printk("type=%d regs=%p", __entry->type, __entry->regs)
+);
+
+
+#endif /*  _TRACE_PROFILE_H */
+
+/* This part must be outside protection */
+#include 
diff --git a/kernel/profile.c b/kernel/profile.c
index dc3384e..d61f921 100644
--- a/kernel/profile.c
+++ b/kernel/profile.c
@@ -29,6 +29,9 @@
 #include 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include 
+
 struct profile_hit {
u32 pc, hits;
 };
@@ -414,6 +417,8 @@ void profile_tick(int type)
 {
struct pt_regs *regs = get_irq_regs();
 
+   trace_profile_tick(type, regs);
+
if (!user_mode(regs) && prof_cpu_mask != NULL &&
cpumask_test_cpu(smp_processor_id(), prof_cpu_mask))
profile_hit(type, (void *)profile_pc(regs));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 01/14] clk: tegra: provide dummy cpu car ops

[Peter De Schrijver]

tegra_boot_secondary() relies on some of the car ops. This means having an
uninitialized tegra_cpu_car_ops will lead to an early boot panic.
Providing a dummy struct avoids this and makes adding Tegra114 clock support
in a bisectable way a lot easier.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/clk/tegra/clk.c b/drivers/clk/tegra/clk.c
index 4a61d15..70b7a47 100644
--- a/drivers/clk/tegra/clk.c
+++ b/drivers/clk/tegra/clk.c
@@ -22,7 +22,8 @@
 #include "clk.h"
 
 /* Global data of Tegra CPU CAR ops */
-struct tegra_cpu_car_ops *tegra_cpu_car_ops;
+static struct tegra_cpu_car_ops dummy_car_ops;
+struct tegra_cpu_car_ops *tegra_cpu_car_ops = _car_ops;
 
 void __init tegra_init_dup_clks(struct tegra_clk_duplicate *dup_list,
struct clk *clks[], int clk_max)
-- 
1.7.7.rc0.72.g4b5ea.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 00/14] Tegra114 clockframework

[Peter De Schrijver]

This is the nineth version of the Tegra114 clockframework. It is based on the
next-20130320-fixed branch of
git://nv-tegra.nvidia.com/user/swarren/linux-2.6.git,
http://patchwork.ozlabs.org/patch/229972/ and
http://patchwork.ozlabs.org/patch/229978/ and
http://patchwork.ozlabs.org/patch/233415/

It has been boottested on Dalmore.

Changes from v8:

* Added pdiv table for PLLU
* Fixed clock initialization for audio

Changes from v7:

* Fixed dummy operations
* Removed some duplicates from the binding document
* Fixed tegra114_clk enum to be in line with the binding document
* Removed __initdata from tegra_periph_clk_list and
  tegra_periph_nodiv_clk_list
* Mark csite clock as CLK_IGNORE_UNUSED
* Fixed mux mask for disp1 and disp2
* Fixed initializations for PLLX, PLLC, PLLC2 and PLCC3
* Converted clk_pll_wait_for_lock() to use a mask instead of a single bit
* added TEGRA_PLL_HAS_LOCK_ENABLE flag

Changes from v6:

* Remove clock-frequency from DT serial nodes
* Remove useless 'cpu' clock from binding documentation
* Use HW gate control for PLLU divided outputs
* Fix clock ID for 'd_audio' clock
* Add dummy cpu car ops to ease making a bisectable series

Changes from v5:

* Add initialization code for PLLC
* Remove some unnecessary clocks
* Fix bug in PLL locking refactoring
* Add super clocks
* Remove most calls to clk_register_clkdev() for the peripheral clocks

Changes from v4:

* Split the new PLL types patch into smaller patches
* Fix some bugs in the PLL patches

Changes from v3:

* Merge with for-next branch
* Provide empty tegra_cpu_car_ops to make SMP boot not crash

Changes from v2:

* Added missing PLLs
* Added bindings to tegra114.dtsi
* Moved the table patch for clk-mux.c to 'clk: add table lookup to mux'
* Bugfixes

Changes from v1:

* Remove SATA and PCIe clocks. They don't appear in the internal TRM, so I
  assume they don't exist.
* Rebase on top of Hiroshi's latest Tegra114 patches
* More generic mux code. This is necessary for the AHUB and DAM clocks.


Peter De Schrijver (14):
  clk: tegra: provide dummy cpu car ops
  clk: tegra: Refactor PLL programming code
  clk: tegra: Add TEGRA_PLL_BYPASS flag
  clk: tegra: introduce TEGRA_PLL_HAS_LOCK_ENABLE
  clk: tegra: Add PLL post divider table
  clk: tegra: move from a lock bit idx to a lock mask
  clk: tegra: Add new fields and PLL types for Tegra114
  clk: tegra: Add flags to tegra_clk_periph()
  clk: tegra: Workaround for Tegra114 MSENC problem
  ARM: tegra: Define Tegra114 CAR binding
  clk: tegra: Implement clocks for Tegra114
  clk: tegra: devicetree match for nvidia,tegra114-car
  ARM: dt: Add references to tegra_car clocks
  clk: tegra: Remove forced clk_enable of uartd

 .../bindings/clock/nvidia,tegra114-car.txt |  317 +++
 arch/arm/boot/dts/tegra114-dalmore.dts |1 -
 arch/arm/boot/dts/tegra114-pluto.dts   |1 -
 arch/arm/boot/dts/tegra114.dtsi|8 +-
 drivers/clk/tegra/Makefile |1 +
 drivers/clk/tegra/clk-periph-gate.c|9 +
 drivers/clk/tegra/clk-periph.c |   11 +-
 drivers/clk/tegra/clk-pll.c| 1194 ++--
 drivers/clk/tegra/clk-tegra114.c   | 2085 
 drivers/clk/tegra/clk-tegra20.c|  173 +-
 drivers/clk/tegra/clk-tegra30.c|  265 ++--
 drivers/clk/tegra/clk.c|4 +-
 drivers/clk/tegra/clk.h|   95 +-
 13 files changed, 3805 insertions(+), 359 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
 create mode 100644 drivers/clk/tegra/clk-tegra114.c

-- 
1.7.7.rc0.72.g4b5ea.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm: Make snapshotting pages for stable writes a per-bio operation

[Jan Kara]

On Wed 03-04-13 15:20:19, Mel Gorman wrote:
> On Tue, Apr 02, 2013 at 10:01:43AM -0700, Darrick J. Wong wrote:
> > Hi,
> > 
> > A couple of weeks have gone by without further comments about this patch.
> > 
> > Are you interested in the minor cleanups and added comments, or is the v2 
> > patch
> > in -next good enough?
> > 
> > Apparently Mel Gorman's interested in this patchset too.  Mel: Most of 
> > stable
> > pages part 2 are already in upstream for 3.9... except this piece.  Are you
> > interested in having this piece in 3.9 also?  Or is 3.10 good enough for
> > everyone?
> > 
> 
> My understanding is that it only affects ARM and DEBUG_VM so there is a
> relatively small chance of this generating spurious bug reports.  However,
> 3.9 is still far enough away that I see no good reason to delay this patch
> until 3.10 either.
  No, actually with direct IO, anything that needs stable pages is going to
blow up quickly because pages attached to bio needn't be from page cache. So
I think it should better make it into 3.9.

Honza
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/11] usb: phy: Add APIs for runtime power management

[Vivek Gautam]

On Wed, Apr 3, 2013 at 7:48 PM, Felipe Balbi  wrote:
> Hi,
>
> On Wed, Apr 03, 2013 at 07:40:44PM +0530, Vivek Gautam wrote:
>> >> > >> >> +static inline void usb_phy_autopm_enable(struct usb_phy *x)
>> >> > >> >> +{
>> >> > >> >> +   if (!x || !x->dev) {
>> >> > >> >> +   dev_err(x->dev, "no PHY or attached device 
>> >> > >> >> available\n");
>> >> > >> >> +   return;
>> >> > >> >> +   }
>> >> > >> >> +
>> >> > >> >> +   pm_runtime_enable(x->dev);
>> >> > >> >> +}
>> >> > >> >
>> >> > >> >
>> >> > >> > IMO we need not have wrapper APIs for runtime_enable and 
>> >> > >> > runtime_disable
>> >> > >> > here. Generally runtime_enable and runtime_disable is done in 
>> >> > >> > probe and
>> >> > >> > remove of a driver respectively. So it's better to leave the
>> >> > >> > runtime_enable/runtime_disable to be done in *phy provider* driver 
>> >> > >> > than
>> >> > >> > having an API for it to be done by *phy user* driver. Felipe, what 
>> >> > >> > do you
>> >> > >> > think?
>> >> > >>
>> >> > >> Thanks!!
>> >> > >> That's very true, runtime_enable() and runtime_disable() calls are 
>> >> > >> made by
>> >> > >> *phy_provider* only. But a querry here.
>> >> > >> Wouldn't in any case a PHY consumer might want to disable runtime_pm 
>> >> > >> on PHY ?
>> >> > >> Say, when consumer failed to suspend the PHY properly
>> >> > >> (*put_sync(phy->dev)* fails), how much sure is the consumer about the
>> >> > >> state of PHY ?
>> >> > >
>> >> > > no no, wait a minute. We might not want to enable runtime pm for the 
>> >> > > PHY
>> >> > > until the UDC says it can handle runtime pm, no ? I guess this makes a
>> >> > > bit of sense (at least in my head :-p).
>> >> > >
>> >> > > Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
>> >> > > enabled... Does it make sense to leave that control to the USB
>> >> > > controller drivers ?
>> >> > >
>> >> > > I'm open for suggestions
>> >> >
>> >> > Of course unless the PHY consumer can handle runtime PM for PHY,
>> >> > PHY should not ideally be going into runtime_suspend.
>> >> >
>> >> > Actually trying out few things, here are my observations
>> >> >
>> >> > Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
>> >> > But a device detection wakes up DWC3 controller, and if i don't wake
>> >> > up PHY (using get_sync(phy->dev)) here
>> >> > in runtime_resume() callback of DWC3, i don't get PHY back in active 
>> >> > state.
>> >> > So it becomes the duty of DWC3 controller to handle PHY's sleep and 
>> >> > wake-up.
>> >> > Thereby it becomes logical that DWC3 controller has the right to
>> >> > enable runtime_pm
>> >> > of PHY.
>> >> >
>> >> > But there's a catch here. if there are multiple consumers of PHY (like
>> >> > USB2 type PHY can
>> >> > have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in 
>> >> > that case,
>> >> > only one of the consumer can enable runtime_pm on PHY. So who decides 
>> >> > this.
>> >> >
>> >> > Aargh!! lot of confusion here :-(
>> >>
>> >>
>> >> hmmm, maybe add a flag to struct usb_phy and check it on
>> >> usb_phy_autopm_enable() ??
>> >>
>> >> How does usbcore handle it ? They request class drivers to pass
>> >> supports_autosuspend, but while we should have a similar flag, that's
>> >> not enough. We also need a flag to tell us when pm_runtime has already
>> >> been enabled.
>>
>> True
>>
>> >>
>> >> So how about:
>> >>
>> >> usb_phy_autopm_enable()
>> >> {
>> >>   if (!phy->suports_autosuspend)
>> >>   return -ENOSYS;
>> >>
>> >>   if (phy->autosuspend_enabled)
>> >>   return 0;
>> >>
>> >>   phy->autosuspend_enabled = true;
>> >>   return pm_runtime_enable(phy->dev);
>> >> }
>> >>
>> >> ???
>>
>> Great
>>
>> >
>> > and of course I missed the fact that pm_runtime_enable returns nothing
>> > :-) But you got my point.
>>
>> Yea, this is a way around this. :-)
>>
>> Just one more query :-)
>>
>> Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
>> it will try to go into suspend state and thereby call runtime_suspend(), if 
>> any.
>> And PHY will come to active state only when its consumer wakes it up,
>> and this consumer is operational
>> only when its related PHY is in fully functional state.
>> So do we have a situation in which this PHY goes into low power state
>> in its runtime_suspend(),
>> resulting in non-detection of devices on further attach (since PHY is
>> in low power state) ?
>>
>> Will the controller (like EHCI/OHCI) be functional now ?
>
> ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(),
> right ? (so does DWC3 :-)

Yes ofcourse.
So PHYs (in their runtime_suspend) should not be pulled into a state
wherein even the controllers become in-operational.
Thereby no attach-detection, and controller doesn't wake up to be able
to usb_phy_autopm_get_sync()

Sorry for so much noise, i am acting like slow study ;-)

>
> --
> balbi



-- 
Thanks & Regards
Vivek
--
To 

Re: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out

[Theodore Ts'o]

On Wed, Apr 03, 2013 at 10:34:06AM -0400, Eric Whitney wrote:
> 
> The TI OMAP4 processor on my Pandaboard test system is little endian.

Ah... so basically, we need to find a test platform which allows us to
boot arbitrary kernels and allows us to have root access (which means
it's unlikely we'll be able to do this via remote access) and which
doesn't have exotic power requirements (which as far as I know rules
out pSeries and zSeries systems) 

It would also be nice if we could run tests in finite time, which
probably rules out the Hercules emulator (it runs at one-tenth zSeries
processor speeds, which doesn't win speed competitions by default, and
I suspect their storage speeds are even worse).

Anyone else have any suggestions?  Or anyone willing to help us run
ext4 regression tests on the ext4 dev tree, so we can find these
problems before we merge into mainline?

Thanks,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ext4: fix a big-endian bug when an extent is zeroed out

[Eric Whitney]

* Theodore Ts'o :
> On Wed, Apr 03, 2013 at 06:22:04PM +0800, Zheng Liu wrote:
> > Subject: [PATCH] ext4: fix a big-endian bug when an extent is zeroed out
> > 
> > From: Zheng Liu 
> > 
> > When an extent was zeroed out, we forgot to do convert from cpu to le16.
> > It could make us hit a BUG_ON when we try to write dirty pages out.  So
> > fix it.
> > 
> > Signed-off-by: Zheng Liu 
> 
> Thanks for finding this!  I think we should push this to Linus right
> away, and not wait for the next merge window.  The bug has been here
> for a long time, but it was unmasked by the fact that we unbroke
> extent zeroing in 3.9-rcX.
> 
> I have two big questions.  (1) Shouldn't Eric Whitney have picked this
> up with his ARM pandaboard testing, since IIRC it's big-endian as
> well?  If not, is there something we can do to improve our testing wrt
> to big-endian systems?


The TI OMAP4 processor on my Pandaboard test system is little endian.

Eric


> 
> And (2) does it make sense to have an inline function
> ext4_ext_set_len(len)?  It might save some lines of code, but more
> importantly, it might make it less likely that we will overlook this
> sort of bug in the future.
> 
>   - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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 v2] drivers/block/xen-blkback: preq.dev is used without initialized

[Jan Beulich]

>>> On 03.04.13 at 15:56, William Dauchy  wrote:
> On Wed, Apr 3, 2013 at 3:42 PM, Jan Beulich  wrote:
>> ChangeLog-3.8.3 for example has
> 
> oh sorry, you are right. I wasn't looking is the 3.8.x branch.
> The thing is, the revert seems present only in 3.8.x branch. For
> example in 3.4.x the last patch is still 01c681d
> Should we consider this normal or is it a mistake?

I think it is a mistake, but ultimately it's Konrad's call.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 1/6] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 03 April 2013 07:57 PM, Felipe Balbi wrote:

hi,

On Wed, Apr 03, 2013 at 07:48:42PM +0530, Kishon Vijay Abraham I wrote:

+struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
+{
+   return phy;
+}
+EXPORT_SYMBOL_GPL(of_phy_xlate);


so you get a PHY and just return it ? What gives ?? (maybe I skipped
some of the discussion...)


hmm.. this is for the common case where the PHY provider implements
only one PHY. And both phy provider and phy_instance is represented
by struct phy *.

For the case where PHY provider implements multiple PHYs (here it
will have a single dt node), the PHY provider will implement it's own
version of of_xlate that takes *of_phandle_args* as argument and
finds the appropriate PHY.


got it.


+struct phy *of_phy_get(struct device *dev, int index)
+{
+   int ret;
+   struct phy *phy = NULL;
+   struct phy_bind *phy_map = NULL;
+   struct of_phandle_args args;
+   struct device_node *node;
+
+   if (!dev->of_node) {
+   dev_dbg(dev, "device does not have a device node entry\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
+   index, );
+   if (ret) {
+   dev_dbg(dev, "failed to get phy in %s node\n",
+   dev->of_node->full_name);
+   return ERR_PTR(-ENODEV);
+   }
+
+   phy = of_phy_lookup(args.np);
+   if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
+   phy = ERR_PTR(-EPROBE_DEFER);
+   goto err0;
+   }
+
+   phy = phy->ops->of_xlate(phy, );


alright, so of_xlate() is optional, am I right ? How about not


Not really. of_xlate is mandatory (it's even checked in phy_create).
Either the PHY provider can implement it's own version or use the
implementation above (by filling the function pointer).


alright.


implementing the above and have a check for of_xlate() being a valid
pointer here ?


Having the way it is actually mandates the PHY providers to always
provide of_xlate which IMO is better since some PHY providers wont
accidentally be using the default implementation.


ok cool, thanks for clarifying.


+   ret = -EINVAL;
+   goto err0;
+   }
+
+   if (!phy_class)
+   phy_core_init();


why don't you setup the class on module_init ? Then this would be a
terrible error condition here :-)


This is for the case where the PHY driver gets loaded before the PHY
framework. I could have returned EPROBE_DEFER here instead I thought
will have it this way.


looks a bit weird IMO. Is it really possible for PHY to load before ?


yeah. it actually happened when I tried with beagle and had all the 
modules as built-in. Because twl4030 has subsys_initcall(), it loads 
before PHY framework.


Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-3.9.0-rc1+: Output from "make kernelrelease"contains incorrect data

[Michal Marek]

On 1.4.2013 11:28, Chris Clayton wrote:
> Ping!
> 
> This is still happening with 3.9-rc5.
> 
> [chris:~/kernel/linux]$ make bzImage
> ...
> Kernel: arch/x86/boot/bzImage is ready  (#14)
> [chris:~/kernel/linux]$ make kernelrelease
> scripts/kconfig/conf --silentoldconfig Kconfig
> 3.9.0-rc5
> [chris:~/kernel/linux]$ make kernelrelease
> 3.9.0-rc5

You need to run make -s kernelrelease.

Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 1/6] drivers: phy: add generic PHY framework

[Felipe Balbi]

hi,

On Wed, Apr 03, 2013 at 07:48:42PM +0530, Kishon Vijay Abraham I wrote:
> >>+struct phy *of_phy_xlate(struct phy *phy, struct of_phandle_args *args)
> >>+{
> >>+   return phy;
> >>+}
> >>+EXPORT_SYMBOL_GPL(of_phy_xlate);
> >
> >so you get a PHY and just return it ? What gives ?? (maybe I skipped
> >some of the discussion...)
> 
> hmm.. this is for the common case where the PHY provider implements
> only one PHY. And both phy provider and phy_instance is represented
> by struct phy *.
> 
> For the case where PHY provider implements multiple PHYs (here it
> will have a single dt node), the PHY provider will implement it's own
> version of of_xlate that takes *of_phandle_args* as argument and
> finds the appropriate PHY.

got it.

> >>+struct phy *of_phy_get(struct device *dev, int index)
> >>+{
> >>+   int ret;
> >>+   struct phy *phy = NULL;
> >>+   struct phy_bind *phy_map = NULL;
> >>+   struct of_phandle_args args;
> >>+   struct device_node *node;
> >>+
> >>+   if (!dev->of_node) {
> >>+   dev_dbg(dev, "device does not have a device node entry\n");
> >>+   return ERR_PTR(-EINVAL);
> >>+   }
> >>+
> >>+   ret = of_parse_phandle_with_args(dev->of_node, "phys", "#phy-cells",
> >>+   index, );
> >>+   if (ret) {
> >>+   dev_dbg(dev, "failed to get phy in %s node\n",
> >>+   dev->of_node->full_name);
> >>+   return ERR_PTR(-ENODEV);
> >>+   }
> >>+
> >>+   phy = of_phy_lookup(args.np);
> >>+   if (IS_ERR(phy) || !try_module_get(phy->ops->owner)) {
> >>+   phy = ERR_PTR(-EPROBE_DEFER);
> >>+   goto err0;
> >>+   }
> >>+
> >>+   phy = phy->ops->of_xlate(phy, );
> >
> >alright, so of_xlate() is optional, am I right ? How about not
> 
> Not really. of_xlate is mandatory (it's even checked in phy_create).
> Either the PHY provider can implement it's own version or use the
> implementation above (by filling the function pointer).

alright.

> >implementing the above and have a check for of_xlate() being a valid
> >pointer here ?
> 
> Having the way it is actually mandates the PHY providers to always
> provide of_xlate which IMO is better since some PHY providers wont
> accidentally be using the default implementation.

ok cool, thanks for clarifying.

> >>+   ret = -EINVAL;
> >>+   goto err0;
> >>+   }
> >>+
> >>+   if (!phy_class)
> >>+   phy_core_init();
> >
> >why don't you setup the class on module_init ? Then this would be a
> >terrible error condition here :-)
> 
> This is for the case where the PHY driver gets loaded before the PHY
> framework. I could have returned EPROBE_DEFER here instead I thought
> will have it this way.

looks a bit weird IMO. Is it really possible for PHY to load before ?
Since PHY driver uses symbols from phy-core, modprobe will make sure to
load drivers based on symbol dependency, right ?

> >>+static struct device_attribute phy_dev_attrs[] = {
> >>+   __ATTR(label, 0444, phy_name_show, NULL),
> >>+   __ATTR(phy_bind, 0444, phy_bind_show, NULL),
> >
> >you could expose a human-readable 'type' string. BTW, how are you using
> >type ? USB2/USB3/etc ? Have you considered our OMAP5 SerDes pair which
> 
> Actually not using *type* anywhere. Just used as an additional info
> about the PHY. It's actually not even enum. Maybe I can remove it
> completely.

makes sense.

> >are currently for USB3 and SATA (and could just as easily be used for
> >PCIe)
> 
> Yeah. Me and Balaji were planning to work on it for having a single
> driver to be used for all the above.

cool :-)

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 3/3] mtip32xx: Add debugfs entry device_status

[Asai Thambi S P]

This patch adds a new debugfs entry 'device_status' in
/sys/kernel/debug/rssd. The value of this entry shows
devices online and those in the process of removing.

Signed-off-by: Sam Bradshaw 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |  148 +++-
 drivers/block/mtip32xx/mtip32xx.h |   18 +++--
 2 files changed, 154 insertions(+), 12 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 7e1aeb3..03555ec 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -81,12 +81,17 @@
 /* Device instance number, incremented each time a device is probed. */
 static int instance;
 
+struct list_head online_list;
+struct list_head removing_list;
+spinlock_t dev_lock;
+
 /*
  * Global variable used to hold the major block device number
  * allocated in mtip_init().
  */
 static int mtip_major;
 static struct dentry *dfs_parent;
+static struct dentry *dfs_device_status;
 
 static u32 cpu_use[NR_CPUS];
 
@@ -2707,6 +2712,100 @@ static ssize_t mtip_hw_show_status(struct device *dev,
 
 static DEVICE_ATTR(status, S_IRUGO, mtip_hw_show_status, NULL);
 
+/* debugsfs entries */
+
+static ssize_t show_device_status(struct device_driver *drv, char *buf)
+{
+   int size = 0;
+   struct driver_data *dd, *tmp;
+   unsigned long flags;
+   char id_buf[42];
+   u16 status = 0;
+
+   spin_lock_irqsave(_lock, flags);
+   size += sprintf([size], "Devices Present:\n");
+   list_for_each_entry_safe(dd, tmp, _list, online_list) {
+   if (dd && dd->pdev) {
+   if (dd->port &&
+   dd->port->identify &&
+   dd->port->identify_valid) {
+   strlcpy(id_buf,
+   (char *) (dd->port->identify + 10), 21);
+   status = *(dd->port->identify + 141);
+   } else {
+   memset(id_buf, 0, 42);
+   status = 0;
+   }
+
+   if (dd->port &&
+   test_bit(MTIP_PF_REBUILD_BIT, >port->flags)) {
+   size += sprintf([size],
+   " device %s %s (ftl rebuild %d %%)\n",
+   dev_name(>pdev->dev),
+   id_buf,
+   status);
+   } else {
+   size += sprintf([size],
+   " device %s %s\n",
+   dev_name(>pdev->dev),
+   id_buf);
+   }
+   }
+   }
+
+   size += sprintf([size], "Devices Being Removed:\n");
+   list_for_each_entry_safe(dd, tmp, _list, remove_list) {
+   if (dd && dd->pdev) {
+   if (dd->port &&
+   dd->port->identify &&
+   dd->port->identify_valid) {
+   strlcpy(id_buf,
+   (char *) (dd->port->identify+10), 21);
+   status = *(dd->port->identify + 141);
+   } else {
+   memset(id_buf, 0, 42);
+   status = 0;
+   }
+
+   if (dd->port &&
+   test_bit(MTIP_PF_REBUILD_BIT, >port->flags)) {
+   size += sprintf([size],
+   " device %s %s (ftl rebuild %d %%)\n",
+   dev_name(>pdev->dev),
+   id_buf,
+   status);
+   } else {
+   size += sprintf([size],
+   " device %s %s\n",
+   dev_name(>pdev->dev),
+   id_buf);
+   }
+   }
+   }
+   spin_unlock_irqrestore(_lock, flags);
+
+   return size;
+}
+
+static ssize_t mtip_hw_read_device_status(struct file *f, char __user *ubuf,
+   size_t len, loff_t *offset)
+{
+   int size = *offset;
+   char buf[MTIP_DFS_MAX_BUF_SIZE];
+
+   if (!len || *offset)
+   return 0;
+
+   size += show_device_status(NULL, buf);
+
+   *offset = size <= len ? size : len;
+   size = copy_to_user(ubuf, buf, *offset);
+   if (size)
+   return -EFAULT;
+
+   return *offset;
+}
+
 static ssize_t mtip_hw_read_registers(struct file *f, char __user *ubuf,
  size_t len, loff_t *offset)
 {
@@ -2801,6 +2900,13 @@ 

[PATCH 2/3] mtip32xx: return 0 from pci probe in case of rebuild

[Asai Thambi S P]

Fix to return 0 from pci probe in case of rebuild. If not, pci consider
probe has failed, and crash during rmmod.

Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 5becdaa..7e1aeb3 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -4300,6 +4300,8 @@ static int mtip_pci_probe(struct pci_dev *pdev,
instance++;
if (rv != MTIP_FTL_REBUILD_MAGIC)
set_bit(MTIP_DDF_INIT_DONE_BIT, >dd_flag);
+   else
+   rv = 0; /* device in rebuild state, return 0 from probe */
goto done;
 
 block_initialize_err:
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH-mmotm] sh4: make the bios early console support depend on EARLY_PRINTK

[Paul Gortmaker]

The commit "early_printk: consolidate random copies of identical code"
introduces a build failure for the lboxre2_defconfig because arch/sh
unconditionally assumes that there will be an early_console struct
present that it can populate with bios routines to drive the
early printk support.

Making this whole block conditional on EARLY_PRINTK solves the
problem and gets rid of unused runtime code for when the feature
is disabled at the same time.

Reported-by: Geert Uytterhoeven 
Cc: Thomas Gleixner 
Cc: Andrew Morton 
Cc: Paul Mundt 
Signed-off-by: Paul Gortmaker 
---

Related mmotm patches:
   * early_printk-consolidate-random-copies-of-identical-code.patch
   * early_printk-consolidate-random-copies-of-identical-code-v3.patch
   * early_printk-consolidate-random-copies-of-identical-code-v3-fix.patch
   * include-linux-printkh-include-stdargh.patch
   
 arch/sh/kernel/sh_bios.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/sh/kernel/sh_bios.c b/arch/sh/kernel/sh_bios.c
index a5b51b9..fe584e5 100644
--- a/arch/sh/kernel/sh_bios.c
+++ b/arch/sh/kernel/sh_bios.c
@@ -104,6 +104,7 @@ void sh_bios_vbr_reload(void)
);
 }
 
+#ifdef CONFIG_EARLY_PRINTK
 /*
  * Print a string through the BIOS
  */
@@ -168,3 +169,4 @@ static int __init setup_early_printk(char *buf)
return 0;
 }
 early_param("earlyprintk", setup_early_printk);
+#endif
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] mtip32xx: recovery from command timeout

[Asai Thambi S P]

To recover from command timeouts, reset the device. In addition
to that improved timeout handling of PIO commands.

Signed-off-by: Sam Bradshaw 
Signed-off-by: Asai Thambi S P 
---
 drivers/block/mtip32xx/mtip32xx.c |  177 ++---
 1 files changed, 87 insertions(+), 90 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 11cc952..5becdaa 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -243,40 +243,31 @@ static inline void release_slot(struct mtip_port *port, 
int tag)
 /*
  * Reset the HBA (without sleeping)
  *
- * Just like hba_reset, except does not call sleep, so can be
- * run from interrupt/tasklet context.
- *
  * @dd Pointer to the driver data structure.
  *
  * return value
  * 0   The reset was successful.
  * -1  The HBA Reset bit did not clear.
  */
-static int hba_reset_nosleep(struct driver_data *dd)
+static int mtip_hba_reset(struct driver_data *dd)
 {
unsigned long timeout;
 
-   /* Chip quirk: quiesce any chip function */
-   mdelay(10);
-
/* Set the reset bit */
writel(HOST_RESET, dd->mmio + HOST_CTL);
 
/* Flush */
readl(dd->mmio + HOST_CTL);
 
-   /*
-* Wait 10ms then spin for up to 1 second
-* waiting for reset acknowledgement
-*/
-   timeout = jiffies + msecs_to_jiffies(1000);
-   mdelay(10);
-   while ((readl(dd->mmio + HOST_CTL) & HOST_RESET)
-&& time_before(jiffies, timeout))
-   mdelay(1);
+   /* Spin for up to 2 seconds, waiting for reset acknowledgement */
+   timeout = jiffies + msecs_to_jiffies(2000);
+   do {
+   mdelay(10);
+   if (test_bit(MTIP_DDF_REMOVE_PENDING_BIT, >dd_flag))
+   return -1;
 
-   if (test_bit(MTIP_DDF_REMOVE_PENDING_BIT, >dd_flag))
-   return -1;
+   } while ((readl(dd->mmio + HOST_CTL) & HOST_RESET)
+&& time_before(jiffies, timeout));
 
if (readl(dd->mmio + HOST_CTL) & HOST_RESET)
return -1;
@@ -481,7 +472,7 @@ static void mtip_restart_port(struct mtip_port *port)
dev_warn(>dd->pdev->dev,
"PxCMD.CR not clear, escalating reset\n");
 
-   if (hba_reset_nosleep(port->dd))
+   if (mtip_hba_reset(port->dd))
dev_err(>dd->pdev->dev,
"HBA reset escalation failed.\n");
 
@@ -527,6 +518,26 @@ static void mtip_restart_port(struct mtip_port *port)
 
 }
 
+static int mtip_device_reset(struct driver_data *dd)
+{
+   int rv = 0;
+
+   if (mtip_check_surprise_removal(dd->pdev))
+   return 0;
+
+   if (mtip_hba_reset(dd) < 0)
+   rv = -EFAULT;
+
+   mdelay(1);
+   mtip_init_port(dd->port);
+   mtip_start_port(dd->port);
+
+   /* Enable interrupts on the HBA. */
+   writel(readl(dd->mmio + HOST_CTL) | HOST_IRQ_EN,
+   dd->mmio + HOST_CTL);
+   return rv;
+}
+
 /*
  * Helper function for tag logging
  */
@@ -632,7 +643,7 @@ static void mtip_timeout_function(unsigned long int data)
if (cmdto_cnt) {
print_tags(port->dd, "timed out", tagaccum, cmdto_cnt);
if (!test_bit(MTIP_PF_IC_ACTIVE_BIT, >flags)) {
-   mtip_restart_port(port);
+   mtip_device_reset(port->dd);
wake_up_interruptible(>svc_wait);
}
clear_bit(MTIP_PF_EH_ACTIVE_BIT, >flags);
@@ -1283,11 +1294,11 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
int rv = 0, ready2go = 1;
struct mtip_cmd *int_cmd = >commands[MTIP_TAG_INTERNAL];
unsigned long to;
+   struct driver_data *dd = port->dd;
 
/* Make sure the buffer is 8 byte aligned. This is asic specific. */
if (buffer & 0x0007) {
-   dev_err(>dd->pdev->dev,
-   "SG buffer is not 8 byte aligned\n");
+   dev_err(>pdev->dev, "SG buffer is not 8 byte aligned\n");
return -EFAULT;
}
 
@@ -1300,23 +1311,21 @@ static int mtip_exec_internal_command(struct mtip_port 
*port,
mdelay(100);
} while (time_before(jiffies, to));
if (!ready2go) {
-   dev_warn(>dd->pdev->dev,
+   dev_warn(>pdev->dev,
"Internal cmd active. new cmd [%02X]\n", fis->command);
return -EBUSY;
}
set_bit(MTIP_PF_IC_ACTIVE_BIT, >flags);
port->ic_pause_timer = 0;
 
-   if (fis->command == ATA_CMD_SEC_ERASE_UNIT)
-   clear_bit(MTIP_PF_SE_ACTIVE_BIT, >flags);
-   else if (fis->command == ATA_CMD_DOWNLOAD_MICRO)
-   clear_bit(MTIP_PF_DM_ACTIVE_BIT, >flags);
+   clear_bit(MTIP_PF_SE_ACTIVE_BIT, >flags);
+   

Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples

[Stephane Eranian]

On Wed, Apr 3, 2013 at 4:14 PM, David Ahern  wrote:
> On 4/3/13 8:00 AM, Stephane Eranian wrote:
>>>
>>> What's the advantage of changing apps -- like the JIT compiler -- to emit
>>> perf based timestamps versus having perf emit existing timestamps? ie.,
>>> monotonic and realtime clocks already have vdso mappings for userspace
>>> with
>>> well known performance characteristics. Why not have perf convert its
>>> perf_clock timestamps into monotonic or realtime when dumping events?
>>>
>> Can monotonic timestamps be obtained from NMI context in the kernel?
>
>
> I don't understand the context of the question.
>
> I am not suggesting perf_clock be changed. I am working on correlating
> existing perf_clock timestamps to clocks typically used by apps (REALTIME
> and time-of-day but also applies to MONOTONIC).
>
But for that, you'd need to expose to users the correlation between
the two clocks.
And now you'd fixed two clock sources definitions not just one.

> You are wanting the reverse -- have apps emit perf_clock timestamps. I was
> just wondering what is the advantage of this approach?
>
Well, that's how I interpreted your question ;-<

If you could have perf_clock use monotonic then we would not have this
discussion.
The correlation would be trivial.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] mtip32xx: recovery improvement and fix for a crash

[Asai Thambi S P]

Hi Jens,

This patchset includes the following. It was generated against your 
for-3.9/drivers

* improved recovery for command timeout
* fix for a crash during rmmod
* add new debugfs entry 'device_status'


Asai Thambi S P (3):
  mtip32xx: recovery from command timeout
  mtip32xx: return 0 from pci probe in case of rebuild
  mtip32xx: Add debugfs entry device_status

 drivers/block/mtip32xx/mtip32xx.c |  327 ++---
 drivers/block/mtip32xx/mtip32xx.h |   18 ++-
 2 files changed, 243 insertions(+), 102 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] check regulator_enable() return value

[Greg KH]

On Wed, Apr 03, 2013 at 05:06:22PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Apr 03, 2013 at 04:02:24PM +0200, Fabio Baltieri wrote:
> > While testing your 'next' branch merged with today's next I got some new
> > warnings, caused by a recently introduced __must_check in:
> > 
> > c8801a8 regulator: core: Mark all get and enable calls as __must_check
> > 
> > These patches introduces a check for regulator_enable() return value in
> > all three affected USB phy drivers, and issue a dev_err() in case it
> > fails.
> > 
> > TWL4030 and TWL6030 patches has been build-tested only.
> 
> Sorry but I can't change my tree anymore, we can send these during
> v3.10-rc.

Really?  You are going to send me a tree that adds build warnings?

Please don't.

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 v3] mm: Make snapshotting pages for stable writes a per-bio operation

[Mel Gorman]

On Tue, Apr 02, 2013 at 10:01:43AM -0700, Darrick J. Wong wrote:
> Hi,
> 
> A couple of weeks have gone by without further comments about this patch.
> 
> Are you interested in the minor cleanups and added comments, or is the v2 
> patch
> in -next good enough?
> 
> Apparently Mel Gorman's interested in this patchset too.  Mel: Most of stable
> pages part 2 are already in upstream for 3.9... except this piece.  Are you
> interested in having this piece in 3.9 also?  Or is 3.10 good enough for
> everyone?
> 

My understanding is that it only affects ARM and DEBUG_VM so there is a
relatively small chance of this generating spurious bug reports.  However,
3.9 is still far enough away that I see no good reason to delay this patch
until 3.10 either.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 10/14] ARM: tegra: Define Tegra114 CAR binding

[Peter De Schrijver]

On Mon, Mar 25, 2013 at 12:15:47PM +0100, Prashant Gaikwad wrote:
> On Friday 22 March 2013 06:09 PM, Peter De Schrijver wrote:
> > The device tree binding models Tegra114 CAR (Clock And Reset) as a single
> > monolithic clock provider.
> >
> > Signed-off-by: Peter De Schrijver 
> > ---
> 
> 
> 
> > +  263  cclk_lp
> > +  264  dfll_ref
> > +  265  dfll_soc
> > +
> 
> Peter,
> 
> Please remove following clock IDs from binding.
> 
> > +Mux clocks
> > +

...
> > +  306  clk_out_1_mux

Is at least used by the init list. So we can't remove that?

Cheers,

Peter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 1/6] drivers: phy: add generic PHY framework

[Kishon Vijay Abraham I]

Hi,

On Wednesday 03 April 2013 07:12 PM, Felipe Balbi wrote:

On Wed, Apr 03, 2013 at 06:23:49PM +0530, Kishon Vijay Abraham I wrote:

The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
should have already called phy_bind with the binding information. The binding
information consists of phy's device name, phy user device name and an index.
The index is used when the same phy user binds to mulitple phys.

PHY drivers should create the PHY by passing phy_descriptor that has
describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
power_on, power_off.

The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for the sysfs entry is added
in Documentation/ABI/testing/sysfs-class-phy and the documentation for
dt binding is can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt

Signed-off-by: Kishon Vijay Abraham I 
---
  Documentation/ABI/testing/sysfs-class-phy  |   15 +
  .../devicetree/bindings/phy/phy-bindings.txt   |   67 +++
  Documentation/phy.txt  |  113 
  MAINTAINERS|7 +
  drivers/Kconfig|2 +
  drivers/Makefile   |2 +
  drivers/phy/Kconfig|   13 +
  drivers/phy/Makefile   |5 +
  drivers/phy/phy-core.c |  616 
  include/linux/phy/phy.h|  228 
  10 files changed, 1068 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-class-phy
  create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
  create mode 100644 Documentation/phy.txt
  create mode 100644 drivers/phy/Kconfig
  create mode 100644 drivers/phy/Makefile
  create mode 100644 drivers/phy/phy-core.c
  create mode 100644 include/linux/phy/phy.h

diff --git a/Documentation/ABI/testing/sysfs-class-phy 
b/Documentation/ABI/testing/sysfs-class-phy
new file mode 100644
index 000..b735467
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-phy
@@ -0,0 +1,15 @@
+What:  /sys/class/phy//label
+Date:  Apr 2013
+KernelVersion: 3.10
+Contact:   Kishon Vijay Abraham I 
+Description:
+   This is a read-only file for getting the label of the phy.
+
+What:  /sys/class/phy//phy_bind
+Date:  Apr 2013
+KernelVersion: 3.10
+Contact:   Kishon Vijay Abraham I 
+Description:
+   This is a read-only file for reading the phy binding
+   information. It contains the device name of the controller,
+   the index and the device name of the PHY in that order.
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..e7b246a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,67 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Required Properties:
+#phy-cells:Number of cells in a PHY specifier;  The meaning of all those
+   cells is defined by the binding for the phy node. The PHY
+   provider can use the values in cells to find the appropriate
+   PHY.
+
+For example:
+
+phys: phy {
+compatible = "xxx";
+reg = <...>;
+.
+.
+#phy-cells = <1>;
+.
+.
+};
+
+That node describes an IP block that implements 2 different PHYs. In order to
+differentiate between these 2 PHYs, an additonal specifier should be given
+while trying to get a reference to it.
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+compatible = "xxx";
+reg = ;
+.
+.
+phys = <_phy>, <_phy>;
+phy-names = "usb2phy", "usb3phy";
+.
+.
+};
+
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+compatible = "xxx";
+reg = ;
+.
+.
+phys = < 1>;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier "1" to
+differentiate between the two PHYs.
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000..7785ec0
--- /dev/null
+++ b/Documentation/phy.txt
@@ 

Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management

[Felipe Balbi]

Hi,

On Wed, Apr 03, 2013 at 07:40:44PM +0530, Vivek Gautam wrote:
> >> > >> >> +static inline void usb_phy_autopm_enable(struct usb_phy *x)
> >> > >> >> +{
> >> > >> >> +   if (!x || !x->dev) {
> >> > >> >> +   dev_err(x->dev, "no PHY or attached device 
> >> > >> >> available\n");
> >> > >> >> +   return;
> >> > >> >> +   }
> >> > >> >> +
> >> > >> >> +   pm_runtime_enable(x->dev);
> >> > >> >> +}
> >> > >> >
> >> > >> >
> >> > >> > IMO we need not have wrapper APIs for runtime_enable and 
> >> > >> > runtime_disable
> >> > >> > here. Generally runtime_enable and runtime_disable is done in probe 
> >> > >> > and
> >> > >> > remove of a driver respectively. So it's better to leave the
> >> > >> > runtime_enable/runtime_disable to be done in *phy provider* driver 
> >> > >> > than
> >> > >> > having an API for it to be done by *phy user* driver. Felipe, what 
> >> > >> > do you
> >> > >> > think?
> >> > >>
> >> > >> Thanks!!
> >> > >> That's very true, runtime_enable() and runtime_disable() calls are 
> >> > >> made by
> >> > >> *phy_provider* only. But a querry here.
> >> > >> Wouldn't in any case a PHY consumer might want to disable runtime_pm 
> >> > >> on PHY ?
> >> > >> Say, when consumer failed to suspend the PHY properly
> >> > >> (*put_sync(phy->dev)* fails), how much sure is the consumer about the
> >> > >> state of PHY ?
> >> > >
> >> > > no no, wait a minute. We might not want to enable runtime pm for the 
> >> > > PHY
> >> > > until the UDC says it can handle runtime pm, no ? I guess this makes a
> >> > > bit of sense (at least in my head :-p).
> >> > >
> >> > > Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
> >> > > enabled... Does it make sense to leave that control to the USB
> >> > > controller drivers ?
> >> > >
> >> > > I'm open for suggestions
> >> >
> >> > Of course unless the PHY consumer can handle runtime PM for PHY,
> >> > PHY should not ideally be going into runtime_suspend.
> >> >
> >> > Actually trying out few things, here are my observations
> >> >
> >> > Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
> >> > But a device detection wakes up DWC3 controller, and if i don't wake
> >> > up PHY (using get_sync(phy->dev)) here
> >> > in runtime_resume() callback of DWC3, i don't get PHY back in active 
> >> > state.
> >> > So it becomes the duty of DWC3 controller to handle PHY's sleep and 
> >> > wake-up.
> >> > Thereby it becomes logical that DWC3 controller has the right to
> >> > enable runtime_pm
> >> > of PHY.
> >> >
> >> > But there's a catch here. if there are multiple consumers of PHY (like
> >> > USB2 type PHY can
> >> > have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that 
> >> > case,
> >> > only one of the consumer can enable runtime_pm on PHY. So who decides 
> >> > this.
> >> >
> >> > Aargh!! lot of confusion here :-(
> >>
> >>
> >> hmmm, maybe add a flag to struct usb_phy and check it on
> >> usb_phy_autopm_enable() ??
> >>
> >> How does usbcore handle it ? They request class drivers to pass
> >> supports_autosuspend, but while we should have a similar flag, that's
> >> not enough. We also need a flag to tell us when pm_runtime has already
> >> been enabled.
> 
> True
> 
> >>
> >> So how about:
> >>
> >> usb_phy_autopm_enable()
> >> {
> >>   if (!phy->suports_autosuspend)
> >>   return -ENOSYS;
> >>
> >>   if (phy->autosuspend_enabled)
> >>   return 0;
> >>
> >>   phy->autosuspend_enabled = true;
> >>   return pm_runtime_enable(phy->dev);
> >> }
> >>
> >> ???
> 
> Great
> 
> >
> > and of course I missed the fact that pm_runtime_enable returns nothing
> > :-) But you got my point.
> 
> Yea, this is a way around this. :-)
> 
> Just one more query :-)
> 
> Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
> it will try to go into suspend state and thereby call runtime_suspend(), if 
> any.
> And PHY will come to active state only when its consumer wakes it up,
> and this consumer is operational
> only when its related PHY is in fully functional state.
> So do we have a situation in which this PHY goes into low power state
> in its runtime_suspend(),
> resulting in non-detection of devices on further attach (since PHY is
> in low power state) ?
> 
> Will the controller (like EHCI/OHCI) be functional now ?

ehci/ohci need to cope with that by calling usb_phy_autopm_get_sync(),
right ? (so does DWC3 :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples

[David Ahern]

On 4/3/13 8:00 AM, Stephane Eranian wrote:

What's the advantage of changing apps -- like the JIT compiler -- to emit
perf based timestamps versus having perf emit existing timestamps? ie.,
monotonic and realtime clocks already have vdso mappings for userspace with
well known performance characteristics. Why not have perf convert its
perf_clock timestamps into monotonic or realtime when dumping events?


Can monotonic timestamps be obtained from NMI context in the kernel?


I don't understand the context of the question.

I am not suggesting perf_clock be changed. I am working on correlating 
existing perf_clock timestamps to clocks typically used by apps 
(REALTIME and time-of-day but also applies to MONOTONIC).


You are wanting the reverse -- have apps emit perf_clock timestamps. I 
was just wondering what is the advantage of this approach?


David

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [PATCH] Gaurantee spinlocks implicit barrier for !PREEMPT_COUNT

[Vineet Gupta]

spinlocks built in a !PREEMPT_COUNT config don't have the compiler
barrier provided by preempt_* routines. This can break lot of code which
relies on barrier semantics.

This manifested as random crashes in timer code when stress testing
ARC Linux (3.9-rc3): !SMP && !PREEMPT_COUNT

Here's the exact sequence which caused this:
(0). tv1[x] <> t1 <---> t2
(1). mod_timer(t1) interrupted after it calls timer_pending()
(2). mod_timer(t2) completes
(3). mod_timer(t1) resumes but messes up the list.
(4). __runt_timers( ) uses bogus timer_list entry / crashes in
 timer->function

when mod_timer() races against itself, the spinlock rightly serializes
the tv1[] timer link list, however timer_pending() called outside the
spinlock accesses timer's link list element, cached in a register.
With low register pressure (and a deep register file), there's nothing
forcing gcc to reload the element across the spinlock, causing a stale
value in register in case of race - ensuing a list corruption.

And the ARcompact disassembly which shows the culprit generated code:

mod_timer:
push_s blink
mov_s r13,r0# timer, timer

..
## timer_pending( )
ld_s r3,[r13]   # <-- .entry.next LOADED
brne r3, 0, @.L163

.L163:
..
## spin_lock_irq( )
lr  r5, [status32]  # flags
bic r4, r5, 6   # temp, flags,
and.f 0, r5, 6  # flags,
flag.nz r4

## detach_if_pending( ) begins

tst_s r3,r3  <--
# timer_pending( ) checks timer->entry.next
# r3 is NOT reloaded by gcc, using stale value
beq.d @.L169
mov.eq r0,0

#  detach_timer( ): __list_del( )

ld r4,[r13,4]   # .entry.prev, D.31439
st r4,[r3,4]# .prev, D.31439

st r3,[r4]  # .next, D.30246

Signed-off-by: Vineet Gupta 
Reported-by: Christian Ruppert 
Cc: Thomas Gleixner 
Cc: Christian Ruppert 
Cc: Pierrick Hascoet 
Cc: Robert Love 
Cc: kpreempt-t...@lists.sourceforge.net
Cc: Frederic Weisbecker 
Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: linux-kernel@vger.kernel.org
---
 include/linux/preempt.h |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/include/linux/preempt.h b/include/linux/preempt.h
index 5a710b9..354d6e3 100644
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -93,14 +93,19 @@ do { \
 
 #else /* !CONFIG_PREEMPT_COUNT */
 
-#define preempt_disable()  do { } while (0)
-#define sched_preempt_enable_no_resched()  do { } while (0)
-#define preempt_enable_no_resched()do { } while (0)
-#define preempt_enable()   do { } while (0)
-
-#define preempt_disable_notrace()  do { } while (0)
-#define preempt_enable_no_resched_notrace()do { } while (0)
-#define preempt_enable_notrace()   do { } while (0)
+/*
+ * compiler barrier needed to ensure that spinlocks provide the barrier
+ * semantics despite !CONFIG_PREEMPT_COUNT.
+ * See commit log for actual bug which forced this change
+ */
+#define preempt_disable()  do { barrier(); } while (0)
+#define sched_preempt_enable_no_resched()  do { barrier(); } while (0)
+#define preempt_enable_no_resched()do { barrier(); } while (0)
+#define preempt_enable()   do { barrier(); } while (0)
+
+#define preempt_disable_notrace()  do { barrier(); } while (0)
+#define preempt_enable_no_resched_notrace()do { barrier(); } while (0)
+#define preempt_enable_notrace()   do { barrier(); } while (0)
 
 #endif /* CONFIG_PREEMPT_COUNT */
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] check regulator_enable() return value

[Fabio Baltieri]

Hi Felipe,

On Wed, Apr 03, 2013 at 05:06:22PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Apr 03, 2013 at 04:02:24PM +0200, Fabio Baltieri wrote:
> > While testing your 'next' branch merged with today's next I got some new
> > warnings, caused by a recently introduced __must_check in:
> > 
> > c8801a8 regulator: core: Mark all get and enable calls as __must_check
> > 
> > These patches introduces a check for regulator_enable() return value in
> > all three affected USB phy drivers, and issue a dev_err() in case it
> > fails.
> > 
> > TWL4030 and TWL6030 patches has been build-tested only.
> 
> Sorry but I can't change my tree anymore, we can send these during
> v3.10-rc.

Sure, I've no problem with that!

Thanks,
Fabio

-- 
Fabio Baltieri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/11] usb: phy: Add APIs for runtime power management

[Vivek Gautam]

Hi,


On Wed, Apr 3, 2013 at 7:26 PM, Felipe Balbi  wrote:
> Hi,
>
> On Wed, Apr 03, 2013 at 04:54:14PM +0300, Felipe Balbi wrote:
>> > >> >> +static inline void usb_phy_autopm_enable(struct usb_phy *x)
>> > >> >> +{
>> > >> >> +   if (!x || !x->dev) {
>> > >> >> +   dev_err(x->dev, "no PHY or attached device 
>> > >> >> available\n");
>> > >> >> +   return;
>> > >> >> +   }
>> > >> >> +
>> > >> >> +   pm_runtime_enable(x->dev);
>> > >> >> +}
>> > >> >
>> > >> >
>> > >> > IMO we need not have wrapper APIs for runtime_enable and 
>> > >> > runtime_disable
>> > >> > here. Generally runtime_enable and runtime_disable is done in probe 
>> > >> > and
>> > >> > remove of a driver respectively. So it's better to leave the
>> > >> > runtime_enable/runtime_disable to be done in *phy provider* driver 
>> > >> > than
>> > >> > having an API for it to be done by *phy user* driver. Felipe, what do 
>> > >> > you
>> > >> > think?
>> > >>
>> > >> Thanks!!
>> > >> That's very true, runtime_enable() and runtime_disable() calls are made 
>> > >> by
>> > >> *phy_provider* only. But a querry here.
>> > >> Wouldn't in any case a PHY consumer might want to disable runtime_pm on 
>> > >> PHY ?
>> > >> Say, when consumer failed to suspend the PHY properly
>> > >> (*put_sync(phy->dev)* fails), how much sure is the consumer about the
>> > >> state of PHY ?
>> > >
>> > > no no, wait a minute. We might not want to enable runtime pm for the PHY
>> > > until the UDC says it can handle runtime pm, no ? I guess this makes a
>> > > bit of sense (at least in my head :-p).
>> > >
>> > > Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
>> > > enabled... Does it make sense to leave that control to the USB
>> > > controller drivers ?
>> > >
>> > > I'm open for suggestions
>> >
>> > Of course unless the PHY consumer can handle runtime PM for PHY,
>> > PHY should not ideally be going into runtime_suspend.
>> >
>> > Actually trying out few things, here are my observations
>> >
>> > Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
>> > But a device detection wakes up DWC3 controller, and if i don't wake
>> > up PHY (using get_sync(phy->dev)) here
>> > in runtime_resume() callback of DWC3, i don't get PHY back in active state.
>> > So it becomes the duty of DWC3 controller to handle PHY's sleep and 
>> > wake-up.
>> > Thereby it becomes logical that DWC3 controller has the right to
>> > enable runtime_pm
>> > of PHY.
>> >
>> > But there's a catch here. if there are multiple consumers of PHY (like
>> > USB2 type PHY can
>> > have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that 
>> > case,
>> > only one of the consumer can enable runtime_pm on PHY. So who decides this.
>> >
>> > Aargh!! lot of confusion here :-(
>>
>>
>> hmmm, maybe add a flag to struct usb_phy and check it on
>> usb_phy_autopm_enable() ??
>>
>> How does usbcore handle it ? They request class drivers to pass
>> supports_autosuspend, but while we should have a similar flag, that's
>> not enough. We also need a flag to tell us when pm_runtime has already
>> been enabled.

True

>>
>> So how about:
>>
>> usb_phy_autopm_enable()
>> {
>>   if (!phy->suports_autosuspend)
>>   return -ENOSYS;
>>
>>   if (phy->autosuspend_enabled)
>>   return 0;
>>
>>   phy->autosuspend_enabled = true;
>>   return pm_runtime_enable(phy->dev);
>> }
>>
>> ???

Great

>
> and of course I missed the fact that pm_runtime_enable returns nothing
> :-) But you got my point.

Yea, this is a way around this. :-)

Just one more query :-)

Lets suppose DWC3 enables runtime_pm on USB 2 type phy,
it will try to go into suspend state and thereby call runtime_suspend(), if any.
And PHY will come to active state only when its consumer wakes it up,
and this consumer is operational
only when its related PHY is in fully functional state.
So do we have a situation in which this PHY goes into low power state
in its runtime_suspend(),
resulting in non-detection of devices on further attach (since PHY is
in low power state) ?

Will the controller (like EHCI/OHCI) be functional now ?



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: tegra: add suspend-resume support

[Linus Walleij]

On Thu, Mar 28, 2013 at 6:48 PM, Stephen Warren  wrote:

> Why can't we just use the device suspend/resume functions rather than
> global (syscore) suspend/resume functions? Presumably this is to ensure
> that all other drivers suspend first, then the pinctrl driver does, and
> the reverse for resume. Can't we rely on deferred probe to ensure that
> instead?
>
> To make that work, we might need every affected driver to define a dummy
> pinmux state in DT that references the pinctrl driver, to make sure they
> all get probed after the pinctrl driver.

Hm that reminds me of that policy change I suggested a while back to
do this instead of using hogs where possible.

It has the nice side-effect that when we inspect the debugfs info
all pins will be properly owned by respective consuming device.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] check regulator_enable() return value

[Felipe Balbi]

Hi,

On Wed, Apr 03, 2013 at 04:02:24PM +0200, Fabio Baltieri wrote:
> While testing your 'next' branch merged with today's next I got some new
> warnings, caused by a recently introduced __must_check in:
> 
> c8801a8 regulator: core: Mark all get and enable calls as __must_check
> 
> These patches introduces a check for regulator_enable() return value in
> all three affected USB phy drivers, and issue a dev_err() in case it
> fails.
> 
> TWL4030 and TWL6030 patches has been build-tested only.

Sorry but I can't change my tree anymore, we can send these during
v3.10-rc.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH v2 3/4] mac802154: Increase tx_buffer_len

[Alan Ott]

Increase the buffer length from 10 to 300 packets. Consider that traffic on
mac802154 devices will often be 6LoWPAN, and a full-length (1280 octet)
IPv6 packet will fragment into 15 6LoWPAN fragments (because the MTU of
IEEE 802.15.4 is 127).  A 300-packet queue is really 20 full-length IPv6
packets.

With a queue length of 10, an entire IPv6 packet was unable to get queued
at one time, causing fragments to be dropped, and making reassembly
impossible.

Signed-off-by: Alan Ott 
---
 net/mac802154/wpan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac802154/wpan.c b/net/mac802154/wpan.c
index 7d3f659..2ca2f4d 100644
--- a/net/mac802154/wpan.c
+++ b/net/mac802154/wpan.c
@@ -360,7 +360,7 @@ void mac802154_wpan_setup(struct net_device *dev)
dev->header_ops = _header_ops;
dev->needed_tailroom= 2; /* FCS */
dev->mtu= IEEE802154_MTU;
-   dev->tx_queue_len   = 10;
+   dev->tx_queue_len   = 300;
dev->type   = ARPHRD_IEEE802154;
dev->flags  = IFF_NOARP | IFF_BROADCAST;
dev->watchdog_timeo = 0;
-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] usb: phy: twl6030-usb: check regulator_enable return value

[Fabio Baltieri]

Since regulator_enable() is going to be marked as __must_check in the
next merge window, always check regulator_enable() return value and
print a warning if it fails.

Cc: Hema HK 
Signed-off-by: Fabio Baltieri 
---
 drivers/usb/phy/phy-twl6030-usb.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/phy/phy-twl6030-usb.c 
b/drivers/usb/phy/phy-twl6030-usb.c
index 8cd6cf4..e841474 100644
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -211,6 +211,7 @@ static irqreturn_t twl6030_usb_irq(int irq, void *_twl)
struct twl6030_usb *twl = _twl;
enum omap_musb_vbus_id_status status = OMAP_MUSB_UNKNOWN;
u8 vbus_state, hw_state;
+   int ret;
 
hw_state = twl6030_readb(twl, TWL6030_MODULE_ID0, STS_HW_CONDITIONS);
 
@@ -218,7 +219,10 @@ static irqreturn_t twl6030_usb_irq(int irq, void *_twl)
CONTROLLER_STAT1);
if (!(hw_state & STS_USB_ID)) {
if (vbus_state & VBUS_DET) {
-   regulator_enable(twl->usb3v3);
+   ret = regulator_enable(twl->usb3v3);
+   if (ret)
+   dev_err(twl->dev, "Failed to enable usb3v3\n");
+
twl->asleep = 1;
status = OMAP_MUSB_VBUS_VALID;
twl->linkstat = status;
@@ -245,12 +249,15 @@ static irqreturn_t twl6030_usbotg_irq(int irq, void *_twl)
struct twl6030_usb *twl = _twl;
enum omap_musb_vbus_id_status status = OMAP_MUSB_UNKNOWN;
u8 hw_state;
+   int ret;
 
hw_state = twl6030_readb(twl, TWL6030_MODULE_ID0, STS_HW_CONDITIONS);
 
if (hw_state & STS_USB_ID) {
+   ret = regulator_enable(twl->usb3v3);
+   if (ret)
+   dev_err(twl->dev, "Failed to enable usb3v3\n");
 
-   regulator_enable(twl->usb3v3);
twl->asleep = 1;
twl6030_writeb(twl, TWL_MODULE_USB, 0x1, USB_ID_INT_EN_HI_CLR);
twl6030_writeb(twl, TWL_MODULE_USB, 0x10, USB_ID_INT_EN_HI_SET);
-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] usb: phy: twl4030-usb: check regulator_enable return value

[Fabio Baltieri]

Since regulator_enable() is going to be marked as __must_check in the
next merge window, always check regulator_enable() return value and
print a warning if it fails.

Cc: Kalle Jokiniemi 
Signed-off-by: Fabio Baltieri 
---
 drivers/usb/phy/phy-twl4030-usb.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/phy-twl4030-usb.c 
b/drivers/usb/phy/phy-twl4030-usb.c
index 3f9858f..13e17ae 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -384,9 +384,17 @@ static void __twl4030_phy_power(struct twl4030_usb *twl, 
int on)
 
 static void twl4030_phy_power(struct twl4030_usb *twl, int on)
 {
+   int ret;
+
if (on) {
-   regulator_enable(twl->usb3v1);
-   regulator_enable(twl->usb1v8);
+   ret = regulator_enable(twl->usb3v1);
+   if (ret)
+   dev_err(twl->dev, "Failed to enable usb3v1\n");
+
+   ret = regulator_enable(twl->usb1v8);
+   if (ret)
+   dev_err(twl->dev, "Failed to enable usb1v8\n");
+
/*
 * Disabling usb3v1 regulator (= writing 0 to VUSB3V1_DEV_GRP
 * in twl4030) resets the VUSB_DEDICATED2 register. This reset
@@ -395,7 +403,11 @@ static void twl4030_phy_power(struct twl4030_usb *twl, int 
on)
 * is re-activated. This ensures that VUSB3V1 is really active.
 */
twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER, 0, VUSB_DEDICATED2);
-   regulator_enable(twl->usb1v5);
+
+   ret = regulator_enable(twl->usb1v5);
+   if (ret)
+   dev_err(twl->dev, "Failed to enable usb1v5\n");
+
__twl4030_phy_power(twl, 1);
twl4030_usb_write(twl, PHY_CLK_CTRL,
  twl4030_usb_read(twl, PHY_CLK_CTRL) |
-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] usb: phy: ab8500-usb: check regulator_enable return value

[Fabio Baltieri]

Since regulator_enable() is going to be marked as __must_check in the
next merge window, always check regulator_enable() return value and
print a warning if it fails.

Cc: Linus Walleij 
Signed-off-by: Fabio Baltieri 
---
 drivers/usb/phy/phy-ab8500-usb.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/phy-ab8500-usb.c b/drivers/usb/phy/phy-ab8500-usb.c
index b8115b0..ac27ed2 100644
--- a/drivers/usb/phy/phy-ab8500-usb.c
+++ b/drivers/usb/phy/phy-ab8500-usb.c
@@ -170,7 +170,9 @@ static void ab8500_usb_regulator_enable(struct ab8500_usb 
*ab)
 {
int ret, volt;
 
-   regulator_enable(ab->v_ape);
+   ret = regulator_enable(ab->v_ape);
+   if (ret)
+   dev_err(ab->dev, "Failed to enable v-ape\n");
 
if (!is_ab8500_2p0_or_earlier(ab->ab8500)) {
ab->saved_v_ulpi = regulator_get_voltage(ab->v_ulpi);
@@ -188,7 +190,9 @@ static void ab8500_usb_regulator_enable(struct ab8500_usb 
*ab)
ret);
}
 
-   regulator_enable(ab->v_ulpi);
+   ret = regulator_enable(ab->v_ulpi);
+   if (ret)
+   dev_err(ab->dev, "Failed to enable vddulpivio18\n");
 
if (!is_ab8500_2p0_or_earlier(ab->ab8500)) {
volt = regulator_get_voltage(ab->v_ulpi);
@@ -197,7 +201,9 @@ static void ab8500_usb_regulator_enable(struct ab8500_usb 
*ab)
volt);
}
 
-   regulator_enable(ab->v_musb);
+   ret = regulator_enable(ab->v_musb);
+   if (ret)
+   dev_err(ab->dev, "Failed to enable musb_1v8\n");
 }
 
 static void ab8500_usb_regulator_disable(struct ab8500_usb *ab)
-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm, x86: Do not zero hugetlbfs pages at boot. -v2

[Michal Hocko]

On Tue 02-04-13 21:43:44, Robin Holt wrote:
[...]
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index ca9a7c6..7683f6a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1185,7 +1185,7 @@ int __weak alloc_bootmem_huge_page(struct hstate *h)
>   while (nr_nodes) {
>   void *addr;
>  
> - addr = __alloc_bootmem_node_nopanic(
> + addr = __alloc_bootmem_node_nopanic_notzeroed(
>   NODE_DATA(hstate_next_node_to_alloc(h,
>   _states[N_MEMORY])),
>   huge_page_size(h), huge_page_size(h), 0);

Ohh, and powerpc seems to have its own opinion how to allocate huge
pages. See arch/powerpc/mm/hugetlbpage.c

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] check regulator_enable() return value

[Fabio Baltieri]

Hello Felipe,

While testing your 'next' branch merged with today's next I got some new
warnings, caused by a recently introduced __must_check in:

c8801a8 regulator: core: Mark all get and enable calls as __must_check

These patches introduces a check for regulator_enable() return value in
all three affected USB phy drivers, and issue a dev_err() in case it
fails.

TWL4030 and TWL6030 patches has been build-tested only.

Thanks,
Fabio


Fabio Baltieri (3):
  usb: phy: ab8500-usb: check regulator_enable return value
  usb: phy: twl4030-usb: check regulator_enable return value
  usb: phy: twl6030-usb: check regulator_enable return value

 drivers/usb/phy/phy-ab8500-usb.c  | 12 +---
 drivers/usb/phy/phy-twl4030-usb.c | 18 +++---
 drivers/usb/phy/phy-twl6030-usb.c | 11 +--
 3 files changed, 33 insertions(+), 8 deletions(-)

-- 
1.8.1.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] 802.15.4 and 6LoWPAN Buffering Fixes

[Alan Ott]

Version 2 of this patch series:

Differences from v1:

1. Patches previously numbered 5 and 6 were squashed (to become current
patch #4) at the request of Alexander Smirnov.

2. Current patch #2 had extraneous braces removed.

3. Current patch #1 was changed. It is now a patch to make mac802154 _not_
retry sending packets on failure. I believe this to be consistent with the
802.15.4 specification (Section 7.5.6.4.3 of IEEE 802.15.4-2006)

Alan Ott (4):
  mac802154: Do not try to resend failed packets
  mac802154: Use netif flow control
  mac802154: Increase tx_buffer_len
  6lowpan: handle dev_queue_xmit() error code properly

 net/ieee802154/6lowpan.c  |  4 ++--
 net/mac802154/mac802154.h |  2 --
 net/mac802154/tx.c| 26 --
 net/mac802154/wpan.c  |  2 +-
 4 files changed, 19 insertions(+), 15 deletions(-)

-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 34/77] xen/blkback: Dont trust the handle from the frontend.

[William Dauchy]

On Tue, Mar 12, 2013 at 11:10 PM, Greg Kroah-Hartman
 wrote:
>> > >> IOW I don't see why this got proposed for stable at all.
>> > >
>> > > So, you suggest to just drop this patch for v3.8.3, don't you?
>> >
>> > I do, yes. But I'd suggest to get Konrad to agree.
>>
>> Yes. Lets drop it.
>
> Now reverted, thanks.

Seems like still present in 3.4.x branch. Is that a mistake?

Regards,
--
William
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mac802154: Do not try to resend failed packets

[Alan Ott]

When ops->xmit() fails, drop the packet. Devices which support hardware
ack and retry (which include all devices currently supported by mainline),
will automatically retry sending the packet (in the hardware) up to 3
times, per the 802.15.4 spec.  There is no need, and it is incorrect to
try to do it in mac802154.

Signed-off-by: Alan Ott 
---
 net/mac802154/mac802154.h |  2 --
 net/mac802154/tx.c| 12 ++--
 2 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
index 21fa386..5c9e021 100644
--- a/net/mac802154/mac802154.h
+++ b/net/mac802154/mac802154.h
@@ -88,8 +88,6 @@ struct mac802154_sub_if_data {
 
 #define mac802154_to_priv(_hw) container_of(_hw, struct mac802154_priv, hw)
 
-#define MAC802154_MAX_XMIT_ATTEMPTS3
-
 #define MAC802154_CHAN_NONE(~(u8)0) /* No channel is assigned */
 
 extern struct ieee802154_reduced_mlme_ops mac802154_mlme_reduced;
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index 4e09d07..7264874 100644
--- a/net/mac802154/tx.c
+++ b/net/mac802154/tx.c
@@ -39,7 +39,6 @@ struct xmit_work {
struct mac802154_priv *priv;
u8 chan;
u8 page;
-   u8 xmit_attempts;
 };
 
 static void mac802154_xmit_worker(struct work_struct *work)
@@ -60,18 +59,12 @@ static void mac802154_xmit_worker(struct work_struct *work)
}
 
res = xw->priv->ops->xmit(>priv->hw, xw->skb);
+   if (res)
+   pr_debug("transmission failed\n");
 
 out:
mutex_unlock(>priv->phy->pib_lock);
 
-   if (res) {
-   if (xw->xmit_attempts++ < MAC802154_MAX_XMIT_ATTEMPTS) {
-   queue_work(xw->priv->dev_workqueue, >work);
-   return;
-   } else
-   pr_debug("transmission failed for %d times",
-MAC802154_MAX_XMIT_ATTEMPTS);
-   }
 
dev_kfree_skb(xw->skb);
 
@@ -114,7 +107,6 @@ netdev_tx_t mac802154_tx(struct mac802154_priv *priv, 
struct sk_buff *skb,
work->priv = priv;
work->page = page;
work->chan = chan;
-   work->xmit_attempts = 0;
 
queue_work(priv->dev_workqueue, >work);
 
-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] 6lowpan: handle dev_queue_xmit() error code properly

[Alan Ott]

dev_queue_xmit() will return a positive value if the packet could not be
queued, often because the real network device (in our case the mac802154
wpan device) has its queue stopped.  lowpan_xmit() should handle the
positive return code (for the debug statement) and return that value to
the higher layer so the higher layer will retry sending the packet.

Signed-off-by: Alan Ott 
---
 net/ieee802154/6lowpan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index e1b4580..55e1fd5 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1139,10 +1139,10 @@ static netdev_tx_t lowpan_xmit(struct sk_buff *skb, 
struct net_device *dev)
 error:
dev_kfree_skb(skb);
 out:
-   if (err < 0)
+   if (err)
pr_debug("ERROR: xmit failed\n");
 
-   return (err < 0 ? NETDEV_TX_BUSY : NETDEV_TX_OK);
+   return (err < 0) ? NET_XMIT_DROP : err;
 }
 
 static struct wpan_phy *lowpan_get_phy(const struct net_device *dev)
-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/4] mac802154: Use netif flow control

[Alan Ott]

Use netif_stop_queue() and netif_wake_queue() to control the flow of
packets to mac802154 devices.  Since many IEEE 802.15.4 devices have no
output buffer, and since the mac802154 xmit() function is designed to
block, netif_stop_queue() is called after each packet.

Signed-off-by: Alan Ott 
---
 net/mac802154/tx.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index 7264874..3fd3e07 100644
--- a/net/mac802154/tx.c
+++ b/net/mac802154/tx.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -44,6 +45,7 @@ struct xmit_work {
 static void mac802154_xmit_worker(struct work_struct *work)
 {
struct xmit_work *xw = container_of(work, struct xmit_work, work);
+   struct mac802154_sub_if_data *sdata;
int res;
 
mutex_lock(>priv->phy->pib_lock);
@@ -65,6 +67,11 @@ static void mac802154_xmit_worker(struct work_struct *work)
 out:
mutex_unlock(>priv->phy->pib_lock);
 
+   /* Restart the netif queue on each sub_if_data object. */
+   rcu_read_lock();
+   list_for_each_entry_rcu(sdata, >priv->slaves, list)
+   netif_wake_queue(sdata->dev);
+   rcu_read_unlock();
 
dev_kfree_skb(xw->skb);
 
@@ -75,6 +82,7 @@ netdev_tx_t mac802154_tx(struct mac802154_priv *priv, struct 
sk_buff *skb,
 u8 page, u8 chan)
 {
struct xmit_work *work;
+   struct mac802154_sub_if_data *sdata;
 
if (!(priv->phy->channels_supported[page] & (1 << chan))) {
WARN_ON(1);
@@ -102,6 +110,12 @@ netdev_tx_t mac802154_tx(struct mac802154_priv *priv, 
struct sk_buff *skb,
return NETDEV_TX_BUSY;
}
 
+   /* Stop the netif queue on each sub_if_data object. */
+   rcu_read_lock();
+   list_for_each_entry_rcu(sdata, >slaves, list)
+   netif_stop_queue(sdata->dev);
+   rcu_read_unlock();
+
INIT_WORK(>work, mac802154_xmit_worker);
work->skb = skb;
work->priv = priv;
-- 
1.7.11.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ 105/124] af_unix: dont send SCM_CREDENTIAL when dest socket is NULL

[Eric Dumazet]

On Wed, 2013-04-03 at 13:41 +0200, Sven Joachim wrote:
> On 2013-04-03 00:11 +0200, Greg Kroah-Hartman wrote:
> 
> > 3.8-stable review patch.  If anyone has any objections, please let me know.
> 
> I'm seeing several complaints from udevd at boot in both 3.8.6-rc1 and
> 3.9-rc5: "udevd[56]: sender uid=65534, message ignored".  Reverting the
> patch below on top of 3.8.6-rc1 fixes that.  I'm using udev version 175
> here, and 65534 is the uid of user "nobody".

And if you use a 3.1 kernel (before commit
16e5726269611b71c930054ffe9b858c1cea88eb) are you seeing this message ?

It might be a wrong sender (application bug or bad identity), and udevd
correctly discards the incoming message.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm, x86: Do not zero hugetlbfs pages at boot. -v2

[Michal Hocko]

On Tue 02-04-13 21:43:44, Robin Holt wrote:
[...]
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index 2b0bcb0..b2e4027 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -705,12 +705,16 @@ void * __init __alloc_bootmem(unsigned long size, 
> unsigned long align,
>  
>  void * __init ___alloc_bootmem_node_nopanic(pg_data_t *pgdat,
>   unsigned long size, unsigned long align,
> - unsigned long goal, unsigned long limit)
> + unsigned long goal, unsigned long limit,
> + int zeroed)
>  {
>   void *ptr;
>  
>   if (WARN_ON_ONCE(slab_is_available()))
> - return kzalloc(size, GFP_NOWAIT);
> + if (zeroed)
> + return kzalloc(size, GFP_NOWAIT);
> + else
> + return kmalloc(size, GFP_NOWAIT);
>  again:
>  
>   /* do not panic in alloc_bootmem_bdata() */

You need to update alloc_bootmem_bdata and alloc_bootmem_core as well.
Otherwise this is a no-op for early allocations when slab is not
available which is the case unless something is broken.

[...]
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/3] xen/arm: introduce xen_early_init, use PSCI on xen

[Nicolas Pitre]

On Wed, 3 Apr 2013, Stefano Stabellini wrote:

> On Tue, 2 Apr 2013, Nicolas Pitre wrote:
> > On Tue, 2 Apr 2013, Stefano Stabellini wrote:
> > 
> > > @@ -176,27 +178,30 @@ static int __init xen_secondary_init(unsigned int 
> > > cpu)
> > >   return 0;
> > >  }
> > >  
> > > +static void __init xen_smp_init(void)
> > > +{
> > > + if (psci_smp_available())
> > > + smp_set_ops(_smp_ops);
> > > +}
> > > +
> > 
> > I still don't understand why you need to do this.  Why can't you just 
> > rely on the next priority which is to set PSCI ops by default if 
> > available?  Using this hook for Xen doesn't look justified. As it is, 
> > you break MCPM.
> > 
> > As I explained to you, MCPM will end up using PSCI as well when 
> > available, which I think should be sufficient for your concern.
> 
> The smp_init hook is not limited to MCPM or the versatile express
> platform. It's a generic hook that can be used by any platform and can
> override the platform smp_ops or the psci_smp_ops depending on platform
> specific configurations.
> 
> Configurations that I am pretty sure won't be available on Xen anyway,
> while I am certain that using psci_smp_ops would work.
> 
> It seems to me that relying on the fact that only versatile express and
> only MCPM use smp_init, even though it might work today, it's very
> fragile and could break tomorrow without any of us noticing.

I claim: this breaks MCPM today.

You claim: the alternative _could_ break with Xen tomorrow.

Could we please wait until there is an actual problem with Xen before 
being overly defensive in the code?


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: need to expose sched_clock to correlate user samples with kernel samples

[Stephane Eranian]

On Wed, Apr 3, 2013 at 3:55 PM, David Ahern  wrote:
> On 4/3/13 3:17 AM, Stephane Eranian wrote:
>>
>> I haven't done any specific testing with either approach yet. The goal is
>> to
>> use this perf timestamp to correlate user level events to hardware
>> events recorded
>> by the kernel. I would assume there would be situations where those user
>> events
>> could be on the critical path, and thus the timestamp operation would have
>> to be
>> as efficient as possible. The vdso approach would be ideal.
>>
>>>
>>> The performance/speed depends on how often is called. I have no idea what
>>> Stephane's use case is but for me it is to correlate perf_clock
>>> timestamps
>>> to timeofday. In my perf-based daemon that tracks process schedulings, I
>>> update the correlation every 5-10 minutes.
>>>
>> I was more thinking along the lines of runtime environments like Java
>> where
>> a JIT compiler is invoked frequently and you need to correlate samples in
>> the
>> native code with Java source. For that, the JIT compiler has to emit
>> mapping
>> tables which have to be timestamped as address ranges may be re-used.
>
>
> What's the advantage of changing apps -- like the JIT compiler -- to emit
> perf based timestamps versus having perf emit existing timestamps? ie.,
> monotonic and realtime clocks already have vdso mappings for userspace with
> well known performance characteristics. Why not have perf convert its
> perf_clock timestamps into monotonic or realtime when dumping events?
>
Can monotonic timestamps be obtained from NMI context in the kernel?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2, RFC 20/30] ramfs: enable transparent huge page cache

[Christoph Lameter]

On Tue, 2 Apr 2013, Hugh Dickins wrote:

> I am strongly in favour of removing that limitation from
> __isolate_lru_page() (and the thread you pointed - thank you - shows Mel
> and Christoph were both in favour too); and note that there is no such
> restriction in the confusingly similar but different isolate_lru_page().

Well the naming could be cleaned up. The fundamental issue with migrating
pages is that all references have to be tracked and updates in a way that
no references can be followed to invalid or stale page contents. If ramfs
does not maintain separate pointers but only relies on pointers already
handled by the migration logic then migration is fine.

> Some people do worry that migrating Mlocked pages would introduce the
> occasional possibility of a minor fault (with migration_entry_wait())
> on an Mlocked region which never faulted before.  I tend to dismiss
> that worry, but maybe I'm wrong to do so: maybe there should be a
> tunable for realtimey people to set, to prohibit page migration from
> mlocked areas; but the default should be to allow it.

Could we have a different way of marking pages "pinned"? This is useful
for various subsystems (like RDMA and various graphics drivers etc) which
need to ensure that virtual address to physical address mappings stay the
same for a prolonged period of time. I think this use case is becoming
more frequent given that offload techniques have to be used these days to
overcome the limits on processor performance.

> The other reason it looks as if ramfs pages cannot be migrated, is
> that it does not set a suitable ->migratepage method, so would be
> handled by fallback_migrate_page(), whose PageDirty test will end
> up failing the migration with -EBUSY or -EINVAL - if I read it
> correctly.

These could be handled the same way that anonymous pages are handled.

> But until ramfs pages can be migrated, they should not be allocated
> with __GFP_MOVABLE.  (I've been writing about the migratability of
> small pages: I expect you have the migratability of THPages in flux.)

I agree.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1] pwm: add sysfs interface

[Lars Poeschel]

From: Lars Poeschel 

This adds a simple sysfs interface to the pwm subsystem. It is
heavily inspired by the gpio sysfs interface.

/sys/class/pwm
/export ... asks the kernel to export a PWM to userspace
/unexport ... to return a PWM to the kernel
/pwmN ... for each exported PWM #N
/duty_ns ... r/w, length of duty portion
/period_ns ... r/w, length of the pwm period
/polarity ... r/w, normal(0) or inverse(1) polarity
   only created if driver supports it
/run ... r/w, write 1 to start and 0 to stop the pwm
/pwmchipN ... for each pwmchip; #N is its first PWM
/base ... (r/o) same as N
/ngpio ... (r/o) number of PWM; numbered N .. MAX_PWMS

Signed-off-by: Lars Poeschel 
---
since PATCH RFC:

* updated documentation
* added ABI doc
* use default group functionality when exposing files to userspace

 create mode 100644 Documentation/ABI/testing/sysfs-class-pwm

diff --git a/Documentation/ABI/testing/sysfs-class-pwm 
b/Documentation/ABI/testing/sysfs-class-pwm
new file mode 100644
index 000..e9be1a3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-pwm
@@ -0,0 +1,37 @@
+What:  /sys/class/pwm/
+Date:  March 2013
+KernelVersion: 3.11
+Contact:   Lars Poeschel 
+Description:
+
+  The sysfs interface for PWM is selectable as a Kconfig option.
+  If a driver successfully probed a pwm chip, it appears at
+  /sys/class/pwm/pwmchipN/ where N is the number of it's first PWM channel. A
+  single driver may probe multiple chips. PWMs are identified as they are
+  inside the kernel, using integers in the range 0..MAX_PWMS. To use an
+  individual PWM, you have to explicitly export it by writing it's kernel
+  global number into the /sys/class/pwm/export file. Write it's number to
+  /sys/class/pwm/unexport to make the pwm available for other uses.
+  After a PWM channel is exported, it is available under
+  /sys/class/pwm/pwmN/. Under this directory you can set the parameters for
+  this PWM channel and at least let it start running.
+  See below for the parameters.
+  It is recommended to set the period_ns at first and the duty_ns after that.
+
+  See Documentation/pwm.txt for more information.
+
+Directory structure:
+
+   /sys/class/pwm
+   /export ... asks the kernel to export a PWM to userspace
+   /unexport ... to return a PWM to the kernel
+   /pwmN ... for each exported PWM #N
+   /duty_ns ... r/w, length of duty portion
+   /period_ns ... r/w, length of the pwm period
+   /polarity ... r/w, normal(0) or inverse(1) polarity
+   only created if driver supports it
+   /run ... r/w, write 1 to start and 0 to stop the pwm
+   /pwmchipN ... for each pwmchip; #N is its first PWM
+   /base ... (r/o) same as N
+   /ngpio ... (r/o) number of PWM; numbered N .. MAX_PWMS
+
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 7d2b4c9..b349d16 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -45,6 +45,52 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int 
period_ns);
 
 To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
 
+Using PWMs with the sysfs interface
+---
+
+You have to enable CONFIG_PWM_SYSFS in your kernel configuration to use
+the sysfs interface. It is exposed at /sys/class/pwm/. If there are pwm
+drivers loaded and these drivers successfully probed a chip, this chip
+is exported as pwmchipX . Note that a single driver can probe multiple chips.
+Inside the directory you can read these properties:
+
+base - This is the linux global start where the chips pwm channels get
+exposed.
+
+npwm - This is the number of pwm channels this chip supports.
+
+If you want to start using a pwm channel with sysfs first you have to
+export it. If you are finished with it and want to free the pwm for other
+uses, you can unexport it:
+
+export - Write the global pwm channel number to this file to start using
+the channel with sysfs.
+
+unexport - Write the global pwm channel number of the channel you are finshed
+with to this file to make the channel available for other uses.
+
+Once a pwm is exported a pwmX (X ranging from 0 to MAX_PWMS) directory appears
+with the following read/write properties inside to control the pwm:
+
+duty_ns - Write the number of nanoseconds the active portion of the pwm period
+should last to this file. This can not be longer than the period_ns.
+
+period_ns - Write the length of the pwm period in nanoseconds to this file.
+This includes the active and inactive portion of the pwm period and can not
+be smaller than duty_ns.
+
+polarity - The normal behaviour is to put out a high for the active portion of
+the pwm period. Write a 

Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management

[Felipe Balbi]

Hi,

On Wed, Apr 03, 2013 at 04:54:14PM +0300, Felipe Balbi wrote:
> > >> >> +static inline void usb_phy_autopm_enable(struct usb_phy *x)
> > >> >> +{
> > >> >> +   if (!x || !x->dev) {
> > >> >> +   dev_err(x->dev, "no PHY or attached device 
> > >> >> available\n");
> > >> >> +   return;
> > >> >> +   }
> > >> >> +
> > >> >> +   pm_runtime_enable(x->dev);
> > >> >> +}
> > >> >
> > >> >
> > >> > IMO we need not have wrapper APIs for runtime_enable and 
> > >> > runtime_disable
> > >> > here. Generally runtime_enable and runtime_disable is done in probe and
> > >> > remove of a driver respectively. So it's better to leave the
> > >> > runtime_enable/runtime_disable to be done in *phy provider* driver than
> > >> > having an API for it to be done by *phy user* driver. Felipe, what do 
> > >> > you
> > >> > think?
> > >>
> > >> Thanks!!
> > >> That's very true, runtime_enable() and runtime_disable() calls are made 
> > >> by
> > >> *phy_provider* only. But a querry here.
> > >> Wouldn't in any case a PHY consumer might want to disable runtime_pm on 
> > >> PHY ?
> > >> Say, when consumer failed to suspend the PHY properly
> > >> (*put_sync(phy->dev)* fails), how much sure is the consumer about the
> > >> state of PHY ?
> > >
> > > no no, wait a minute. We might not want to enable runtime pm for the PHY
> > > until the UDC says it can handle runtime pm, no ? I guess this makes a
> > > bit of sense (at least in my head :-p).
> > >
> > > Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
> > > enabled... Does it make sense to leave that control to the USB
> > > controller drivers ?
> > >
> > > I'm open for suggestions
> > 
> > Of course unless the PHY consumer can handle runtime PM for PHY,
> > PHY should not ideally be going into runtime_suspend.
> > 
> > Actually trying out few things, here are my observations
> > 
> > Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
> > But a device detection wakes up DWC3 controller, and if i don't wake
> > up PHY (using get_sync(phy->dev)) here
> > in runtime_resume() callback of DWC3, i don't get PHY back in active state.
> > So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
> > Thereby it becomes logical that DWC3 controller has the right to
> > enable runtime_pm
> > of PHY.
> > 
> > But there's a catch here. if there are multiple consumers of PHY (like
> > USB2 type PHY can
> > have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that 
> > case,
> > only one of the consumer can enable runtime_pm on PHY. So who decides this.
> > 
> > Aargh!! lot of confusion here :-(
> 
> 
> hmmm, maybe add a flag to struct usb_phy and check it on
> usb_phy_autopm_enable() ??
> 
> How does usbcore handle it ? They request class drivers to pass
> supports_autosuspend, but while we should have a similar flag, that's
> not enough. We also need a flag to tell us when pm_runtime has already
> been enabled.
> 
> So how about:
> 
> usb_phy_autopm_enable()
> {
>   if (!phy->suports_autosuspend)
>   return -ENOSYS;
> 
>   if (phy->autosuspend_enabled)
>   return 0;
> 
>   phy->autosuspend_enabled = true;
>   return pm_runtime_enable(phy->dev);
> }
> 
> ???

and of course I missed the fact that pm_runtime_enable returns nothing
:-) But you got my point.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2] drivers/block/xen-blkback: preq.dev is used without initialized

[William Dauchy]

On Wed, Apr 3, 2013 at 3:42 PM, Jan Beulich  wrote:
> ChangeLog-3.8.3 for example has

oh sorry, you are right. I wasn't looking is the 3.8.x branch.
The thing is, the revert seems present only in 3.8.x branch. For
example in 3.4.x the last patch is still 01c681d
Should we consider this normal or is it a mistake?

--
William
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: need to expose sched_clock to correlate user samples with kernel samples

[David Ahern]

On 4/3/13 3:17 AM, Stephane Eranian wrote:

I haven't done any specific testing with either approach yet. The goal is to
use this perf timestamp to correlate user level events to hardware
events recorded
by the kernel. I would assume there would be situations where those user events
could be on the critical path, and thus the timestamp operation would have to be
as efficient as possible. The vdso approach would be ideal.



The performance/speed depends on how often is called. I have no idea what
Stephane's use case is but for me it is to correlate perf_clock timestamps
to timeofday. In my perf-based daemon that tracks process schedulings, I
update the correlation every 5-10 minutes.


I was more thinking along the lines of runtime environments like Java where
a JIT compiler is invoked frequently and you need to correlate samples in the
native code with Java source. For that, the JIT compiler has to emit mapping
tables which have to be timestamped as address ranges may be re-used.


What's the advantage of changing apps -- like the JIT compiler -- to 
emit perf based timestamps versus having perf emit existing timestamps? 
ie., monotonic and realtime clocks already have vdso mappings for 
userspace with well known performance characteristics. Why not have perf 
convert its perf_clock timestamps into monotonic or realtime when 
dumping events?


David

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management

[Felipe Balbi]

HI,

On Wed, Apr 03, 2013 at 06:42:48PM +0530, Vivek Gautam wrote:
> >> >> Adding  APIs to handle runtime power management on PHY
> >> >> devices. PHY consumers may need to wake-up/suspend PHYs
> >> >> when they work across autosuspend.
> >> >>
> >> >> Signed-off-by: Vivek Gautam 
> >> >> ---
> >> >>   include/linux/usb/phy.h |  141
> >> >> +++
> >> >>   1 files changed, 141 insertions(+), 0 deletions(-)
> >> >>
> >> >> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
> >> >> index 6b5978f..01bf9c1 100644
> >> >> --- a/include/linux/usb/phy.h
> >> >> +++ b/include/linux/usb/phy.h
> >> >> @@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
> >> >> usb_phy_type type)
> >> >> return "UNKNOWN PHY TYPE";
> >> >> }
> >> >>   }
> >> >> +
> >> >> +static inline void usb_phy_autopm_enable(struct usb_phy *x)
> >> >> +{
> >> >> +   if (!x || !x->dev) {
> >> >> +   dev_err(x->dev, "no PHY or attached device 
> >> >> available\n");
> >> >> +   return;
> >> >> +   }
> >> >> +
> >> >> +   pm_runtime_enable(x->dev);
> >> >> +}
> >> >
> >> >
> >> > IMO we need not have wrapper APIs for runtime_enable and runtime_disable
> >> > here. Generally runtime_enable and runtime_disable is done in probe and
> >> > remove of a driver respectively. So it's better to leave the
> >> > runtime_enable/runtime_disable to be done in *phy provider* driver than
> >> > having an API for it to be done by *phy user* driver. Felipe, what do you
> >> > think?
> >>
> >> Thanks!!
> >> That's very true, runtime_enable() and runtime_disable() calls are made by
> >> *phy_provider* only. But a querry here.
> >> Wouldn't in any case a PHY consumer might want to disable runtime_pm on 
> >> PHY ?
> >> Say, when consumer failed to suspend the PHY properly
> >> (*put_sync(phy->dev)* fails), how much sure is the consumer about the
> >> state of PHY ?
> >
> > no no, wait a minute. We might not want to enable runtime pm for the PHY
> > until the UDC says it can handle runtime pm, no ? I guess this makes a
> > bit of sense (at least in my head :-p).
> >
> > Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
> > enabled... Does it make sense to leave that control to the USB
> > controller drivers ?
> >
> > I'm open for suggestions
> 
> Of course unless the PHY consumer can handle runtime PM for PHY,
> PHY should not ideally be going into runtime_suspend.
> 
> Actually trying out few things, here are my observations
> 
> Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
> But a device detection wakes up DWC3 controller, and if i don't wake
> up PHY (using get_sync(phy->dev)) here
> in runtime_resume() callback of DWC3, i don't get PHY back in active state.
> So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
> Thereby it becomes logical that DWC3 controller has the right to
> enable runtime_pm
> of PHY.
> 
> But there's a catch here. if there are multiple consumers of PHY (like
> USB2 type PHY can
> have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that case,
> only one of the consumer can enable runtime_pm on PHY. So who decides this.
> 
> Aargh!! lot of confusion here :-(


hmmm, maybe add a flag to struct usb_phy and check it on
usb_phy_autopm_enable() ??

How does usbcore handle it ? They request class drivers to pass
supports_autosuspend, but while we should have a similar flag, that's
not enough. We also need a flag to tell us when pm_runtime has already
been enabled.

So how about:

usb_phy_autopm_enable()
{
if (!phy->suports_autosuspend)
return -ENOSYS;

if (phy->autosuspend_enabled)
return 0;

phy->autosuspend_enabled = true;
return pm_runtime_enable(phy->dev);
}

???

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v5 2/6] usb: phy: omap-usb2: use the new generic PHY framework

[Felipe Balbi]

On Wed, Apr 03, 2013 at 06:23:50PM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. omap_usb2_suspend
> is split into omap_usb_suspend and omap_usb_resume in order to align
> with the new framework.
> 
> However using the old USB PHY library cannot be completely removed
> because OTG is intertwined with PHY and moving to the new framework
> will break OTG. Once we have a separate OTG state machine, we
> can get rid of the USB PHY library.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/phy/omap-usb2.c |   48 
> +++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
> index 844ab68..4e48db4 100644
> --- a/drivers/usb/phy/omap-usb2.c
> +++ b/drivers/usb/phy/omap-usb2.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /**
>   * omap_usb2_set_comparator - links the comparator present in the sytem with
> @@ -119,9 +120,49 @@ static int omap_usb2_suspend(struct usb_phy *x, int 
> suspend)
>   return 0;
>  }
>  
> +static int omap_usb_suspend(struct phy *x)
> +{
> + struct omap_usb *phy = dev_get_drvdata(>dev);
> +
> + if (!phy->is_suspended) {
> + omap_control_usb_phy_power(phy->control_dev, 0);
> + pm_runtime_put_sync(phy->dev);
> + phy->is_suspended = 1;
> + }
> +
> + return 0;
> +}
> +
> +static int omap_usb_resume(struct phy *x)
> +{
> + u32 ret;
> + struct omap_usb *phy = dev_get_drvdata(>dev);
> +
> + if (phy->is_suspended) {
> + ret = pm_runtime_get_sync(phy->dev);
> + if (ret < 0) {
> + dev_err(phy->dev, "get_sync failed with err %d\n",
> + ret);
> + return ret;
> + }
> + omap_control_usb_phy_power(phy->control_dev, 1);
> + phy->is_suspended = 0;
> + }
> +
> + return 0;
> +}
> +
> +static struct phy_ops ops = {

const ? Maybe provide a:

#define DEFINE_PHY_OPS(name)\
const struct phy_ops #name_phy_ops = {

macro ? This will force people to add the const keyword :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/2] efi: Distinguish between "remaining space" and actually used space

[Matthew Garrett]

On Wed, 2013-04-03 at 14:11 +0100, Matt Fleming wrote:

> This looks like something that will differ between implementations, and the
> fact that it's appearing in our code is a sure sign that this isn't the way to
> go.

Our choices right now are:

1) Break machines that don't garbage collect on every reboot
2) Leave Samsungs (and some Lenovos?) vulnerable to bricking
3) Maintain a whitelist or blacklist that will inevitably be inadequate,
either breaking otherwise working machines or risking bricking of broken
ones
4) Attempt to implement something that'll work in all cases

Dealing with firmware is hard. This fixes (1) without leaving us with
(2), which seems like a net win.

-- 
Matthew Garrett | mj...@srcf.ucam.org
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [RFC PATCH v2] rtc: rtc-at91rm9200: manage IMR depending on revision

[Johan Hovold]

On Wed, Apr 03, 2013 at 12:37:47PM +0200, Nicolas Ferre wrote:
> On 04/03/2013 11:51 AM, Johan Hovold :
> > On Tue, Apr 02, 2013 at 06:36:06PM +0200, Nicolas Ferre wrote:

[...]

> >> I now use a different compatibility string to figure out what is the IP
> >> revision that has the "boggus IMR" error. I think this way to handle it
> >> is much simpler than the "config" structure one from Johan.
> > 
> > I wouldn't say it's much simpler. My solution is only more generic, but
> > could of course also be reduced to "set a flag if compatible matches
> > sam9x5".
> 
> The advantage is precisely to avoid the need for a "flag". Only function
> pointers that are changed in case of the compatible string matching.

Yeah, you could do it that way. The overhead is negligible in either
solution; mask updates are infrequent and the only difference when
retrieving the mask would be to first check the flag.

An advantage of using the config-struct would perhaps be that it is same
mechanism used in i2c-at91 and atmel_lcdfb (in the arm-soc tree) to deal
with SoC-quirks and is easily extended should need arise.

The diffs of both solutions are also of roughly the same size.

But I don't have any strong preference. You decide.

[...]

> >> diff --git 
> >> a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt 
> >> b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> >> index 2a3feab..9b87053 100644
> >> --- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> >> +++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
> >> @@ -1,7 +1,8 @@
> >>  Atmel AT91RM9200 Real Time Clock
> >>  
> >>  Required properties:
> >> -- compatible: should be: "atmel,at91rm9200-rtc"
> >> +- compatible: should be: "atmel,at91rm9200-rtc", "atmel,at91sam9x5-rtc" or
> >> + "atmel,at91sam9n12-rtc".
> > 
> > Also at91sam9g45 and at91sam9rl use this driver.
> 
> Yes, sure, I did not want to add every single user of the RTC...
> 
> > As seems to be the case
> > for other peripherals, I suggest we use "atmel,at91sam9x5-rtc" for
> > sam9x5 and "atmel,at91rm9200-rtc" for the other SoCs, that is, the least
> > (and first) common denominator.
> 
> ... I was just following the habit of naming the changes in peripheral
> revision by it first use in a SoC:
> at91rm9200-rtc: from rm9200 up to 9g45
> at91sam9x5-rtc: sam9x5 only (with IMR issue)
> at91sam9n12-rtc: fist SoC that corrects the IMR issue with a new IP
> revision, until now and sama5d3 SoC

Ah, ok.
 
> > Either way, there's not need to add at91sam9n12-rtc in this patch.
> > 
> >>  - reg: physical base address of the controller and length of memory mapped
> >>region.
> >>  - interrupts: rtc alarm/event interrupt
> > 
> > I'll respond to this mail with a revert-patch, and an updated RFC-series
> > based on top of the DT-patch in Andrew's queue.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 1/6] drivers: phy: add generic PHY framework

[Felipe Balbi]

On Wed, Apr 03, 2013 at 06:23:49PM +0530, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. To obtain a reference to the PHY without
> using phandle, the platform specfic intialization code (say from board file)
> should have already called phy_bind with the binding information. The binding
> information consists of phy's device name, phy user device name and an index.
> The index is used when the same phy user binds to mulitple phys.
> 
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, 
> resume,
> power_on, power_off.
> 
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
> dt binding is can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  Documentation/ABI/testing/sysfs-class-phy  |   15 +
>  .../devicetree/bindings/phy/phy-bindings.txt   |   67 +++
>  Documentation/phy.txt  |  113 
>  MAINTAINERS|7 +
>  drivers/Kconfig|2 +
>  drivers/Makefile   |2 +
>  drivers/phy/Kconfig|   13 +
>  drivers/phy/Makefile   |5 +
>  drivers/phy/phy-core.c |  616 
> 
>  include/linux/phy/phy.h|  228 
>  10 files changed, 1068 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-phy
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>  create mode 100644 Documentation/phy.txt
>  create mode 100644 drivers/phy/Kconfig
>  create mode 100644 drivers/phy/Makefile
>  create mode 100644 drivers/phy/phy-core.c
>  create mode 100644 include/linux/phy/phy.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-phy 
> b/Documentation/ABI/testing/sysfs-class-phy
> new file mode 100644
> index 000..b735467
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-phy
> @@ -0,0 +1,15 @@
> +What:/sys/class/phy//label
> +Date:Apr 2013
> +KernelVersion:   3.10
> +Contact: Kishon Vijay Abraham I 
> +Description:
> + This is a read-only file for getting the label of the phy.
> +
> +What:/sys/class/phy//phy_bind
> +Date:Apr 2013
> +KernelVersion:   3.10
> +Contact: Kishon Vijay Abraham I 
> +Description:
> + This is a read-only file for reading the phy binding
> + information. It contains the device name of the controller,
> + the index and the device name of the PHY in that order.
> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
> b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> new file mode 100644
> index 000..e7b246a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
> @@ -0,0 +1,67 @@
> +This document explains only the dt data binding. For general information 
> about
> +PHY subsystem refer Documentation/phy.txt
> +
> +PHY device node
> +===
> +
> +Required Properties:
> +#phy-cells:  Number of cells in a PHY specifier;  The meaning of all those
> + cells is defined by the binding for the phy node. The PHY
> + provider can use the values in cells to find the appropriate
> + PHY.
> +
> +For example:
> +
> +phys: phy {
> +compatible = "xxx";
> +reg = <...>;
> +.
> +.
> +#phy-cells = <1>;
> +.
> +.
> +};
> +
> +That node describes an IP block that implements 2 different PHYs. In order to
> +differentiate between these 2 PHYs, an additonal specifier should be given
> +while trying to get a reference to it.
> +
> +PHY user node
> +=
> +
> +Required Properties:
> +phys : the phandle for the PHY device (used by the PHY subsystem)
> +
> +Optional properties:
> +phy-names : the names of the PHY corresponding to the PHYs present in the
> + *phys* phandle
> +
> +Example 1:
> +usb1: usb_otg_ss@xxx {
> +compatible = "xxx";
> +reg = ;
> +.
> +.
> +phys = <_phy>, <_phy>;
> +phy-names = "usb2phy", "usb3phy";
> +.
> +.
> +};
> +
> +This node represents a controller that uses two PHYs one for usb2 and one for
> +usb3.
> +
> +Example 2:
> +usb2: usb_otg_ss@xxx {
> +compatible = "xxx";
> +reg = ;
> +.
> +.
> +phys = < 1>;
> +.
> +.
> +};
> +
> +This node represents a controller that uses one of the PHYs which is defined
> +previously. Note that the phy handle has an 

Re: [PATCH 1/2] efi: Determine how much space is used by boot services-only variables

[Matthew Garrett]

On Wed, 2013-04-03 at 14:09 +0100, Matt Fleming wrote:

> We're fixing a regression in efivars.c, but only for those users that
> boot via the EFI boot stub? That seems likely to upset some people.

Not really - it just makes the estimates more accurate. Applying (2)
without (1) should still fix the functional regression.

-- 
Matthew Garrett | mj...@srcf.ucam.org

Re: [PATCH v2] drivers/block/xen-blkback: preq.dev is used without initialized

[Jan Beulich]

>>> On 03.04.13 at 15:25, William Dauchy  wrote:
> On Wed, Apr 3, 2013 at 3:01 PM, Jan Beulich  wrote:
>> Iirc we requested the earlier commit to be removed from stable
>> trees, and I think Greg also did so.
> 
> I'm sorry but I'm unable to find a revert of 01c681d in stable tree.

ChangeLog-3.8.3 for example has

commit 32f4d10ed8fd7ef4cebbf02c5326e8bb6aeca9b1
Author: Greg Kroah-Hartman 
Date:   Tue Mar 12 15:08:26 2013 -0700

Revert "xen/blkback: Don't trust the handle from the frontend."

This reverts commit 01c681d4c70d64cb72142a2823f27c4146a02e63 upstream
(ef56ca64ea733c3b88f0bb74b04da128b1dc35d8 in this tree), as it wasn't
supposed to have been applied to the stable tree.

Cc: Jan Beulich 
Cc: Ian Campbell 
Cc: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman 


Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv5 0/7] arm: vt8500: Add support for pinctrl/gpio module

[Linus Walleij]

On Wed, Apr 3, 2013 at 8:24 AM, Tony Prisk  wrote:

> v5 changes:
> Changed as requested by Rob Herring:
> Added of_find_property_value_of_size() to drivers/of/base.c to remove some
> code that was being duplicated.
>
> Changed as requested by Stephen Warren:
> Redid the kfree(maps) code as devm_kzalloc would cause issues. We now kzalloc
> maps all at once, and configs as required. A call to wmt_pctl_dt_free_map() is
> used to kfree the allocated blocks if we fail early.

This v5 series:
Acked-by: Linus Walleij 

I guess it will go in through the VT8500 tree eventually?

Maybe you could put Stephen's BCMring patch on top when sending
it in (also Acked-by) so we can avoid having that dangling.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH Resend v5] sched: fix init NOHZ_IDLE flag

[Vincent Guittot]

On my smp platform which is made of 5 cores in 2 clusters, I have the
nr_busy_cpu field of sched_group_power struct that is not null when the
platform is fully idle. The root cause is:
During the boot sequence, some CPUs reach the idle loop and set their
NOHZ_IDLE flag while waiting for others CPUs to boot. But the nr_busy_cpus
field is initialized later with the assumption that all CPUs are in the busy
state whereas some CPUs have already set their NOHZ_IDLE flag.

More generally, the NOHZ_IDLE flag must be initialized when new sched_domains
are created in order to ensure that NOHZ_IDLE and nr_busy_cpus are aligned.

This condition can be ensured by adding a synchronize_rcu between the
destruction of old sched_domains and the creation of new ones so the NOHZ_IDLE
flag will not be updated with old sched_domain once it has been initialized.
But this solution introduces a additionnal latency in the rebuild sequence
that is called during cpu hotplug.

As suggested by Frederic Weisbecker, another solution is to have the same
rcu lifecycle for both NOHZ_IDLE and sched_domain struct. I have introduce
a new sched_domain_rq struct that is the entry point for both sched_domains
and objects that must follow the same lifecycle like NOHZ_IDLE flags. They
will share the same RCU lifecycle and will be always synchronized.

The synchronization is done at the cost of :
 - an additional indirection for accessing the first sched_domain level
 - an additional indirection and a rcu_dereference before accessing to the
   NOHZ_IDLE flag.

Change since v4:
 - link both sched_domain and NOHZ_IDLE flag in one RCU object so
   their states are always synchronized.

Change since V3;
 - NOHZ flag is not cleared if a NULL domain is attached to the CPU
 - Remove patch 2/2 which becomes useless with latest modifications

Change since V2:
 - change the initialization to idle state instead of busy state so a CPU that
   enters idle during the build of the sched_domain will not corrupt the
   initialization state

Change since V1:
 - remove the patch for SCHED softirq on an idle core use case as it was
   a side effect of the other use cases.

Signed-off-by: Vincent Guittot 
---
 include/linux/sched.h |6 +++
 kernel/sched/core.c   |  105 -
 kernel/sched/fair.c   |   35 +++--
 kernel/sched/sched.h  |   24 +--
 4 files changed, 145 insertions(+), 25 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index d35d2b6..2a52188 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -959,6 +959,12 @@ struct sched_domain {
unsigned long span[0];
 };
 
+struct sched_domain_rq {
+   struct sched_domain *sd;
+   unsigned long flags;
+   struct rcu_head rcu;/* used during destruction */
+};
+
 static inline struct cpumask *sched_domain_span(struct sched_domain *sd)
 {
return to_cpumask(sd->span);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7f12624..69e2313 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5602,6 +5602,15 @@ static void destroy_sched_domains(struct sched_domain 
*sd, int cpu)
destroy_sched_domain(sd, cpu);
 }
 
+static void destroy_sched_domain_rq(struct sched_domain_rq *sd_rq, int cpu)
+{
+   if (!sd_rq)
+   return;
+
+   destroy_sched_domains(sd_rq->sd, cpu);
+   kfree_rcu(sd_rq, rcu);
+}
+
 /*
  * Keep a special pointer to the highest sched_domain that has
  * SD_SHARE_PKG_RESOURCE set (Last Level Cache Domain) for this
@@ -5632,10 +5641,23 @@ static void update_top_cache_domain(int cpu)
  * hold the hotplug lock.
  */
 static void
-cpu_attach_domain(struct sched_domain *sd, struct root_domain *rd, int cpu)
+cpu_attach_domain(struct sched_domain_rq *sd_rq, struct root_domain *rd,
+   int cpu)
 {
struct rq *rq = cpu_rq(cpu);
-   struct sched_domain *tmp;
+   struct sched_domain_rq *tmp_rq;
+   struct sched_domain *tmp, *sd = NULL;
+
+   /*
+* If we don't have any sched_domain and associated object, we can
+* directly jump to the attach sequence otherwise we try to degenerate
+* the sched_domain
+*/
+   if (!sd_rq)
+   goto attach;
+
+   /* Get a pointer to the 1st sched_domain */
+   sd = sd_rq->sd;
 
/* Remove the sched domains which do not contribute to scheduling. */
for (tmp = sd; tmp; ) {
@@ -5658,14 +5680,17 @@ cpu_attach_domain(struct sched_domain *sd, struct 
root_domain *rd, int cpu)
destroy_sched_domain(tmp, cpu);
if (sd)
sd->child = NULL;
+   /* update sched_domain_rq */
+   sd_rq->sd = sd;
}
 
+attach:
sched_domain_debug(sd, cpu);
 
rq_attach_root(rq, rd);
-   tmp = rq->sd;
-   rcu_assign_pointer(rq->sd, sd);
-   destroy_sched_domains(tmp, cpu);
+   tmp_rq = rq->sd_rq;
+   

[PATCH v2] aio: convert the ioctx list to radix tree

[Octavian Purdila]

When using a large number of threads performing AIO operations the
IOCTX list may get a significant number of entries which will cause
significant overhead. For example, when running this fio script:

rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
blocksize=1024; numjobs=512; thread; loops=100

on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
30% CPU time spent by lookup_ioctx:

 32.51%  [guest.kernel]  [g] lookup_ioctx
  9.19%  [guest.kernel]  [g] __lock_acquire.isra.28
  4.40%  [guest.kernel]  [g] lock_release
  4.19%  [guest.kernel]  [g] sched_clock_local
  3.86%  [guest.kernel]  [g] local_clock
  3.68%  [guest.kernel]  [g] native_sched_clock
  3.08%  [guest.kernel]  [g] sched_clock_cpu
  2.64%  [guest.kernel]  [g] lock_release_holdtime.part.11
  2.60%  [guest.kernel]  [g] memcpy
  2.33%  [guest.kernel]  [g] lock_acquired
  2.25%  [guest.kernel]  [g] lock_acquire
  1.84%  [guest.kernel]  [g] do_io_submit

This patchs converts the ioctx list to a radix tree. For a performance
comparison the above FIO script was run on a 2 sockets 8 core
machine. This are the results for the original list based
implementation and for the radix tree based implementation:

cores 1 2 4 8 1632
list111025 ms  62219 ms  34193 ms  22998 ms  19335 ms  15956 ms
radix75400 ms  42668 ms  23923 ms  17206 ms  15820 ms  13295 ms
% of radix
relative  68%   69%   70%   75%   82%   83%
to list

To consider the impact of the patch on the typical case of having
only one ctx per process the following FIO script was run:

rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
blocksize=1024; numjobs=1; thread; loops=100

on the same system and the results are the following:

list65241 ms
radix   65402 ms
% of radix
relative100.25%
to list

Cc: Andi Kleen 

Signed-off-by: Octavian Purdila 

---

Changes since V1:
 * add performance comparision for the typical case of having only one
   ctx per process
 * use ARRAY_SIZE and drop tracking idx as it is not needed

 arch/s390/mm/pgtable.c   |4 +-
 fs/aio.c |   95 +++---
 include/linux/aio.h  |1 -
 include/linux/mm_types.h |3 +-
 kernel/fork.c|2 +-
 5 files changed, 61 insertions(+), 44 deletions(-)

diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index ae44d2a..6fb6751 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -831,7 +831,7 @@ int s390_enable_sie(void)
task_lock(tsk);
if (!tsk->mm || atomic_read(>mm->mm_users) > 1 ||
 #ifdef CONFIG_AIO
-   !hlist_empty(>mm->ioctx_list) ||
+   tsk->mm->ioctx_rtree.rnode ||
 #endif
tsk->mm != tsk->active_mm) {
task_unlock(tsk);
@@ -858,7 +858,7 @@ int s390_enable_sie(void)
task_lock(tsk);
if (!tsk->mm || atomic_read(>mm->mm_users) > 1 ||
 #ifdef CONFIG_AIO
-   !hlist_empty(>mm->ioctx_list) ||
+   tsk->mm->ioctx_rtree.rnode ||
 #endif
tsk->mm != tsk->active_mm) {
mmput(mm);
diff --git a/fs/aio.c b/fs/aio.c
index 3f941f2..c70d4ac 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -281,10 +282,18 @@ static struct kioctx *ioctx_alloc(unsigned nr_events)
aio_nr += ctx->max_reqs;
spin_unlock(_nr_lock);
 
-   /* now link into global list. */
+   /* now insert into the radix tree */
+   err = radix_tree_preload(GFP_KERNEL);
+   if (err)
+   goto out_cleanup;
spin_lock(>ioctx_lock);
-   hlist_add_head_rcu(>list, >ioctx_list);
+   err = radix_tree_insert(>ioctx_rtree, ctx->user_id, ctx);
spin_unlock(>ioctx_lock);
+   radix_tree_preload_end();
+   if (err) {
+   WARN_ONCE(1, "aio: insert into ioctx tree failed: %d", err);
+   goto out_cleanup;
+   }
 
dprintk("aio: allocated ioctx %p[%ld]: mm=%p mask=0x%x\n",
ctx, ctx->user_id, current->mm, ctx->ring_info.nr);
@@ -362,6 +371,32 @@ ssize_t wait_on_sync_kiocb(struct kiocb *iocb)
 }
 EXPORT_SYMBOL(wait_on_sync_kiocb);
 
+static inline void exit_aio_ctx(struct mm_struct *mm, struct kioctx *ctx)
+{
+   void *ret;
+
+   ret = radix_tree_delete(>ioctx_rtree, ctx->user_id);
+   BUG_ON(!ret || ret != ctx);
+
+   kill_ctx(ctx);
+
+   if (1 != atomic_read(>users))
+   pr_debug("exit_aio:ioctx still alive: %d %d %d\n",
+atomic_read(>users), ctx->dead, ctx->reqs_active);
+   /*
+* We don't need to bother with munmap() here -
+* exit_mmap(mm) is coming and it'll unmap everything.
+* Since aio_free_ring() uses non-zero ->mmap_size
+* as indicator that it needs to unmap the area,
+* just set it to 0; aio_free_ring() is the only
+* 

Re: [RFC] Add implicit barriers to irqsave/restore class of functions

[Vineet Gupta]

Hi Christian,

On 04/03/2013 06:40 PM, Christian Ruppert wrote:
> This patch adds implicit memory barriers to irqsave/restore functions of
> the ARC architecture port in line with what is done in other architectures.
>
> It seems to fix several seemingly unrelated issues in our platform but for
> the moment it is insufficiently tested (and might even be incomplete).
> Please comment.

I think this is not needed. Semantically we need barrier for spinlocks, not irq
save/restore - although spin locks are one of the primary users of irq
save/restore API.

So repeating what Thomas already said, the barrier already exists for
PREEMPT_COUNT, we need to make sure they are present for !PREEMPT_COUNT.

-Vineet

> Signed-off-by: Christian Ruppert 
> ---
>  arch/arc/include/asm/irqflags.h |8 
>  1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arc/include/asm/irqflags.h b/arch/arc/include/asm/irqflags.h
> index ccd8480..c8147d1 100644
> --- a/arch/arc/include/asm/irqflags.h
> +++ b/arch/arc/include/asm/irqflags.h
> @@ -39,7 +39,7 @@ static inline long arch_local_irq_save(void)
>   "   flag.nz %0  \n"
>   : "=r"(temp), "=r"(flags)
>   : "n"((STATUS_E1_MASK | STATUS_E2_MASK))
> - : "cc");
> + : "memory", "cc");
>  
>   return flags;
>  }
> @@ -53,7 +53,7 @@ static inline void arch_local_irq_restore(unsigned long 
> flags)
>   __asm__ __volatile__(
>   "   flag %0 \n"
>   :
> - : "r"(flags));
> + : "r"(flags) : "memory");
>  }
>  
>  /*
> @@ -73,7 +73,7 @@ static inline void arch_local_irq_disable(void)
>   "   and %0, %0, %1  \n"
>   "   flag %0 \n"
>   : "="(temp)
> - : "n"(~(STATUS_E1_MASK | STATUS_E2_MASK)));
> + : "n"(~(STATUS_E1_MASK | STATUS_E2_MASK)) : "memory");
>  }
>  
>  /*
> @@ -85,7 +85,7 @@ static inline long arch_local_save_flags(void)
>  
>   __asm__ __volatile__(
>   "   lr  %0, [status32]  \n"
> - : "="(temp));
> + : "="(temp) : : "memory");
>  
>   return temp;
>  }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] gpio: remove GENERIC_GPIO completely

[Linus Walleij]

On Fri, Mar 29, 2013 at 2:11 PM, Alexandre Courbot  wrote:

> Since I have received no death threat from architecture maintainers I'd like 
> to
> proceed with the remainder of this work so that it doesn't go half-baked into
> 3.10. These three patches finish the removal of the GENERIC_GPIO config option
> which has been made equivalent to GPIOLIB in the previous series. It does so 
> by
> first changing all references to GENERIC_GPIO into GPIOLIB in driver code and
> configuration files, and then removing the unused option from the Kconfig 
> files
> where it is declared.
>
> The last patch in the series confirms gpiolib in its new role as GPIO 
> framework
> by renaming CONFIG_GPIOLIB into CONFIG_GPIO, following the model used by other
> frameworks. This name changing might rise concern but it seems more logical to
> me and the historical gpiolib name is still mentioned in the documentation to
> relieve the confusion.
>
> If I can get a few acks on these (or at least the first two ones) I'd like to
> include them into my next branch as soon as possible so points of breakage can
> be fixed. There are indeed a few new users of GENERIC_GPIO (CC Romain, I sent 
> a
> warning but saw no action so far) in the next tree and compilation will break
> for them.
>
> Another issue, I could not update the Chinese documentation in a satisfying
> manner due to my absence of Chinese skills. Hope that will be forgiven.
>
> Alexandre Courbot (3):
>   Convert selectors of GENERIC_GPIO to GPIOLIB
>   Remove GENERIC_GPIO config option
>   Rename CONFIG_GPIOLIB to CONFIG_GPIO

The series:
Acked-by: Linus Walleij 

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/block/xen-blkback: preq.dev is used without initialized

[William Dauchy]

Hello Jan,

On Wed, Apr 3, 2013 at 3:01 PM, Jan Beulich  wrote:
> Iirc we requested the earlier commit to be removed from stable
> trees, and I think Greg also did so.

I'm sorry but I'm unable to find a revert of 01c681d in stable tree.

Regards,
--
William
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] mm/x86: Patch out arch_flush_lazy_mmu_mode() when running on bare metal

[Boris Ostrovsky]

On 03/23/2013 09:36 AM, Konrad Rzeszutek Wilk wrote:

From: Boris Ostrovsky 

Invoking arch_flush_lazy_mmu_mode() results in calls to
preempt_enable()/disable() which may have performance impact.

Since lazy MMU is not used on bare metal we can patch away
arch_flush_lazy_mmu_mode() so that it is never called in such
environment.

Signed-off-by: Boris Ostrovsky 
Tested-by: Josh Boyer 
Tested-by: Konrad Rzeszutek Wilk 
Acked-by: Borislav Petkov 
Signed-off-by: Konrad Rzeszutek Wilk 


Peter, what's the status of these two patches? They are not going into
3.9, right?

Thanks.
-boris



---
  arch/x86/include/asm/paravirt.h   |  5 -
  arch/x86/include/asm/paravirt_types.h |  2 ++
  arch/x86/kernel/paravirt.c| 25 +
  arch/x86/lguest/boot.c|  1 +
  arch/x86/xen/mmu.c|  1 +
  5 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 5edd174..7361e47 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -703,7 +703,10 @@ static inline void arch_leave_lazy_mmu_mode(void)
PVOP_VCALL0(pv_mmu_ops.lazy_mode.leave);
  }
  
-void arch_flush_lazy_mmu_mode(void);

+static inline void arch_flush_lazy_mmu_mode(void)
+{
+   PVOP_VCALL0(pv_mmu_ops.lazy_mode.flush);
+}
  
  static inline void __set_fixmap(unsigned /* enum fixed_addresses */ idx,

phys_addr_t phys, pgprot_t flags)
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 142236e..b3b0ec1 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -91,6 +91,7 @@ struct pv_lazy_ops {
/* Set deferred update mode, used for batching operations. */
void (*enter)(void);
void (*leave)(void);
+   void (*flush)(void);
  };
  
  struct pv_time_ops {

@@ -679,6 +680,7 @@ void paravirt_end_context_switch(struct task_struct *next);
  
  void paravirt_enter_lazy_mmu(void);

  void paravirt_leave_lazy_mmu(void);
+void paravirt_flush_lazy_mmu(void);
  
  void _paravirt_nop(void);

  u32 _paravirt_ident_32(u32);
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 17fff18..8bfb335 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -263,6 +263,18 @@ void paravirt_leave_lazy_mmu(void)
leave_lazy(PARAVIRT_LAZY_MMU);
  }
  
+void paravirt_flush_lazy_mmu(void)

+{
+   preempt_disable();
+
+   if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
+   arch_leave_lazy_mmu_mode();
+   arch_enter_lazy_mmu_mode();
+   }
+
+   preempt_enable();
+}
+
  void paravirt_start_context_switch(struct task_struct *prev)
  {
BUG_ON(preemptible());
@@ -292,18 +304,6 @@ enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
return this_cpu_read(paravirt_lazy_mode);
  }
  
-void arch_flush_lazy_mmu_mode(void)

-{
-   preempt_disable();
-
-   if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU) {
-   arch_leave_lazy_mmu_mode();
-   arch_enter_lazy_mmu_mode();
-   }
-
-   preempt_enable();
-}
-
  struct pv_info pv_info = {
.name = "bare hardware",
.paravirt_enabled = 0,
@@ -475,6 +475,7 @@ struct pv_mmu_ops pv_mmu_ops = {
.lazy_mode = {
.enter = paravirt_nop,
.leave = paravirt_nop,
+   .flush = paravirt_nop,
},
  
  	.set_fixmap = native_set_fixmap,

diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 1cbd89c..7114c63 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1334,6 +1334,7 @@ __init void lguest_init(void)
pv_mmu_ops.read_cr3 = lguest_read_cr3;
pv_mmu_ops.lazy_mode.enter = paravirt_enter_lazy_mmu;
pv_mmu_ops.lazy_mode.leave = lguest_leave_lazy_mmu_mode;
+   pv_mmu_ops.lazy_mode.flush = paravirt_flush_lazy_mmu;
pv_mmu_ops.pte_update = lguest_pte_update;
pv_mmu_ops.pte_update_defer = lguest_pte_update;
  
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c

index e8e3493..f4f4105 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2197,6 +2197,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
.lazy_mode = {
.enter = paravirt_enter_lazy_mmu,
.leave = xen_leave_lazy_mmu,
+   .flush = paravirt_flush_lazy_mmu,
},
  
  	.set_fixmap = xen_set_fixmap,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] ARM: remove mach .init_irq for irqchip_init users

[Jamie Iles]

On Thu, Mar 28, 2013 at 09:46:45PM +0100, Maxime Ripard wrote:
> Now that the arm core code calls irqchip_init, we can remove it from all
> the machines that were using it.
> 
> Signed-off-by: Maxime Ripard 
> Acked-by: Simon Horman 

Acked-by: Jamie Iles 

Thanks Maxime!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] x86, kdump: Retore crashkernel= to allocate low

[Vivek Goyal]

On Tue, Apr 02, 2013 at 01:36:02PM -0700, Yinghai Lu wrote:

[..]
> > You are just describing what your code does. There is no theme or
> > justification behind this behavior. There is no uniformity. A user can
> > question that so far you used to honor last crashkernel= parameter and
> > suddenly in 3.9 that's no more the case. Out of blue crashkernel=X,high is
> > overriding crashkernel=X and it is not obivious why.
> 
> Let me repeat again:
> we keep crashkernel=X old behavior with old kexec-tools.
> crashkernel=X;high is for new kexec-tools that support loading high.
> 
> If the user want to use ,high but still with old kexec-tools, that is
> not going to work.
> 
> Can we just keep it separated?

Kernel does not know about old kexec-tools or new kexec-tools. Neither
kernel can enforce what command line options are passed by user. So
kernel needs to define a clean interface here which is easily understood
and is extensible also in future.

[..]
> >
> > If user wants 128M in low memory, they will just specify
> > crashkernel=128M;low
> 
> in the kernel-parameter.txt, already says ;low is need to used with ;high.

But why are we tying ;low to ;high. One should be easily extend
crashkernel=X to be able to reserve memory above 4G if specified amount
is not available below 4G. In that case also one might want to reserve
some low memory?

For that matter crashkernel=range1:size,range2:size syntax should be
extendible too to reserve memory above 4G if desired size of memory
is not available in low memory.

Now in those cases too, one would like to have 72M of low memory
reserved. So ;low shoud not be tied to ;high necessarily.

In fact current code does not care whetehr ;high was specified or not.
If memory is reserved above 4G, ;low code will kick in.

> 
> >
> > If they want to control multiple ranges of memory, then that's the feature
> > we currently don't support. Currently we support only reserving one range
> > of memory.
> >
> > If you want to support multiple ranges of memory,then do it properly.
> > Parse all crashkernel= options, prepare a list of memory to be reserved
> > and unreserved, resolve all the conflicts between various options and
> > then reserve the memory. But that does not seem to be a requirement at
> > this point of time.
> 
> No we does not support multiple ranges, as it will need more changes
> in kexec-tools.
> 
> Can we stop here with those four patches?
> 
> Later, we can extend it if it is really needed.

crashkernel= options are already confusing. I think we with this patchset
we will just make them even more confusing and future extensions
difficult.

We really need to stick to the notion of only one crashkernel= option
is accepted and that is last one on command line. And if need be,
we need to work on multi range reservation feature where we process
and reserve ranges as specified by all crashkernel= parameters on
command line.

Creating new combinations where some crashkernel= are preferred over
others and some crashkernel= options work with only selected crashkernel=
options, is asking for trouble, especially keeping in mind future
extensions.

I prefer following for 3.9.

- process only right most crashkernel= option.
- implement crashkernel_no_auto_low option to opt out of auto reserved
  low memory
- implement crashkernel=X;high to support high memory reservations.

And now old kexec-tools user can use crashkernel=X while users needing
high memory reservation can use crashkernel=X;high.

If you really want to support user defined crashkernel=X;low along with
crashkernel=Y;high, that is really a multi range reservation feature and
need to be implemented properly instead of coming up with short cuts.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add non-zero module sections to sysfs

[Sebastian Wankerl]

Add non-zero module sections to sysfs on architectures unequal to PARISC.
KGDB needs all module sections for proper module debugging. Therefore, commit 
35dead4235e2b67da7275b4122fed37099c2f462 is revoked except for PARISC
architecture.

Signed-off-by: Sebastian Wankerl 
Signed-off-by: Philip Kranz 

---
 kernel/module.c |4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/module.c b/kernel/module.c
index 3c2c72d..5393a54 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1316,7 +1316,11 @@ resolve_symbol_wait(struct module *mod,
 #ifdef CONFIG_KALLSYMS
 static inline bool sect_empty(const Elf_Shdr *sect)
 {
+#if defined(CONFIG_PARISC)
return !(sect->sh_flags & SHF_ALLOC) || sect->sh_size == 0;
+#else
+   return !(sect->sh_flags & SHF_ALLOC);
+#endif
 }
 
 struct module_sect_attr
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 01/11] usb: phy: Add APIs for runtime power management

[Vivek Gautam]

Hi Felipe,


On Wed, Apr 3, 2013 at 1:45 PM, Felipe Balbi  wrote:
> Hi,
>
> On Wed, Apr 03, 2013 at 11:48:39AM +0530, Vivek Gautam wrote:
>> >> Adding  APIs to handle runtime power management on PHY
>> >> devices. PHY consumers may need to wake-up/suspend PHYs
>> >> when they work across autosuspend.
>> >>
>> >> Signed-off-by: Vivek Gautam 
>> >> ---
>> >>   include/linux/usb/phy.h |  141
>> >> +++
>> >>   1 files changed, 141 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
>> >> index 6b5978f..01bf9c1 100644
>> >> --- a/include/linux/usb/phy.h
>> >> +++ b/include/linux/usb/phy.h
>> >> @@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
>> >> usb_phy_type type)
>> >> return "UNKNOWN PHY TYPE";
>> >> }
>> >>   }
>> >> +
>> >> +static inline void usb_phy_autopm_enable(struct usb_phy *x)
>> >> +{
>> >> +   if (!x || !x->dev) {
>> >> +   dev_err(x->dev, "no PHY or attached device available\n");
>> >> +   return;
>> >> +   }
>> >> +
>> >> +   pm_runtime_enable(x->dev);
>> >> +}
>> >
>> >
>> > IMO we need not have wrapper APIs for runtime_enable and runtime_disable
>> > here. Generally runtime_enable and runtime_disable is done in probe and
>> > remove of a driver respectively. So it's better to leave the
>> > runtime_enable/runtime_disable to be done in *phy provider* driver than
>> > having an API for it to be done by *phy user* driver. Felipe, what do you
>> > think?
>>
>> Thanks!!
>> That's very true, runtime_enable() and runtime_disable() calls are made by
>> *phy_provider* only. But a querry here.
>> Wouldn't in any case a PHY consumer might want to disable runtime_pm on PHY ?
>> Say, when consumer failed to suspend the PHY properly
>> (*put_sync(phy->dev)* fails), how much sure is the consumer about the
>> state of PHY ?
>
> no no, wait a minute. We might not want to enable runtime pm for the PHY
> until the UDC says it can handle runtime pm, no ? I guess this makes a
> bit of sense (at least in my head :-p).
>
> Imagine if PHY is runtime suspended but e.g. DWC3 isn't runtime pm
> enabled... Does it make sense to leave that control to the USB
> controller drivers ?
>
> I'm open for suggestions

Of course unless the PHY consumer can handle runtime PM for PHY,
PHY should not ideally be going into runtime_suspend.

Actually trying out few things, here are my observations

Enabling runtime_pm on PHY pushes PHY to go into runtime_suspend state.
But a device detection wakes up DWC3 controller, and if i don't wake
up PHY (using get_sync(phy->dev)) here
in runtime_resume() callback of DWC3, i don't get PHY back in active state.
So it becomes the duty of DWC3 controller to handle PHY's sleep and wake-up.
Thereby it becomes logical that DWC3 controller has the right to
enable runtime_pm
of PHY.

But there's a catch here. if there are multiple consumers of PHY (like
USB2 type PHY can
have DWC3 controller as well as EHCI/OHCI or even HSGadget) then in that case,
only one of the consumer can enable runtime_pm on PHY. So who decides this.

Aargh!! lot of confusion here :-(


>
> --
> balbi



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] Add implicit barriers to irqsave/restore class of functions

[Christian Ruppert]

This patch adds implicit memory barriers to irqsave/restore functions of
the ARC architecture port in line with what is done in other architectures.

It seems to fix several seemingly unrelated issues in our platform but for
the moment it is insufficiently tested (and might even be incomplete).
Please comment.

Signed-off-by: Christian Ruppert 
---
 arch/arc/include/asm/irqflags.h |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arc/include/asm/irqflags.h b/arch/arc/include/asm/irqflags.h
index ccd8480..c8147d1 100644
--- a/arch/arc/include/asm/irqflags.h
+++ b/arch/arc/include/asm/irqflags.h
@@ -39,7 +39,7 @@ static inline long arch_local_irq_save(void)
"   flag.nz %0  \n"
: "=r"(temp), "=r"(flags)
: "n"((STATUS_E1_MASK | STATUS_E2_MASK))
-   : "cc");
+   : "memory", "cc");
 
return flags;
 }
@@ -53,7 +53,7 @@ static inline void arch_local_irq_restore(unsigned long flags)
__asm__ __volatile__(
"   flag %0 \n"
:
-   : "r"(flags));
+   : "r"(flags) : "memory");
 }
 
 /*
@@ -73,7 +73,7 @@ static inline void arch_local_irq_disable(void)
"   and %0, %0, %1  \n"
"   flag %0 \n"
: "="(temp)
-   : "n"(~(STATUS_E1_MASK | STATUS_E2_MASK)));
+   : "n"(~(STATUS_E1_MASK | STATUS_E2_MASK)) : "memory");
 }
 
 /*
@@ -85,7 +85,7 @@ static inline long arch_local_save_flags(void)
 
__asm__ __volatile__(
"   lr  %0, [status32]  \n"
-   : "="(temp));
+   : "="(temp) : : "memory");
 
return temp;
 }
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] efi: Distinguish between "remaining space" and actually used space

[Matt Fleming]

On 01/04/13 16:14, Matthew Garrett wrote:
> @@ -452,8 +462,33 @@ check_var_size_locked(struct efivars *efivars, u32 
> attributes,
>   if (status != EFI_SUCCESS)
>   return status;
>  
> - if (!storage_size || size > remaining_size || size > max_size ||
> - (remaining_size - size) < (storage_size / 2))
> + list_for_each_entry(entry, >list, list) {
> + var = >var;
> + status = get_var_data_locked(efivars, var);
> +
> + if (status || !(var->Attributes & EFI_VARIABLE_NON_VOLATILE))
> + continue;
> +
> + active_size += var->DataSize;
> + active_size += utf16_strsize(var->VariableName, 1024);
> + /*
> +  * There's some additional metadata associated with each
> +  * variable. Intel's reference implementation is 60 bytes -
> +  * bump that to 128 to account for vendor additions and
> +  * potential alignment constraints
> +  */
> + active_size += 128;
> + }

This is the kind of thing I was referring to when I said, 

  Hmm... I'm not convinced this will provide a long-term solution. Is there
  anything that mandates that the size of all variables has to correlate
  sensibly with the results from QueryVariableInfo()? Even if there is in
  theory, I doubt it'll be true everywhere in practice, and trying to
  workaround implementation bugs in our workarounds for other bugs is the
  path to madness.

  We can't continue this approach where we attempt to guess how the firmware
  implements variable storage, because as we've seen, there are various
  schemes out there. 

This looks like something that will differ between implementations, and the
fact that it's appearing in our code is a sure sign that this isn't the way to
go.

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] efi: Determine how much space is used by boot services-only variables

[Matt Fleming]

On 01/04/13 16:13, Matthew Garrett wrote:
> EFI variables can be flagged as being accessible only within boot services.
> This makes it awkward for us to figure out how much space they use at
> runtime. In theory we could figure this out by simply comparing the results
> from QueryVariableInfo() to the space used by all of our variables, but
> that fails if the platform doesn't garbage collect on every boot. Thankfully,
> calling QueryVariableInfo() while still inside boot services gives a more
> reliable answer. This patch passes that information from the EFI boot stub
> up to the efivars code, letting us calculate a reasonably accurate value.
> 
> Signed-off-by: Matthew Garrett 
> ---
>  arch/x86/boot/compressed/eboot.c  | 47 
> +++
>  arch/x86/include/asm/efi.h| 10 
>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>  arch/x86/platform/efi/efi.c   | 21 
>  drivers/firmware/efivars.c| 29 +
>  5 files changed, 108 insertions(+)

We're fixing a regression in efivars.c, but only for those users that
boot via the EFI boot stub? That seems likely to upset some people.

Introducing new features via the EFI boot stub is fine, and working
around firmware bugs so that we can use some feature is also cool, but
we can't start fixing regressions from other subsystems in the EFI boot
stub.

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -next] mxs/spi: fix error return code in mxs_spi_probe()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/spi/spi-mxs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 7b1c014..8498276 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -570,6 +570,7 @@ static int mxs_spi_probe(struct platform_device *pdev)
ssp->dmach = dma_request_slave_channel(>dev, "rx-tx");
if (!ssp->dmach) {
dev_err(ssp->dev, "Failed to request DMA\n");
+   ret = -ENODEV;
goto out_master_free;
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] timer: Fix possible issues with non serialized timer_pending( )

[Christian Ruppert]

Hello Vineet,

In the following a patch for a seemingly unrelated problem (RB-trees in
hrtimer implementation) which seems to fix the original problem at the
same time. For the moment, this patch is insufficiently tested but I am
posting it here (preliminarily) since it seems to be in line with
Thomas' comment: The implementation of irqsave/restore in other
architectures (MIPS, ARM) imply memory barriers and adding this implicit
barrier to ARC code as well seems to stabilise some of our remaining
crashes.

Greetings,
  Christian

On Wed, Apr 03, 2013 at 02:36:59PM +0200, Thomas Gleixner wrote:
> Vineet,
> 
> On Fri, 29 Mar 2013, Vineet Gupta wrote:
> 
> > When stress testing ARC Linux from 3.9-rc3, we've hit a serialization
> > issue when mod_timer() races with itself. This is on a FPGA board and
> > kernel .config among others has !SMP and !PREEMPT_COUNT.
> > 
> > The issue happens in mod_timer( ) because timer_pending( ) based early
> > exit check is NOT done inside the timer base spinlock - as a networking
> > optimization.
> > 
> > The value used in there, timer->entry.next is also used further in call
> > chain (all inlines though) for actual list manipulation. However if the
> > register containing this pointer remains live across the spinlock (in a
> > UP setup with !PREEMPT_COUNT there's nothing forcing gcc to reload) then
> > a stale value of next pointer causes incorrect list manipulation,
> > observed with following sequence in our tests.
> > 
> > (0). tv1[x] <> t1 <---> t2
> > (1). mod_timer(t1) interrupted after it calls timer_pending()
> > (2). mod_timer(t2) completes
> > (3). mod_timer(t1) resumes but messes up the list.
> > (4). __runt_timers( ) uses bogus timer_list entry / crashes in
> >  timer->function
> > 
> > The simplest fix is to NOT rely on spinlock based compiler barrier but
> > add an explicit one in timer_pending()
> 
> That's simple, but dangerous. There is other code which relies on the
> implicit barriers of spinlocks, so I think we need to add the barrier
> to the !PREEMPT_COUNT implementation of preempt_*() macros.
> 
> Thanks,
> 
>   tglx
> 
> > FWIW, the relevant ARCompact disassembly of mod_timer which clearly
> > shows the issue due to register reuse is:
> > 
> > mod_timer:
> > push_s blink
> > mov_s r13,r0# timer, timer
> > 
> > ...
> > ## timer_pending( )
> > ld_s r3,[r13]   # <-- .entry.next LOADED
> > brne r3, 0, @.L163
> > 
> > .L163:
> > 
> > ## spin_lock_irq( )
> > lr  r5, [status32]  # flags
> > bic r4, r5, 6   # temp, flags,
> > and.f 0, r5, 6  # flags,
> > flag.nz r4
> > 
> > ## detach_if_pending( ) begins
> > 
> > tst_s r3,r3  <--
> > # timer_pending( ) checks timer->entry.next
> > # r3 is NOT reloaded by gcc, using stale value
> > beq.d @.L169
> > mov.eq r0,0
> > 
> > #  detach_timer( ): __list_del( )
> > 
> > ld r4,[r13,4]   # .entry.prev, D.31439
> > st r4,[r3,4]# .prev, D.31439
> > st r3,[r4]  # .next, D.30246
> > 
> > Signed-off-by: Vineet Gupta 
> > Reported-by: Christian Ruppert 
> > Cc: Thomas Gleixner 
> > Cc: Christian Ruppert 
> > Cc: Pierrick Hascoet 
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  include/linux/timer.h |   11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/linux/timer.h b/include/linux/timer.h
> > index 8c5a197..1537104 100644
> > --- a/include/linux/timer.h
> > +++ b/include/linux/timer.h
> > @@ -168,7 +168,16 @@ static inline void init_timer_on_stack_key(struct 
> > timer_list *timer,
> >   */
> >  static inline int timer_pending(const struct timer_list * timer)
> >  {
> > -   return timer->entry.next != NULL;
> > +   int pending = timer->entry.next != NULL;
> > +
> > +   /*
> > +* The check above enables timer fast path - early exit.
> > +* However most of the call sites are not protected by timer->base
> > +* spinlock. If the caller (say mod_timer) races with itself, it
> > +* can use the stale "next" pointer. See commit log for details.
> > +*/
> > +   barrier();
> > +   return pending;
> >  }
> >  
> >  extern void add_timer_on(struct timer_list *timer, int cpu);
> > -- 
> > 1.7.10.4
> > 
> > 

-- 
  Christian Ruppert  ,  
/|
  Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri
 _// | bilis Systems   CH-1228 Plan-les-Ouates
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/7] memcg: don't use mem_cgroup_get() when creating a kmemcg cache

[Glauber Costa]

On 04/03/2013 01:12 PM, Li Zefan wrote:
> Use css_get()/css_put() instead of mem_cgroup_get()/mem_cgroup_put().
> 
> Signed-off-by: Li Zefan 
> ---
>  mm/memcontrol.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 43ca91d..dafacb8 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3191,7 +3191,7 @@ void memcg_release_cache(struct kmem_cache *s)
>   list_del(>memcg_params->list);
>   mutex_unlock(>slab_caches_mutex);
>  
> - mem_cgroup_put(memcg);
> + css_put(>css);
>  out:
>   kfree(s->memcg_params);
>  }
> @@ -3350,16 +3350,18 @@ static struct kmem_cache 
> *memcg_create_kmem_cache(struct mem_cgroup *memcg,
>  
>   mutex_lock(_cache_mutex);
>   new_cachep = cachep->memcg_params->memcg_caches[idx];
> - if (new_cachep)
> + if (new_cachep) {
> + css_put(>css);
>   goto out;
> + }
>  
>   new_cachep = kmem_cache_dup(memcg, cachep);
>   if (new_cachep == NULL) {
>   new_cachep = cachep;
> + css_put(>css);
>   goto out;
>   }
>  
> - mem_cgroup_get(memcg);
>   atomic_set(_cachep->memcg_params->nr_pages , 0);
>  
>   cachep->memcg_params->memcg_caches[idx] = new_cachep;
> @@ -3449,8 +3451,6 @@ static void memcg_create_cache_work_func(struct 
> work_struct *w)
>  
>   cw = container_of(w, struct create_work, work);
>   memcg_create_kmem_cache(cw->memcg, cw->cachep);
> - /* Drop the reference gotten when we enqueued. */
> - css_put(>memcg->css);
>   kfree(cw);
>  }
>  
> 
At first look, this one seems all right.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Suggestion] ARM64:kernel: compiling issue for early_console.

[Chen Gang]

On 2013年04月03日 19:39, Christopher Covington wrote:
> Maybe somebody else does have a fix, but Catalin mentioned he was going on
> vacation for two weeks on March 28th in "[GIT PULL] Preparatory GIC patches
> for arm64 support".
> 
  ok, I can wait.

>> >   if really no one fix it within this week, I should try (since I find it).
> I'm sure a fix would be appreciated.
> 

  ok, thanks. I prefer to wait (at least for the end of Catalin's vacation).


>> > On 2013年03月27日 20:02, Chen Gang wrote:
>>> >> On 2013年03月27日 19:55, Catalin Marinas wrote:
 >>>
 >>> I saw some patches from tglx on unifying the various early printk
 >>> implementations, though not sure whether it's those patches causing it
 >>> (in which case arm64 needs to be updated as well).
> I looked briefly and wasn't able to find this patchset.

  ok, thank for your results.


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers/block/xen-blkback: preq.dev is used without initialized

[Jan Beulich]

>>> On 03.04.13 at 14:56, William Dauchy  wrote:
> On Thu, Feb 28, 2013 at 3:34 AM, Chen Gang  wrote:
>> additional information:
>>   before commit 01c681d4c70d64cb72142a2823f27c4146a02e63, the value printed
>>   here was bogus, as it was the guest provided value from req->u.rw.handle
>>   rather than the actual device.
>>
>> Signed-off-by: Chen Gang 
>> Acked-by: Jan Beulich 
> 
> Sorry I'm a bit late but since since 01c681d is in stable, I guess
> a72d900 (xen/xen-blkback: preq.dev is used without initialized)
> could be added in stable as well.
> Am I wrong? otherwise I'm ok to do the request.

Iirc we requested the earlier commit to be removed from stable
trees, and I think Greg also did so.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/7] memcg: use css_get in sock_update_memcg()

[Glauber Costa]

On 04/03/2013 01:11 PM, Li Zefan wrote:
> Use css_get/css_put instead of mem_cgroup_get/put.
> 
> Note, if at the same time someone is moving @current to a different
> cgroup and removing the old cgroup, css_tryget() may return false,
> and sock->sk_cgrp won't be initialized.
> 
> Signed-off-by: Li Zefan 
> ---
>  mm/memcontrol.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 23d0f6e..43ca91d 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -536,15 +536,15 @@ void sock_update_memcg(struct sock *sk)
>*/
>   if (sk->sk_cgrp) {
>   BUG_ON(mem_cgroup_is_root(sk->sk_cgrp->memcg));
> - mem_cgroup_get(sk->sk_cgrp->memcg);
> + css_get(>sk_cgrp->memcg->css);
>   return;
>   }
>  
>   rcu_read_lock();
>   memcg = mem_cgroup_from_task(current);
>   cg_proto = sk->sk_prot->proto_cgroup(memcg);
> - if (!mem_cgroup_is_root(memcg) && memcg_proto_active(cg_proto)) 
> {
> - mem_cgroup_get(memcg);
> + if (!mem_cgroup_is_root(memcg) &&
> + memcg_proto_active(cg_proto) && css_tryget(>css)) {
>   sk->sk_cgrp = cg_proto;
>   }

What happens if this tryget fails ? Won't we leak a reference here? We
will put regardless when the socket is released, and this may go
negative. No?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 2/6] usb: phy: omap-usb2: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framework
will break OTG. Once we have a separate OTG state machine, we
can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/phy/omap-usb2.c |   48 +++
 1 file changed, 48 insertions(+)

diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 844ab68..4e48db4 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -119,9 +120,49 @@ static int omap_usb2_suspend(struct usb_phy *x, int 
suspend)
return 0;
 }
 
+static int omap_usb_suspend(struct phy *x)
+{
+   struct omap_usb *phy = dev_get_drvdata(>dev);
+
+   if (!phy->is_suspended) {
+   omap_control_usb_phy_power(phy->control_dev, 0);
+   pm_runtime_put_sync(phy->dev);
+   phy->is_suspended = 1;
+   }
+
+   return 0;
+}
+
+static int omap_usb_resume(struct phy *x)
+{
+   u32 ret;
+   struct omap_usb *phy = dev_get_drvdata(>dev);
+
+   if (phy->is_suspended) {
+   ret = pm_runtime_get_sync(phy->dev);
+   if (ret < 0) {
+   dev_err(phy->dev, "get_sync failed with err %d\n",
+   ret);
+   return ret;
+   }
+   omap_control_usb_phy_power(phy->control_dev, 1);
+   phy->is_suspended = 0;
+   }
+
+   return 0;
+}
+
+static struct phy_ops ops = {
+   .suspend= omap_usb_suspend,
+   .resume = omap_usb_resume,
+   .of_xlate   = of_phy_xlate,
+   .owner  = THIS_MODULE,
+};
+
 static int omap_usb2_probe(struct platform_device *pdev)
 {
struct omap_usb *phy;
+   struct phy  *generic_phy;
struct usb_otg  *otg;
 
phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
@@ -144,6 +185,13 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg= otg;
phy->phy.type   = USB_PHY_TYPE_USB2;
 
+   generic_phy = devm_phy_create(phy->dev, "omap-usb2", pdev->dev.of_node,
+   USB_PHY_TYPE_USB2, , phy);
+   if (IS_ERR(generic_phy)) {
+   dev_dbg(>dev, "Failed to create PHY\n");
+   return PTR_ERR(generic_phy);
+   }
+
phy->control_dev = omap_get_control_dev();
if (IS_ERR(phy->control_dev)) {
dev_dbg(>dev, "Failed to get control device\n");
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] drivers/block/xen-blkback: preq.dev is used without initialized

[William Dauchy]

Hello,

On Thu, Feb 28, 2013 at 3:34 AM, Chen Gang  wrote:
> additional information:
>   before commit 01c681d4c70d64cb72142a2823f27c4146a02e63, the value printed
>   here was bogus, as it was the guest provided value from req->u.rw.handle
>   rather than the actual device.
>
> Signed-off-by: Chen Gang 
> Acked-by: Jan Beulich 

Sorry I'm a bit late but since since 01c681d is in stable, I guess
a72d900 (xen/xen-blkback: preq.dev is used without initialized)
could be added in stable as well.
Am I wrong? otherwise I'm ok to do the request.

Regards,

--
William
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 6/6] usb: musb: omap2430: use the new generic PHY framework

[Kishon Vijay Abraham I]

Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.

musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state machine to handle otg, these can be
moved out of xceiv and then we can start using the generic PHY framework.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/musb_core.h |2 ++
 drivers/usb/musb/omap2430.c  |   22 --
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 7fb4819..78251fd 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct musb;
 struct musb_hw_ep;
@@ -357,6 +358,7 @@ struct musb {
u16 int_tx;
 
struct usb_phy  *xceiv;
+   struct phy  *phy;
 
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a42a45..55f071d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -349,14 +349,24 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   if (dev->parent->of_node)
+   if (dev->parent->of_node) {
+   musb->phy = devm_of_phy_get_byname(dev->parent, "usb2-phy");
+
+   /* We can't totally remove musb->xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
"usb-phy", 0);
-   else
+   } else {
musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+   musb->phy = devm_phy_get(dev, 0);
+   }
 
-   if (IS_ERR_OR_NULL(musb->xceiv)) {
-   pr_err("HS USB OTG: no transceiver configured\n");
+   if (IS_ERR_OR_NULL(musb->xceiv) || IS_ERR(musb->phy)) {
+   dev_err(dev, "no transceiver configured\n");
return -EPROBE_DEFER;
}
 
@@ -612,7 +622,7 @@ static int omap2430_runtime_suspend(struct device *dev)
OTG_INTERFSEL);
 
omap2430_low_level_exit(musb);
-   usb_phy_set_suspend(musb->xceiv, 1);
+   phy_suspend(musb->phy);
}
 
return 0;
@@ -628,7 +638,7 @@ static int omap2430_runtime_resume(struct device *dev)
musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
 
-   usb_phy_set_suspend(musb->xceiv, 0);
+   phy_resume(musb->phy);
}
 
return 0;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 3/6] usb: otg: twl4030: use the new generic PHY framework

[Kishon Vijay Abraham I]

Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.

However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework completely will break OTG. Once we have a separate OTG state machine,
we can get rid of the USB PHY library.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/otg/twl4030-usb.c |   37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index a994715..6dab049 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -575,10 +576,39 @@ static int twl4030_set_host(struct usb_otg *otg, struct 
usb_bus *host)
return 0;
 }
 
+static int twl4030_usb_suspend(struct phy *phy)
+{
+   struct twl4030_usb *twl = dev_get_drvdata(>dev);
+
+   twl4030_phy_suspend(twl, 1);
+
+   return 0;
+}
+
+static int twl4030_usb_resume(struct phy *phy)
+{
+   struct twl4030_usb *twl = dev_get_drvdata(>dev);
+
+   if (!twl->asleep)
+   return -EBUSY;
+   __twl4030_phy_resume(twl);
+   twl->asleep = 0;
+
+   return 0;
+}
+
+static struct phy_ops ops = {
+   .suspend= twl4030_usb_suspend,
+   .resume = twl4030_usb_resume,
+   .of_xlate   = of_phy_xlate,
+   .owner  = THIS_MODULE,
+};
+
 static int twl4030_usb_probe(struct platform_device *pdev)
 {
struct twl4030_usb_data *pdata = pdev->dev.platform_data;
struct twl4030_usb  *twl;
+   struct phy  *phy;
int status, err;
struct usb_otg  *otg;
struct device_node  *np = pdev->dev.of_node;
@@ -617,6 +647,13 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg->set_host   = twl4030_set_host;
otg->set_peripheral = twl4030_set_peripheral;
 
+   phy = devm_phy_create(twl->dev, "twl4030", pdev->dev.of_node,
+   USB_PHY_TYPE_USB2, , twl);
+   if (IS_ERR(phy)) {
+   dev_dbg(>dev, "Failed to create PHY\n");
+   return PTR_ERR(phy);
+   }
+
/* init spinlock for workqueue */
spin_lock_init(>lock);
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 4/6] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/usb-musb.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..f01bc42 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "omap_device.h"
 #include "soc.h"
@@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data 
*musb_board_data)
musb_plat.mode = board_data->mode;
musb_plat.extvbus = board_data->extvbus;
 
-   if (cpu_is_omap44xx())
+   if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+   phy_bind("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
+   } else if (cpu_is_omap34xx()) {
+   phy_bind("musb-hdrc.0.auto", 0, "twl4030_usb");
+   }
 
if (soc_is_am35xx()) {
oh_name = "am35x_otg_hs";
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 0/6] Generic PHY Framework

[Kishon Vijay Abraham I]

Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
without using phandle, the platform specfic intialization code (say from board
file) should have already called phy_bind with the binding information. The
binding information consists of phy's device name, phy user device name and an
index. The index is used when the same phy user binds to mulitple phys.

This framework will be of use only to devices that uses external PHY (PHY
functionality is not embedded within the controller).

The intention of creating this framework is to bring the phy drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and to
increase code maintainability.

Comments to make PHY as bus wasn't done because PHY devices can be part of
other bus and making a same device attached to multiple bus leads to bad
design.

Making omap-usb2 and twl4030 to use this framework is provided as a sample.

This patch series is developed on linus tree HEAD. Once the patch series gets
finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree.

Changes from v4:
* removed of_phy_get_with_args/devm_of_phy_get_with_args. Now the *phy 
providers*
  should use their custom implementation of of_xlate or use of_phy_xlate to get
  *phy instance* from *phy providers*.
* Added of_phy_xlate to be used by *phy providers* if it provides only one PHY.
* changed phy_core from having subsys_initcall to module_init.
* other minor fixes.

Changes from v3:
* Changed the return value of PHY APIs to ENOSYS
* Added APIs of_phy_get_with_args/devm_of_phy_get_with_args to support getting
  PHYs if the same IP implements multiple PHYs.
* modified phy_bind API so that the binding information can now be _updated_.
  In effect of this removed the binding information added in board files and
  added only in usb-musb.c. If a particular board uses a different phy binding,
  it can update it in board file after usb_musb_init().
* Added Documentation/devicetree/bindings/phy/phy-bindings.txt for dt binding
  information.

Changes from v2:
* removed phy_descriptor structure completely so changed the APIs which were
  taking phy_descriptor as parameters
* Added 2 more APIs *of_phy_get_byname* and *devm_of_phy_get_byname* to be used
  by PHY user drivers which has *phy* and *phy-names* binding in the dt data
* Fixed a few typos
* Removed phy_list and we now use class_dev_iter_init, class_dev_iter_next and
  class_dev_iter_exit for traversing through the phy list. (Note we still need
  phy_bind list and phy_bind_mutex).
* Changed the sysfs entry name from *bind* to *phy_bind*.

Changes from v1:
* Added Documentation for the PHY framework
* Added few more APIs mostly w.r.t devres
* Modified omap-usb2 and twl4030 to make use of the new framework

Did USB enumeration testing in panda and beagle.

Kishon Vijay Abraham I (6):
  drivers: phy: add generic PHY framework
  usb: phy: omap-usb2: use the new generic PHY framework
  usb: otg: twl4030: use the new generic PHY framework
  ARM: OMAP: USB: Add phy binding information
  ARM: dts: omap: update usb_otg_hs data
  usb: musb: omap2430: use the new generic PHY framework

 Documentation/ABI/testing/sysfs-class-phy  |   15 +
 .../devicetree/bindings/phy/phy-bindings.txt   |   67 +++
 Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
 Documentation/devicetree/bindings/usb/usb-phy.txt  |6 +
 Documentation/phy.txt  |  113 
 MAINTAINERS|7 +
 arch/arm/boot/dts/omap3.dtsi   |2 +
 arch/arm/boot/dts/omap4.dtsi   |3 +
 arch/arm/boot/dts/twl4030.dtsi |1 +
 arch/arm/mach-omap2/usb-musb.c |7 +-
 drivers/Kconfig|2 +
 drivers/Makefile   |2 +
 drivers/phy/Kconfig|   13 +
 drivers/phy/Makefile   |5 +
 drivers/phy/phy-core.c |  616 
 drivers/usb/musb/musb_core.h   |2 +
 drivers/usb/musb/omap2430.c|   22 +-
 drivers/usb/otg/twl4030-usb.c  |   37 ++
 drivers/usb/phy/omap-usb2.c|   48 ++
 include/linux/phy/phy.h|  228 
 20 files changed, 1194 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-phy
 create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
 create mode 100644 Documentation/phy.txt
 create mode 100644 drivers/phy/Kconfig
 create mode 100644 drivers/phy/Makefile
 create mode 100644 drivers/phy/phy-core.c
 create mode 100644 include/linux/phy/phy.h

-- 
1.7.10.4

--
To unsubscribe from this