Re: [GIT PULL] optimize 64-by-32 ddivision for constant divisors on 32-bit machines

[Arnd Bergmann]

On Sunday 22 November 2015 17:28:33 Nicolas Pitre wrote:
> On Sun, 22 Nov 2015, Arnd Bergmann wrote:
> > On Monday 16 November 2015 20:20:38 you wrote:
> > I'm now getting a build regressing with the attached randconfig 
> > configuration,
> > when compiling drivers/net/wireless/iwlegacy/common.o:
> > 
> > drivers/built-in.o: In function `il_send_rxon_timing':
> > :(.text+0xbbac80): undefined reference to `__aeabi_uldivmod'
> > :(.text+0xbbac9c): undefined reference to `__aeabi_uldivmod'
> > :(.text+0xbbacdc): undefined reference to `__aeabi_uldivmod'
> > :(.text+0xbbadc8): undefined reference to `__aeabi_uldivmod'
> > :(.text+0xbbadf8): undefined reference to `__aeabi_uldivmod'
> > :(.text+0xbbae3c): more undefined references to `__aeabi_uldivmod' follow
> > drivers/built-in.o: In function `il_send_rxon_timing':
> > :(.text+0xbbb11c): undefined reference to `ilog2_NaN'
> 
> This looks like some gcc bug from a few years ago.

Yes, I clearly remember debugging something in this area before,
but I don't remember what we did about it.

We already have the workaround for OABI (which you kept), and I have
another workaround to disable the optimized function for ARMv3 as
well, as newer gcc versions also get that wrong here (internal compiler
error IIRC).

We could add yet another such workaround for CONFIG_PROFILE_ALL_BRANCHES,
but I don't have a good feeling about doing this unless we understand
well enough why it breaks. At some point, I did this workaround, which
is still in my randconfig tree:

--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -144,7 +144,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int 
val, int expect);
  */
 #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
 #define __trace_if(cond) \
-   if (__builtin_constant_p((cond)) ? !!(cond) :   \
+   if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
({  \
int __r;\
static struct ftrace_branch_data\

However, it doesn't seem related to the problem at hand. I think it was
about some false 'maybe uninitialized' warning, but I currently don't see any
difference with or without that patch for either issues.

> > I've verified that this goes away if I turn off CONFIG_PROFILE_ALL_BRANCHES,
> > and it only shows up with gcc-5.0 through gcc-5.2.1, but not 4.9.3.
> > 
> > Aside from those, I have not been able to reduce the failure scenario.
> > 
> > Also, I have only tested on ARM32, no idea if this shows up elsewhere.
> 
> What if you revert "ARM: asm/div64.h: adjust to generic codde" and 
> recompile?

Without that patch, it works again.

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

[PATCH v2] sp5100_tco: Add AMD Mullins platform support

[Denis Turischev]

AMD Mullins watchdog is fully compatible to the previous Hudson chipset,
reuse the existent sp5100_tco driver.

v2: rebased to v4.4-rc2

Signed-off-by: Denis Turischev 

diff -Nru linux-4.4-rc2.orig/drivers/watchdog/sp5100_tco.c 
linux-4.4-rc2/drivers/watchdog/sp5100_tco.c
--- linux-4.4-rc2.orig/drivers/watchdog/sp5100_tco.c2015-11-23 
02:45:59.0 +0200
+++ linux-4.4-rc2/drivers/watchdog/sp5100_tco.c 2015-11-23 09:51:48.701245853 
+0200
@@ -306,6 +306,8 @@
 static const struct pci_device_id sp5100_tco_pci_tbl[] = {
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, PCI_ANY_ID,
  PCI_ANY_ID, },
+   { PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID,
+ PCI_ANY_ID, }, 
{ 0, }, /* End of list */
 };
 MODULE_DEVICE_TABLE(pci, sp5100_tco_pci_tbl);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Build regressions/improvements in v4.4-rc2

[Geert Uytterhoeven]

Below is the list of build error/warning regressions/improvements in
v4.4-rc2[1] compared to v4.3[2].

Summarized:
  - build errors: +13/-11
  - build warnings: +97/-101

JFYI, when comparing v4.4-rc2[1] to v4.4-rc1[3], the summaries are:
  - build errors: +11/-10
  - build warnings: +39/-54

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

As I haven't mastered kup yet, there's no verbose summary at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.4-rc2.summary.gz

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] http://kisskb.ellerman.id.au/kisskb/head/9622/ (256 out of 254 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/9535/ (256 out of 254 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/9597/ (255 out of 254 configs)


*** ERRORS ***

13 error regressions:
  + /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: 'cached_to_uncached' 
undeclared (first use in this function):  => 99:17
  + /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: implicit declaration 
of function 'cpu_context' [-Werror=implicit-function-declaration]:  => 192:2
  + /home/kisskb/slave/src/net/sched/sch_dsmark.c: error: unrecognizable insn:: 
 => 316:1
  + error: debugfs.c: undefined reference to `clk_round_rate':  => 
.text+0x364fb0), .text+0x38af08), .text+0x38b054)
  + error: debugfs.c: undefined reference to `clk_set_parent':  => 
.text+0x16d5d0)
  + error: debugfs.c: undefined reference to `clk_set_rate':  => 
.text+0x3940fc), .text+0x128820), .text+0x392fbc), .text+0x3651a4), 
.text+0x167080), .text+0x1285e0), .text+0x128604), .text+0x394070), 
.text+0x297834), .text+0x1f2334), .text+0x36526c), .text+0x38b0cc), 
.text+0x171ddc)
  + error: e1000_hw.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.__dynamic_netdev_dbg' defined in .text section in lib/built-in.o:  => 
(.text+0x1ff8420), (.text+0x1ff8680)
  + error: e1000_hw.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `.udelay' defined in .text section in arch/powerpc/kernel/built-in.o:  
=> (.text+0x1ff7a10), (.text+0x1ff7bd0), (.text+0x1ff830c), (.text+0x1ff850c)
  + error: e1000_hw.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_restgpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff7bf0), (.text+0x1ff7a30)
  + error: e1000_hw.c: relocation truncated to fit: R_PPC64_REL24 against 
symbol `_savegpr0_30' defined in .text.save.restore section in 
arch/powerpc/lib/built-in.o:  => (.text+0x1ff7a38), (.text+0x1ff787c)
  + error: last.c: undefined reference to `clk_round_rate':  => .text+0x7e388), 
.text+0x71918), .text+0x72ba0), .text+0xd186c), .text+0x79668), .text+0x7ae88)
  + error: last.c: undefined reference to `clk_set_parent':  => .text+0xd3f38), 
.text+0xd3f58), .text+0xd79c8), .text+0xccde8)
  + error: last.c: undefined reference to `clk_set_rate':  => .text+0xd3f64), 
.text+0x7e398), .text+0x7ae98), .text+0xd96b4), .text+0xa7fd0), .text+0x71928), 
.text+0xcdc5c), .text+0xd921c), .text+0xd92a4), .text+0xcae30), .text+0x79678), 
.text+0xdd2c4), .text+0xdc494), .text+0x72bb0), .text+0xd19a0)

11 error improvements:
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'early_init_dt_scan_nodes' 
[-Werror=implicit-function-declaration]: 244:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'early_init_dt_verify' 
[-Werror=implicit-function-declaration]: 215:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_flat_dt_match_machine' 
[-Werror=implicit-function-declaration]: 218:2 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_get_flat_dt_prop' 
[-Werror=implicit-function-declaration]: 229:3 => 
  - /home/kisskb/slave/src/arch/arm/kernel/devtree.c: error: implicit 
declaration of function 'of_get_flat_dt_root' 
[-Werror=implicit-function-declaration]: 228:3 => 
  - /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit declaration 
of function 'free_dma' [-Werror=implicit-function-declaration]: 11384:3 => 
  - /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit declaration 
of function 'request_dma' [-Werror=implicit-function-declaration]: 11300:4 => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' 
defined in .text section in arch/powerpc/kernel/entry_64.o: (.text+0x1ff8804), 
(.text+0x1ff90c8), (.text+0x1ff8c08), (.text+0x1ff8a78), (.text+0x1ff8ac0), 
(.text+0x1ff8684) => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.eeh_check_failure' defined in .text section in 
arch/powerpc/kernel/built-in.o: (.text+0x1ff8ec4), (.text+0x1ff8fc0) => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`_restgpr0_22' defined in .text.save.restore section in 
arch/powerpc/lib/bu

Re: lapic_suspend/lapic_resume wrong?

[Ingo Molnar]

* Juergen Gross  wrote:

> Hi,
> 
> while trying to find the reason for a hanging kernel during resume
> handling I found a strange inconsistency in arch/x86/kernel/apic/apic.c
> regarding usage of config options.
> 
> Attached patch addresses this, no test done as I'm not sure whether
> this is a correct approach. Can you have a look at it, please?
> 
> 
> Juergen
>
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 2f69e3b..bc06c9d 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -2270,6 +2270,7 @@ static struct {
>   unsigned int apic_tmict;
>   unsigned int apic_tdcr;
>   unsigned int apic_thmr;
> + unsigned int apic_cmci;
>  } apic_pm_state;
>  
>  static int lapic_suspend(void)
> @@ -2299,6 +2300,10 @@ static int lapic_suspend(void)
>   if (maxlvt >= 5)
>   apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
>  #endif
> +#ifdef CONFIG_X86_MCE_INTEL
> + if (maxlvt >= 6)
> + apic_pm_state.apic_cmci = apic_read(APIC_LVTCMCI);
> +#endif
>  
>   local_irq_save(flags);
>   disable_local_APIC();
> @@ -2355,10 +2360,14 @@ static void lapic_resume(void)
>   apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
>   apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
>   apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
> -#if defined(CONFIG_X86_MCE_INTEL)
> +#if defined(CONFIG_X86_THERMAL_VECTOR)
>   if (maxlvt >= 5)
>   apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
>  #endif
> +#if defined(CONFIG_X86_MCE_INTEL)
> + if (maxlvt >= 6)
> + apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci);
> +#endif
>   if (maxlvt >= 4)
>   apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
>   apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);

the x86 bit looks absolutely sensible to me.

Have you checked whether we indeed lose this value over S/R, or is this mostly 
working fine by accident, due to us executing the CMCI vector initialization 
via:

  
mce_syscore_resume()->__mcheck_cpu_init_vendor()->mce_intel_feature_init()->intel_init_cmci()
 

on every resume event?

The Xen fix is unrelated, just put into the same patch, right?

Thanks,

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

[PATCH v2 2/5] clk: sunxi: Add driver for the H3 THS clock

[Josef Gajdusek]

This patch adds a driver for the THS clock which is present on the
Allwinner H3.

Signed-off-by: Josef Gajdusek 
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 drivers/clk/sunxi/Makefile|  1 +
 drivers/clk/sunxi/clk-h3-ths.c| 98 +++
 3 files changed, 100 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-h3-ths.c

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 23e7bce..6d63b35 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -73,6 +73,7 @@ Required properties:
"allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
+   "allwinner,sun8i-h3-ths-clk" - for THS on H3
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index f520af6..1bf8e1c 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -8,6 +8,7 @@ obj-y += clk-a10-hosc.o
 obj-y += clk-a10-mod1.o
 obj-y += clk-a10-pll2.o
 obj-y += clk-a20-gmac.o
+obj-y += clk-h3-ths.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
 obj-y += clk-sun8i-bus-gates.o
diff --git a/drivers/clk/sunxi/clk-h3-ths.c b/drivers/clk/sunxi/clk-h3-ths.c
new file mode 100644
index 000..663afc0
--- /dev/null
+++ b/drivers/clk/sunxi/clk-h3-ths.c
@@ -0,0 +1,98 @@
+/*
+ * Sunxi THS clock driver
+ *
+ * Copyright (C) 2015 Josef Gajdusek
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define SUN8I_H3_THS_CLK_ENABLE31
+#define SUN8I_H3_THS_CLK_DIVIDER_SHIFT 0
+#define SUN8I_H3_THS_CLK_DIVIDER_WIDTH 2
+
+static DEFINE_SPINLOCK(sun8i_h3_ths_clk_lock);
+
+static const struct clk_div_table sun8i_h3_ths_clk_table[] __initconst = {
+   { .val = 0, .div = 1 },
+   { .val = 1, .div = 2 },
+   { .val = 2, .div = 4 },
+   { .val = 3, .div = 6 },
+   { } /* sentinel */
+};
+
+static void __init sun8i_h3_ths_clk_setup(struct device_node *node)
+{
+   struct clk *clk;
+   struct clk_gate *gate;
+   struct clk_divider *div;
+   const char *parent;
+   const char *clk_name = node->name;
+   void __iomem *reg;
+   int err;
+
+   reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+
+   if (IS_ERR(reg))
+   return;
+
+   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!gate)
+   goto err_unmap;
+
+   div = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!div)
+   goto err_gate_free;
+
+   of_property_read_string(node, "clock-output-names", &clk_name);
+   parent = of_clk_get_parent_name(node, 0);
+
+   gate->reg = reg;
+   gate->bit_idx = SUN8I_H3_THS_CLK_ENABLE;
+   gate->lock = &sun8i_h3_ths_clk_lock;
+
+   div->reg = reg;
+   div->shift = SUN8I_H3_THS_CLK_DIVIDER_SHIFT;
+   div->width = SUN8I_H3_THS_CLK_DIVIDER_WIDTH;
+   div->table = sun8i_h3_ths_clk_table;
+   div->lock = &sun8i_h3_ths_clk_lock;
+
+   clk = clk_register_composite(NULL, clk_name, &parent, 1,
+NULL, NULL,
+&div->hw, &clk_divider_ops,
+&gate->hw, &clk_gate_ops,
+CLK_SET_RATE_PARENT);
+
+   if (IS_ERR(clk))
+   goto err_div_free;
+
+   err = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+   if (err)
+   goto err_unregister_clk;
+
+   return;
+
+err_unregister_clk:
+   clk_unregister(clk);
+err_gate_free:
+   kfree(gate);
+err_div_free:
+   kfree(div);
+err_unmap:
+   iounmap(reg);
+}
+
+CLK_OF_DECLARE(sun8i_h3_ths_clk, "allwinner,sun8i-h3-ths-clk",
+  sun8i_h3_ths_clk_setup);
-- 
2.4.10

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

[PATCH v2 0/5] sunxi: THS support

[Josef Gajdusek]

Hello everyone,

this is v2 of my THS patchset

Changelog:

 * Some stylistic changes
 * devm_reset_control_get_optional -> devm_reset_control_get
 * Added the clk-h3-ths clock driver
   - Note: A23/A33/A83T do not have a separate clock, H3 seems to be the first
 (and only?) SoC with it
   - Because of this, I moved the clock init code to the H3-specific init
 function.
 * Use the nvmem cell abstraction instead of accessing the configuration memory 
directly
 * Use the IRQ line (and fixed incorrect interrupt number in the DTS)
 * Renamed to sun8i_ths

Ad the "magical constants": what I meant is that altough the datasheet explains
what they are, it does not explain how to pick their values. "ADC" and "Sensor"
"acquire time" are also not exactly the most helpful descriptions.
Anyway, I changed the values such as the final sampling rate is about 1Hz.

Josef Gajdusek (5):
  ARM: dts: sun8i: Add SID node
  clk: sunxi: Add driver for the H3 THS clock
  thermal: Add a driver for the Allwinner THS sensor
  dt-bindings: document sun8i_ths
  ARM: dts: sun8i: Add THS node to the H3 .dtsi

 Documentation/devicetree/bindings/clock/sunxi.txt  |   1 +
 .../devicetree/bindings/thermal/sun8i-ths.txt  |  31 ++
 arch/arm/boot/dts/sun8i-h3.dtsi|  40 +++
 drivers/clk/sunxi/Makefile |   1 +
 drivers/clk/sunxi/clk-h3-ths.c |  98 ++
 drivers/thermal/Kconfig|   7 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/sun8i_ths.c| 365 +
 8 files changed, 544 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-ths.txt
 create mode 100644 drivers/clk/sunxi/clk-h3-ths.c
 create mode 100644 drivers/thermal/sun8i_ths.c

-- 
2.4.10

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

[PATCH v2 3/5] thermal: Add a driver for the Allwinner THS sensor

[Josef Gajdusek]

This patch adds support for the Sunxi thermal sensor on the Allwinner H3.
Should be easily extendable for the A33/A83T/... as they have similar but
not completely identical sensors.

Signed-off-by: Josef Gajdusek 
---
 drivers/thermal/Kconfig |   7 +
 drivers/thermal/Makefile|   1 +
 drivers/thermal/sun8i_ths.c | 365 
 3 files changed, 373 insertions(+)
 create mode 100644 drivers/thermal/sun8i_ths.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index c463c89..2b41147 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -365,6 +365,13 @@ config INTEL_PCH_THERMAL
  Thermal reporting device will provide temperature reading,
  programmable trip points and other information.
 
+config SUN8I_THS
+   tristate "sun8i THS driver"
+   depends on MACH_SUN8I
+   depends on OF
+   help
+ Enable this to support thermal reporting on some newer Allwinner SoCs.
+
 menu "Texas Instruments thermal drivers"
 depends on ARCH_HAS_BANDGAP || COMPILE_TEST
 source "drivers/thermal/ti-soc-thermal/Kconfig"
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index cfae6a6..227e1a1 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -48,3 +48,4 @@ obj-$(CONFIG_INTEL_PCH_THERMAL)   += intel_pch_thermal.o
 obj-$(CONFIG_ST_THERMAL)   += st/
 obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra_soctherm.o
 obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
+obj-$(CONFIG_SUN8I_THS)+= sun8i_ths.o
diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c
new file mode 100644
index 000..2c976ac
--- /dev/null
+++ b/drivers/thermal/sun8i_ths.c
@@ -0,0 +1,365 @@
+/*
+ * Sunxi THS driver
+ *
+ * Copyright (C) 2015 Josef Gajdusek
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define THS_H3_CTRL0   0x00
+#define THS_H3_CTRL1   0x04
+#define THS_H3_CDAT0x14
+#define THS_H3_CTRL2   0x40
+#define THS_H3_INT_CTRL0x44
+#define THS_H3_STAT0x48
+#define THS_H3_ALARM_CTRL  0x50
+#define THS_H3_SHUTDOWN_CTRL   0x60
+#define THS_H3_FILTER  0x70
+#define THS_H3_CDATA   0x74
+#define THS_H3_DATA0x80
+
+#define THS_H3_CTRL0_SENSOR_ACQ0_OFFS   0
+#define THS_H3_CTRL0_SENSOR_ACQ0(x) \
+   ((x) << THS_H3_CTRL0_SENSOR_ACQ0_OFFS)
+#define THS_H3_CTRL1_ADC_CALI_EN_OFFS   17
+#define THS_H3_CTRL1_ADC_CALI_EN \
+   BIT(THS_H3_CTRL1_ADC_CALI_EN_OFFS)
+#define THS_H3_CTRL1_OP_BIAS_OFFS   20
+#define THS_H3_CTRL1_OP_BIAS(x) \
+   ((x) << THS_H3_CTRL1_OP_BIAS_OFFS)
+#define THS_H3_CTRL2_SENSE_EN_OFFS  0
+#define THS_H3_CTRL2_SENSE_EN \
+   BIT(THS_H3_CTRL2_SENSE_EN_OFFS)
+#define THS_H3_CTRL2_SENSOR_ACQ1_OFFS   16
+#define THS_H3_CTRL2_SENSOR_ACQ1(x) \
+   ((x) << THS_H3_CTRL2_SENSOR_ACQ1_OFFS)
+
+#define THS_H3_INT_CTRL_ALARM_INT_EN_OFFS   0
+#define THS_H3_INT_CTRL_ALARM_INT_EN \
+   BIT(THS_H3_INT_CTRL_ALARM_INT_EN_OFFS)
+#define THS_H3_INT_CTRL_SHUT_INT_EN_OFFS   4
+#define THS_H3_INT_CTRL_SHUT_INT_EN \
+   BIT(THS_H3_INT_CTRL_SHUT_INT_EN_OFFS)
+#define THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS   8
+#define THS_H3_INT_CTRL_DATA_IRQ_EN \
+   BIT(THS_H3_INT_CTRL_DATA_IRQ_EN_OFFS)
+#define THS_H3_INT_CTRL_THERMAL_PER_OFFS   12
+#define THS_H3_INT_CTRL_THERMAL_PER(x) \
+   ((x) << THS_H3_INT_CTRL_THERMAL_PER_OFFS)
+
+#define THS_H3_STAT_ALARM_INT_STS_OFFS  0
+#define THS_H3_STAT_ALARM_INT_STS \
+   BIT(THS_H3_STAT_ALARM_INT_STS_OFFS)
+#define THS_H3_STAT_SHUT_INT_STS_OFFS   4
+#define THS_H3_STAT_SHUT_INT_STS \
+   BIT(THS_H3_STAT_SHUT_INT_STS_OFFS)
+#define THS_H3_STAT_DATA_IRQ_STS_OFFS   8
+#define THS_H3_STAT_DATA_IRQ_STS \
+   BIT(THS_H3_STAT_DATA_IRQ_STS_OFFS)
+#define THS_H3_STAT_ALARM_OFF_STS_OFFS  12
+#define THS_H3_STAT_ALARM_OFF_STS \
+   BIT(THS_H3_STAT_ALARM_OFF_STS_OFFS)
+
+#define THS_H3_ALARM_CTRL_ALARM0_T_HYST_OFFS0
+#define THS_H3_ALARM_CTRL_ALARM0_T_HYST(x) \
+   ((x) << THS_H3_ALARM_CTRL_ALARM0_T_HYST_OFFS)
+#define THS_H3_ALARM_CTRL_ALARM0_T_HOT_OFFS 16
+#define THS_H3_ALARM_CTRL_ALARM0_T_HOT(x) \
+   ((x) << THS_H3_ALARM_CTRL_ALARM0_T_HOT_OFFS)
+
+#define THS_H3_SHUTDOWN_CTRL_SHUT0_T_HOT_OFFS   16
+#de

[PATCH v2 1/5] ARM: dts: sun8i: Add SID node

[Josef Gajdusek]

Add a node describing the Security ID memory to the
Allwinner H3 .dtsi file.

Signed-off-by: Josef Gajdusek 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 0faa38a..58de718 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -359,6 +359,13 @@
#size-cells = <0>;
};
 
+   sid: eeprom@01c14000 {
+   compatible = "allwinner,sun4i-a10-sid";
+   reg = <0x01c14000 0x400>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   };
+
usbphy: phy@01c19400 {
compatible = "allwinner,sun8i-h3-usb-phy";
reg = <0x01c19400 0x2c>,
-- 
2.4.10

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

[PATCH v2 5/5] ARM: dts: sun8i: Add THS node to the H3 .dtsi

[Josef Gajdusek]

This patch adds nodes for the THS driver and the THS clock to the Allwinner
H3 .dtsi file.

Signed-off-by: Josef Gajdusek 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 58de718..48500d4 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -77,6 +77,14 @@
};
};
 
+   thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>;
+   polling-delay = <5000>;
+   thermal-sensors = <&ths 0>;
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -236,6 +244,14 @@
"ahb1_ephy", "ahb1_dbg";
};
 
+   ths_clk: clk@01c20074 {
+   #clock-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths-clk";
+   reg = <0x01c20074 0x4>;
+   clocks = <&osc24M>;
+   clock-output-names = "ths";
+   };
+
mmc0_clk: clk@01c20088 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
@@ -364,6 +380,10 @@
reg = <0x01c14000 0x400>;
#address-cells = <1>;
#size-cells = <1>;
+
+   ths_calibration: calib@234 {
+   reg = <0x234 0x4>;
+   };
};
 
usbphy: phy@01c19400 {
@@ -529,6 +549,19 @@
interrupts = ;
};
 
+   ths: ths@01c25000 {
+   #thermal-sensor-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths";
+   reg = <0x01c25000 0x88>;
+   interrupts = ;
+   resets = <&bus_rst 104>;
+   reset-names = "ahb";
+   clocks = <&bus_gates 72>, <&ths_clk>;
+   clock-names = "ahb", "ths";
+   nvmem-cells = <&ths_calibration>;
+   nvmem-cell-names = "calibration";
+   };
+
uart0: serial@01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] dt-bindings: document sun8i_ths

[Josef Gajdusek]

This patch adds the binding documentation for the sun8i_ths driver

Signed-off-by: Josef Gajdusek 
---
 .../devicetree/bindings/thermal/sun8i-ths.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-ths.txt

diff --git a/Documentation/devicetree/bindings/thermal/sun8i-ths.txt 
b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
new file mode 100644
index 000..67056bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
@@ -0,0 +1,31 @@
+* sun8i THS
+
+Required properties:
+- compatible : "allwinner,sun8i-h3-ths"
+- reg : Address range of the thermal registers and location of the calibration
+value
+- resets : Must contain an entry for each entry in reset-names.
+   see ../reset/reset.txt for details
+- reset-names : Must include the name "ahb"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
+  clock
+
+Optional properties:
+- nvmem-cells : Must contain an entry for each entry in nvmem-cell-names
+- nvmem-cell-names : Must contain "calibration" for the cell containing the
+  temperature calibration cell, if available
+
+Example:
+ths: ths@01c25000 {
+   #thermal-sensor-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths";
+   reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
+   interrupts = ;
+   resets = <&bus_rst 136>;
+   reset-names = "ahb";
+   clocks = <&bus_gates 72>, <&ths_clk>;
+   clock-names = "ahb", "ths";
+   nvmem-cells = <&ths_calibration>;
+   nvmem-cell-names = "calibration";
+};
-- 
2.4.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Build regressions/improvements in v4.4-rc2

[Geert Uytterhoeven]

On Mon, Nov 23, 2015 at 9:01 AM, Geert Uytterhoeven
 wrote:
> JFYI, when comparing v4.4-rc2[1] to v4.4-rc1[3], the summaries are:
>   - build errors: +11/-10

  + error: debugfs.c: undefined reference to `clk_round_rate':  =>
.text+0x38b054), .text+0x38af08), .text+0x364fb0)
  + error: debugfs.c: undefined reference to `clk_set_parent':  =>
.text+0x16d5d0)
  + error: debugfs.c: undefined reference to `clk_set_rate':  =>
.text+0x1f2334), .text+0x1285e0), .text+0x392fbc), .text+0x128820),
.text+0x3651a4), .text+0x394070), .text+0x167080), .text+0x3940fc),
.text+0x38b0cc), .text+0x171ddc), .text+0x36526c), .text+0x297834),
.text+0x128604)
  + error: last.c: undefined reference to `clk_round_rate':  =>
.text+0x71918), .text+0xd186c), .text+0x72ba0), .text+0x7e388),
.text+0x7ae88), .text+0x79668)
  + error: last.c: undefined reference to `clk_set_parent':  =>
.text+0xd3f38), .text+0xccde8), .text+0xd3f58), .text+0xd79c8)
  + error: last.c: undefined reference to `clk_set_rate':  =>
.text+0xcdc5c), .text+0xdc494), .text+0xd19a0), .text+0x79678),
.text+0xa7fd0), .text+0xd921c), .text+0xd3f64), .text+0x7ae98),
.text+0x71928), .text+0xd92a4), .text+0x7e398), .text+0x72bb0),
.text+0xd96b4), .text+0xdd2c4), .text+0xcae30)

arm-randconfig

> [1] http://kisskb.ellerman.id.au/kisskb/head/9622/ (256 out of 254 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/9597/ (255 out of 254 configs)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: imx6dl clock setup incorrectness

[Nikita Yushchenko]

Hi

>> While working with board with imx6s cpu, with kernel based on linux-imx
>> imx_3.14.28_1.0.0_ga branch, I noticed this message in boot log:
>>
>>> failed to set parent of clk gpu2d_core_sel to pll2_pfd1_594m
>>
>>
>> I looked into it and found that:
>>
>> - CCM_CBCMR register layout is different between imx6q/imx6d and
>> imc6dl/imx6s (at least manuals state that)
>>
>> - clock setup in clk-imx6q.c (that is used both got imx6q/imx6d and
>> imx6dl/imx6s) creates gpu2d_core_sel clock object as described in imx6q
>> manual (i.e. using bits 18:19 of CCM_CBCMR register)
>>
>> - however per imx6dl manual, these bits contain different field
>> (mlb_sys_sel) on imx6dl/imx6s, and gpu2d_core sel is in bits 8:9
>>
>> - imx6q has different clock selector, gpu3d_shader_clk_sel, in bits 8:9,
>> and existing code unconditionally creates gpu3d_shader_clk_sel clock object
>>
>> - per manual, gpu3d_shader_clk_sel does not exist on imx6qdl/imx6s
>>
>> - however gpu driver (which also is common between imx6q/imx6d and
>> imc6dl/imx6s) does use gpu3d_shader_clk which is child of
>> gpu3d_shader_clk_sel. Which means that it is not possible to simply
>> change clock object creation code to match manuals.
>>
>>
>> I'm looking for advice how to fix this situation properly.
>>
>>
>> Btw situation is the same in mainline kernel - clock setup code in
>> mainline is moved to drivers/clk/imx/ but still has the same incorrectness.
> 
> Isn't this handled by the following commit?
> 
> commit 2e603ad98460fd0efab71e618d49a2ffc9aef67b
> Author: Dirk Behme 
> Date:   Fri May 3 11:08:45 2013 +0200
> 
> ARM: i.MX6: clk: add i.MX6 DualLite differences
> 
> The CCM_CBCMR register (address 0x02C4018) has different meaning
> between the i.MX6 Quad/Dual and the i.MX6 Solo/DualLite.
> 
> Compared to the i.MX6 Quad/Dual, the CCM_CBCMR register in the
> i.MX6 Solo/DualLite doesn't have a gpu3d_shader configuration and
> moves the gpu2_core configuration at that place.
> 
> Handle these i.MX6 Quad/Dual vs. i.MX6 Solo/DualLite clock differences
> by using cpu_is_mx6dl().
> 
> Signed-off-by: Dirk Behme 
> Signed-off-by: Shawn Guo 

Ah I see.

With this patch, "gpu2d_clk" clk object is just reparented to "gpu3d_shader".

gpu3d_shader_clk_sel CCM_CBCMR field on imx6q is in bits 9:8. On this location 
imx6dl has gpu2d_core_sel field.

Thus reparenting "gpu2d_clk" to "gpu3d_shader" may look correct...  However I 
doubt it is.

Per manuals, bit meaning of imxq6's gpu3d_shader_clk_sel and imx6dl's 
gpu2d_core_sel is different:

- imx6q:

| 9–8 gpu3d_shader_clk_sel
| 
| Selector for gpu3d_shader clock multiplexer
| 00 derive clock from mmdc_ch0 clk
| 01 derive clock from pll3_sw_clk
| 10 derive clock from PFD 594M
| 11 derive clock from 720M PFD

- imx6dl:

| 9–8 gpu2d_core_sel
| Selector for gpu2d_core clock multiplexer
| 00 derive clock from mmdc_ch0 clk
| 01 derive clock from pll3_sw_clk
| 10 derive clock from PLL2 PFD1
| 11 derive clock from Reserved

Also, existing code does create "gpu3d_shader" clock on imx6dl, referencing 
register bits that, per imx6dl manual, contains gpu2d_core_podf field.

This clock *is* referenced in in-tree device tree file.
As of today, looks like this setting in not used by in-tree code. But it is 
used by out-fo-tree vivante gpu drivers.


Thus the inconsistency does exist: clock tree created for imx6dl does not match 
manual. This is misleading at least...  and likely causes a real error (gpu3d 
driver mangling with gpu2d clock) when out of tree driver gpu3d driver is used.

I guess fix could look something like

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index c193508..f11aab3 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -35,6 +35,7 @@ static const char *axi_sels[] = { "periph", 
"pll2_pfd2_396m", "periph", "pll3_p
 static const char *audio_sels[]= { "pll4_audio_div", "pll3_pfd2_508m", 
"pll3_pfd3_454m", "pll3_usb_otg", };
 static const char *gpu_axi_sels[]  = { "axi", "ahb", };
 static const char *gpu2d_core_sels[]   = { "axi", "pll3_usb_otg", 
"pll2_pfd0_352m", "pll2_pfd2_396m", };
+static const char *gpu2d_core_sels_dl[]= { "mmdc_ch0_axi", 
"pll3_usb_otg", "pll2_pfd1_594m", "dummy", };
 static const char *gpu3d_core_sels[]   = { "mmdc_ch0_axi", "pll3_usb_otg", 
"pll2_pfd1_594m", "pll2_pfd2_396m", };
 static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", 
"pll2_pfd1_594m", "pll3_pfd0_720m", };
 static const char *ipu_sels[]  = { "mmdc_ch0_axi", "pll2_pfd2_396m", 
"pll3_120m", "pll3_pfd1_540m", };
@@ -292,10 +293,11 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
if (clk_on_imx6q()) {
clk[IMX6QDL_CLK_GPU2D_AXI]= imx_clk_mux("gpu2d_axi",
base + 0x18, 0,  1, gpu_axi_sels,  ARRAY_SIZE(gpu_axi_sels));
clk[IMX6QDL_CLK_GPU3D_AXI]= imx_clk_mux("gpu3d_axi",
base + 0x18, 1,

Re: [PATCH v4 10/13] of: add vendor prefix for boe

[Thierry Reding]

On Fri, Nov 20, 2015 at 04:15:36PM +0800, Chris Zhong wrote:
> Signed-off-by: Chris Zhong 
> Acked-by: Rob Herring 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied, with slightly modified commit message.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: [PATCH v4 11/13] drm/panel: simple: Add support for BOE TV080WUM-NL0

[Thierry Reding]

On Fri, Nov 20, 2015 at 04:15:37PM +0800, Chris Zhong wrote:
> This adds support for the BOE TV080WUM-NL0 1200x1920 mipi panel to the
> DRM simple panel driver.
> 
> Signed-off-by: Chris Zhong 
> 
> ---
> 
> Changes in v4:
> Alphabetically arranged the name
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/gpu/drm/panel/panel-simple.c | 34 ++
>  1 file changed, 34 insertions(+)

Applied, with slightly modified commit message.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: [PATCH 1/2] clk: rockchip: dmc: support rk3399 dmc clock driver

[MyungJoo Ham]

> +static unsigned long rk3399_dmcclk_recalc_rate(struct clk_hw *hw,
> +unsigned long parent_rate)
> +{
> + struct rk3399_dmcclk *dmc = to_rk3399_dmcclk(&hw);
> + u32 val;
> +
> + /*
> +  * Get parent rate since it changed in this clks set_rate op. The parent
> +  * rate passed into this function is cached before set_rate is called in
> +  * the common clk code, so we have to get it here.
> +  */
> + parent_rate = clk_get_rate(clk_get_parent(hw->clk));
> +
> + val = readl(dmc->cru + CRU_CLKSEL6_CON);
> + val = (val >> CLK_DDRC_DIV_CON_SHIFT) & CLK_DDRC_DIV_CON_MASK;
> +
> + return parent_rate / (val + 1);
> +}
> +
> +/*
> + * TODO: set ddr frequcney in dcf which run in ATF
> + */
> +static int rk3399_dmcclk_set_rate(struct clk_hw *hw, unsigned long rate,
> +   unsigned long parent_rate)
> +{
> + return 0;
> +}

Is it correct that you didn't fill this up because your
Trustzone driver (SMC) is not ready yet?

Then, why don't you fill that function assuming that TrustZone is not activated
and add SMC call functions with if or #if after its TrustZone driver is ready?

Or does your SoC mandate the usage ot TrustZone, restricting the usage
of CRU_CLKSEL6_CON write? (I don't see why SoC vendors will do this..)


I'll be ready to merge the RK3399 devfreq driver if you
fill this up (assuming that TZ is not enabled) or
add TZ driver and SMC calls.


Cheers,
MyungJoo
ps. according to rk339_dmcclk_recalc_rate(), filling rk339_dmcclk_set_rate
assuming that TZ is not enabled seems trivial.

Re: [PATCH v4 12/13] drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree binding

[Thierry Reding]

On Fri, Nov 20, 2015 at 04:15:38PM +0800, Chris Zhong wrote:
> This binding specifies a set of common properties for display panels. It
> can be used as a basis by bindings for specific panels.
> Bindings for three specific panels are provided to show how the
> simple panel binding can be used.
> 
> Signed-off-by: Chris Zhong 
> Acked-by: Rob Herring 
> 
> ---
> 
> Changes in v4: None
> Changes in v3:
> move boe,tv080wum-nl0.txt to bindings/display/panel/
> 
> Changes in v2:
> As Thierry.Reding comment, add a documentation for this panel.
> 
>  .../devicetree/bindings/display/panel/boe,tv080wum-nl0.txt | 7 
> +++
>  1 file changed, 7 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt

Applied, with a rewritten commit message. The one above seems to be
copied from the original commit that added the simple-panel binding.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: [PATCH] ASoC: pxa: remove incorrect do_div() call

[zhangfei]

On 11/20/2015 05:32 PM, Arnd Bergmann wrote:

The new optimized do_div implementation (now in asm-generic/next) exposes a
glitch in the brownstone audio driver by producing a compile-time warning:

sound/soc/pxa/brownstone.c: In function 'brownstone_wm8994_hw_params':
sound/soc/pxa/brownstone.c:67:85: warning: comparison of distinct pointer types 
lacks a cast
sound/soc/pxa/brownstone.c:67:10125: warning: right shift count >= width of 
type [-Wshift-count-overflow]
sound/soc/pxa/brownstone.c:67:10254: warning: passing argument 1 of 
'__div64_32' from incompatible pointer type [-Wincompatible-pointer-types]

The driver just divides two plain integer values, so it should not
use do_div to start with, but has apparently done so ever since the
code was first merged. This replaces do_div with a simple division
operator.

Signed-off-by: Arnd Bergmann 
---
I think this one is harmless, so we only need it in 4.5 to avoid the warning,
but not backported to earlier kernels.

Found today on ARM allmodconfig

diff --git a/sound/soc/pxa/brownstone.c b/sound/soc/pxa/brownstone.c
index 6147e86e9b0f..416ea646c3b1 100644
--- a/sound/soc/pxa/brownstone.c
+++ b/sound/soc/pxa/brownstone.c
@@ -63,8 +63,7 @@ static int brownstone_wm8994_hw_params(struct 
snd_pcm_substream *substream,
sysclk= params_rate(params) * 512;
sspa_mclk = params_rate(params) * 64;
}
-   sspa_div = freq_out;
-   do_div(sspa_div, sspa_mclk);
+   sspa_div = freq_out / sspa_mclk;

snd_soc_dai_set_sysclk(cpu_dai, MMP_SSPA_CLK_AUDIO, freq_out, 0);
snd_soc_dai_set_pll(cpu_dai, MMP_SYSCLK, 0, freq_out, sysclk);



Thanks Arnd.

Looks sspa_div is not used at all.
So we can remove sspa_div as well as do_div.

What do you think.

Thanks

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

Re: [PATCH 2/2] arm64: dts: berlin4ct: enable all i2c nodes for the STB board

[Sebastian Hesselbarth]

On 23.11.2015 03:49, Jisheng Zhang wrote:

On Fri, 20 Nov 2015 22:19:32 +0100
Sebastian Hesselbarth wrote:

On 20.11.2015 10:47, Jisheng Zhang wrote:

Enable all i2c nodes for the Marvell berlin BG4CT STB board.

Signed-off-by: Jisheng Zhang 
---
  arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 50 +++
  1 file changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts 
b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
index 348c37e..9e8e2e0 100644
--- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
+++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
@@ -61,6 +61,56 @@
};
  };

+&avio_pinctrl {
+   twsi1_pmux: twsi1-pmux {
+   groups = "TX_EDDC_SCL", "TX_EDDC_SDA";
+   function = "tx_eddc";
+   };


Please keep the pinmux sub-nodes in the SoC dtsi as long
as they are not strictly board specific, i.e. gpios.


Hmm, seems all boards configure this pin for EDDC usage, so it's fine
to move to soc




+};
+
+&i2c0 {
+   status = "okay";
+   pinctrl-0 = <&twsi0_pmux>;
+   pinctrl-names = "default";


If there is only one (or a default) pinctrl-0 option for i2c0,
you can also move it to the SoC dtsi.


Some board may not use i2c0, i2c2, i2c3 host and use the pin as gpio for other
purpose. Considering the above twsi1_pmux usage, what's the better solution?
move twsi1_pmux to soc's dtsi and leave i2c0, i2c2, i2c3 pinctrl in board dts?


If some boards don't use i2cN, they do not enable the node in their
board dts. That is sufficient to not configure the pinmux as it will
only be set if a driver is loaded for that node.

If there is only one or two different pinmux settings for a specific
function _always_ move the pinmux setting into SoC dtsi. If there is
a well known default out of two or more possible settings, we may also
have that pinmux as a default in the i2c node and only overwrite it
when we have a board that uses a different setting.

So, for i2c: Move all pinctrl/pinctrl-names properties to the SoC
dtsi.

Sebastian

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

Re: [PATCH v2] zram: Prevent page allocation failure during zcomp_strm_alloc

[Sergey Senozhatsky]

On (11/23/15 16:43), Sergey Senozhatsky wrote:
[..]
> agree. we also would want to switch from vzalloc() to
>   __vmalloc_node_flags(size, NUMA_NO_NODE,
>   GFP_NOIO | __GFP_HIGHMEM |  __GFP_ZERO)

[..]
> > So, Kyeongdon's patch will remove warning overhead and likely to
> > make zcomp_stram_alloc successful with vmalloc so I want to
> > roll it out first. And let's add a WARN_ON_ONCE to detect of
> > failure and rethink it when we receive such report.

hm... for k{z,m}alloc() it does reduce the warning overhead, but not
for vmalloc() -> warn_alloc_failed() [in theory]. So I guess, I'll
change vmalloc() to

__vmalloc(XXX,
GFP_NOIO | __GFP_NOWARN | __GFP_HIGHMEM | __GFP_ZERO,
PAGE_KERNEL);

/* passing __GFP_NOWARN */.

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch: consolidate CONFIG_STRICT_DEVM in lib/Kconfig.debug

[Ingo Molnar]

* Dan Williams  wrote:

> Let all the archs that implement CONFIG_STRICT_DEVM use a common
> definition in lib/Kconfig.debug.

For the x86 bit:

Acked-by: Ingo Molnar 

> Note, the 'depends on !SPARC' is due to sparc not implementing
> devmem_is_allowed().

Maybe that should be converted into a helper Kconfig switch for architectures 
to 
opt in to /dev/mem restrictions?

Thanks,

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

Re: [PATCH v2 0/6] sched/fair: Clean up sched metric definitions

[Yuyang Du]

Hi Peter and Ingo,

A reminder of this patch searies, in case you forget.

Thanks,
Yuyang

On Thu, Oct 22, 2015 at 07:24:42AM +0800, Yuyang Du wrote:
> Hi Peter and Ingo,
> 
> As discussed recently, the sched metrics need a little bit cleanup. This
> series of patches attempt to do that: refactor, rename, remove...
> 
> Thanks a lot to Ben, Morten, Dietmar, Vincent, and others who provided
> valuable comments.
> 
> v2 changes:
> - Rename SCHED_RESOLUTION_SHIFT to SCHED_FIXEDPOINT_SHIFT, thanks to Peter
> - Fix bugs in calculate_imbalance(), thanks to Vincent
> - Fix "#if 0" for increased kernel load
> 
> Thanks,
> Yuyang
> 
> Yuyang Du (6):
>   sched/fair: Generalize the load/util averages resolution definition
>   sched/fair: Remove SCHED_LOAD_SHIFT and SCHED_LOAD_SCALE
>   sched/fair: Add introduction to the sched load avg metrics
>   sched/fair: Remove scale_load_down() for load_avg
>   sched/fair: Rename scale_load() and scale_load_down()
>   sched/fair: Remove unconditionally inactive code
> 
>  include/linux/sched.h | 81 
> +++
>  init/Kconfig  | 16 ++
>  kernel/sched/core.c   |  8 ++---
>  kernel/sched/fair.c   | 33 ++---
>  kernel/sched/sched.h  | 52 +++--
>  5 files changed, 127 insertions(+), 63 deletions(-)
> 
> -- 
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Arnd Bergmann]

On Sunday 22 November 2015 21:36:45 Nicolas Pitre wrote:
> On Sun, 22 Nov 2015, Arnd Bergmann wrote:
> 
> > I've also found some /proc/cpuinfo output to cross-reference SoCs
> > to their core names.
> > 
> >   variant partrevisionnamefeatures
> > dove: 0   0x581   5   PJ4 idivt
> 
> I just managed to boot my dusty Dove DB and ran a quick test programon 
> it. Its cpuinfo corresponds to the above.
> 
> $ cat m.c
> #include 
> int mydiv(int, int);
> int main()
> {
> printf("div test\n");
> printf("%d\n", mydiv(12345678, 37));
> return 0;
> }
> $ cat d.c
> int mydiv(int x, int y)
> {
> return x/y;
> }
> $ gcc -o test m.c d.c
> $ ./test
> div test
> 333666
> $ gcc -o test m.c d.c -march=armv7ve -mthumb
> $ ./test
> div test
> 333666
> $ gcc -o test m.c d.c -march=armv7ve -marm
> $ ./test
> div test
> Illegal instruction (core dumped)
> $

Ok, thanks a lot! So the reporting in /proc/cpuinfo clearly matches
the actual features, and we can just treat this as no LPAE / no IDIV
for kernel compilation, as nobody ever seems to use THUMB2_KERNEL
in practice.

PJ4-MP is like Cortex-A15/A7/A12/A17 and supports both IDIV and LPAE,
which leaves the question whether Scorpion or Krait do the same as
well, or whether they are outliers and need a special configuration.

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

Re: [GIT PULL 00/37] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling, this was based on tip/perf/urgent and I did a
> test merge of tip/perf/core with tip/perf/urgent and then with this branch,
> haven't noticed problems,
> 
> Best regards,
> 
> - Arnaldo
> 
> The following changes since commit e15bf88a44d1fcb685754b2868b1cd28927af3aa:
> 
>   Merge tag 'perf-urgent-for-mingo' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2015-11-18 06:56:48 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo
> 
> for you to fetch changes up to 2c6caff2b26fde8f3f87183f8c97f2cebfdbcb98:
> 
>   perf ui/gtk: Support folded callchains (2015-11-19 13:19:26 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> User visible:
> 
> - Allows BPF scriptlets specify arguments to be fetched using
>   DWARF info, using a prologue generated at compile/build time (He Kuang, 
> Wang Nan)
> 
> - Allow attaching BPF scriptlets to module symbols (Wang Nan)
> 
> - Allow attaching BPF scriptlets to userspace code using uprobe (Wang Nan)
> 
> - BPF programs now can specify 'perf probe' tunables via its section name,
>   separating key=val values using semicolons (Wang Nan)
> 
> Testing some of these new BPF features:
> 
> Use case: get callchains when receiving SSL packets, filter then in the
>   kernel, at arbitrary place.
> 
>   # cat ssl.bpf.c
>   #define SEC(NAME) __attribute__((section(NAME), used))
> 
>   struct pt_regs;
> 
>   SEC("func=__inet_lookup_established hnum")
>   int func(struct pt_regs *ctx, int err, unsigned short port)
>   {
>   return err == 0 && port == 443;
>   }
> 
>   char _license[] SEC("license") = "GPL";
>   int  _version   SEC("version") = LINUX_VERSION_CODE;
>   #
>   # perf record -a -g -e ssl.bpf.c
>   ^C[ perf record: Woken up 1 times to write data ]
>   [ perf record: Captured and wrote 0.787 MB perf.data (3 samples) ]
>   # perf script | head -30
>   swapper 0 [000] 58783.268118: perf_bpf_probe:func: (816a0f60) 
> hnum=0x1bb
>8a0f61 __inet_lookup_established (/lib/modules/4.3.0+/build/vmlinux)
>896def ip_rcv_finish (/lib/modules/4.3.0+/build/vmlinux)
>8976c2 ip_rcv (/lib/modules/4.3.0+/build/vmlinux)
>855eba __netif_receive_skb_core (/lib/modules/4.3.0+/build/vmlinux)
>8565d8 __netif_receive_skb (/lib/modules/4.3.0+/build/vmlinux)
>8572a8 process_backlog (/lib/modules/4.3.0+/build/vmlinux)
>856b11 net_rx_action (/lib/modules/4.3.0+/build/vmlinux)
>2a284b __do_softirq (/lib/modules/4.3.0+/build/vmlinux)
>2a2ba3 irq_exit (/lib/modules/4.3.0+/build/vmlinux)
>96b7a4 do_IRQ (/lib/modules/4.3.0+/build/vmlinux)
>969807 ret_from_intr (/lib/modules/4.3.0+/build/vmlinux)
>2dede5 cpu_startup_entry (/lib/modules/4.3.0+/build/vmlinux)
>95d5bc rest_init (/lib/modules/4.3.0+/build/vmlinux)
>   1163ffa start_kernel ([kernel.vmlinux].init.text)
>   11634d7 x86_64_start_reservations ([kernel.vmlinux].init.text)
>   1163623 x86_64_start_kernel ([kernel.vmlinux].init.text)
> 
>   qemu-system-x86  9178 [003] 58785.792417: perf_bpf_probe:func: 
> (816a0f60) hnum=0x1bb
>8a0f61 __inet_lookup_established (/lib/modules/4.3.0+/build/vmlinux)
>896def ip_rcv_finish (/lib/modules/4.3.0+/build/vmlinux)
>8976c2 ip_rcv (/lib/modules/4.3.0+/build/vmlinux)
>855eba __netif_receive_skb_core (/lib/modules/4.3.0+/build/vmlinux)
>8565d8 __netif_receive_skb (/lib/modules/4.3.0+/build/vmlinux)
>856660 netif_receive_skb_internal (/lib/modules/4.3.0+/build/vmlinux)
>8566ec netif_receive_skb_sk (/lib/modules/4.3.0+/build/vmlinux)
>  430a br_handle_frame_finish ([bridge])
>  48bc br_handle_frame ([bridge])
>855f44 __netif_receive_skb_core (/lib/modules/4.3.0+/build/vmlinux)
>8565d8 __netif_receive_skb (/lib/modules/4.3.0+/build/vmlinux)
>   #
> 
>   Use 'perf probe' various options to list functions, see what variables can
>   be collected at any given point, experiment first collecting without a 
> filter,
>   then filter, use it together with 'perf trace', 'perf top', with or without
>   callchains, if it explodes, please tell us!
> 
> - Introduce a new callchain mode: "folded", that will list per line
>   representations of all callchains for a give histogram entry, facilitating
>   'perf report' output processing by other tools, such as Brendan Gregg's
>   flamegraph tools (Namhyung Kim)
> 
>   E.g:
> 
>  # perf report | grep -v ^# | head
> 18.37% 0.00%  swapper  [kernel.kallsyms]   [k] cpu_startup_entry
> |
> ---cpu_startup_entry
>|
>|--12.07%--start_secondary
>|
> --

Re: multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs

[Lee Jones]

On Sun, 22 Nov 2015, Pavel Machek wrote:

> On Mon 2015-11-16 14:11:42, Charles Keepax wrote:
> > On Sat, Nov 14, 2015 at 10:16:33PM +0100, Pavel Machek wrote:
> > > HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> > > > On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> > > > 
> > > > > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > > > > with device that does not have dev_name initialized.
> > > > 
> > > > OK, that'll be the problem then - we're not mapping the supply into the
> > > > individual child device but rather system wide, probably because that
> > > > mapping is being done too early, before we've actually created the
> > > > device.
> > > 
> > > Take a look at mfd_add_device(). Yes, we do
> > > regulator_bulk_register_supply_alias() before doing
> > > platform_device_add().
> > > 
> > > > > regulator_bulk_register_supply_alias() results in "Adding alias"
> > > > > stuff, and then drivers/regulator/arizona-micsupp.c tries to register
> > > > > another "MICVDD".
> > > > 
> > > > That's fine because all supplies should be namespaced with a device.
> > > > The goal is to say "Supply X on device Y" (we do support exceptions for
> > > > the few cases where there are not yet any devices involved but this
> > > > clearly isn't one of them).
> > 
> > Indeed that should be the case.
> > 
> > > 
> > > Well, clearly someone should tell that to wm5102
> > > maintainers. Hmm. It looks like driver is marked supported but there
> > > are no names attached?
> > > 
> > > WOLFSON MICROELECTRONICS DRIVERS
> > > L:  patc...@opensource.wolfsonmicro.com
> > > T:  git git://opensource.wolfsonmicro.com/linux-2.6-asoc
> > > T:  git git://opensource.wolfsonmicro.com/linux-2.6-audioplus
> > > W:
> > > http://opensource.wolfsonmicro.com/content/linux-drivers-wolfson-device\
> > > s
> > > S:  Supported
> > > 
> > > I guess Charles Keepax should be listed there?
> > 
> > The patches mailing list functions as maintainer here. That way
> > anyone who works on upstream Linux stuff here will see the email
> > so you have more chance of someone replying. Also convient for
> > when people leave the company etc. makes for an easy transition.
> > I am afraid though that as in this case you are not always going
> > to get a reply over the weekend.
> 
> Well.. maintainer is a responsible person. Yes, you can list a mailing
> list in maintainers file.. but mailing list is not going to be
> responsible for that.
> 
> Having a real name of person helps; if your name was listed there, I'd
> know you (are supposed to be) authoritative person for this.
> 
> I see it will need to be updated from time to time, but having name
> really helps.

A Mailing List is perfectly adequate for drivers which reside in a
maintained subsystem.  No requirement to submit names, particularly if
there are lots of authorities personnel or if the personalities change
regularly.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Jisheng Zhang]

Dear all,

On Mon, 23 Nov 2015 15:21:58 +0800
Jisheng Zhang wrote:

> Dear Sebastian,
> 
> On Fri, 20 Nov 2015 22:06:59 +0100
> Sebastian Hesselbarth wrote:
> 
> > On 20.11.2015 09:42, Jisheng Zhang wrote:  
> > > Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.
> > > 
> > > Signed-off-by: Jisheng Zhang 
> > > ---
> > >  arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 38 
> > > ++
> > >  1 file changed, 38 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi 
> > > b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> > > index a4a1876..808a997 100644
> > > --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> > > +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> > > @@ -42,6 +42,7 @@
> > >   * OTHER DEALINGS IN THE SOFTWARE.
> > >   */
> > >  
> > > +#include 
> > >  #include 
> > >  
> > >  / {
> > > @@ -135,6 +136,22 @@
> > >   interrupts =  > > IRQ_TYPE_LEVEL_HIGH)>;
> > >   };
> > >  
> > > + cpupll: cpupll {
> > > + compatible = "marvell,berlin-pll";
> > > + reg = <0x922000 0x14>, <0xea0710 4>;
> > > + #clock-cells = <0>;
> > > + clocks = <&osc>, <&clk CLK_CPUFASTREF>;
> > > + bypass-shift = /bits/ 8 <2>;
> > > + };
> > > +
> > > + mempll: mempll {
> > > + compatible = "marvell,berlin-pll";
> > > + reg = <0x940034 0x14>, <0xea0710 4>;
> > 
> > Whenever you see overlapping/repeating reg ranges, e.g. <0xea0710 4>
> > you can be sure you are not representing HW structure but driver
> > structure here.
> > 
> > Please merge clocks/gates/plls to a single clock complex node
> > and deal with the internals by using "simple-mfd" and "syscon" regmaps.
> >   
> > > + #clock-cells = <0>;
> > > + clocks = <&osc>, <&clk CLK_MEMFASTREF>;
> > > + bypass-shift = /bits/ 8 <1>;
> > > + };
> > > +
> > >   apb@e8 {
> > >   compatible = "simple-bus";
> > >   #address-cells = <1>;
> > > @@ -225,6 +242,27 @@
> > >   };
> > >   };
> > >  
> > > + syspll: syspll {
> > > + compatible = "marvell,berlin-pll";
> > > + reg = <0xea0200 0x14>, <0xea0710 4>;
> > > + #clock-cells = <0>;
> > > + clocks = <&osc>;
> > > + bypass-shift = /bits/ 8 <0>;
> > > + };
> > > +
> > > + gateclk: gateclk {
> > > + compatible = "marvell,berlin4ct-gateclk";
> > > + reg = <0xea0700 4>;
> > > + #clock-cells = <1>;
> > > + };
> > > +
> > > + clk: clk {
> > > + compatible = "marvell,berlin4ct-clk";
> > > + reg = <0xea0720 0x144>;
> > 
> > Looking at the reg ranges, I'd say that they are all clock related
> > and pretty close to each other:
> > 
> > gateclk: reg = <0xea0700 4>;
> > bypass:  reg = <0xea0710 4>;
> > clk: reg = <0xea0720 0x144>;  
> 
> Although these ranges sit close, but we should represent HW structure as you
> said.
> 
> First of all, let me describe the clks/plls in BG4CT. BG4CT contains:
> 
> two kinds of PLL: normal PLL and AVPLL. These PLLs are put with their users
> together. For example: mempll pll registers <0xf7940034, 0x14> is put together
> with mem controller registers. AVPLL control registers are put with AV 
> devices.
> You can also check mempll, cpupll and syspll ranges:
> 
> cpupll: <0x922000 0x14>
> 
> mempll: <0x940034 0x14>
> 
> syspll: <0xea0200 0x14>
> 
> 
> We have three normal PLLS: cpupll, mempll and syspll. All these three PLLs use
> 25MHZ osc as clocksource. These plls can be bypassed. when syspll is bypassed
> the 25MHZ osc is directly output to syspllclk. When mempll/cpupll is bypassed,
> its corresponding fastrefclk is directly output to ddrphyclk/cpuclk: 
> 
> 
>---25MHZ osc--|\
>| |-- syspllclk
>---| SYSPLL |-|/
> 
> 
> 
>---cpufastrefclk--|\
>| |-- cpuclk
>---| CPUPLL |-|/
> 
> 
>---memfastrefclk--|\
>| |-- ddrphyclk
>---| MEMPLL |-|/
> 
> NOTE: the fastrefclk is the so called normal clk below.
> 
> 
> 
> two kinds of clk: normal clk and gate clk. The normal clk supports changing
> divider, selecting clock source, disabling/enabling etc. The gate clk only
> supports disabling/enabling. normal clks use syspllclk as clocksource, while
> gate clks use perifsysclk as clocksource.
> 


I hope I have described the BG4CT HW clk/pll clearly, I really need your advice
about my proposal. The clk nodes in my proposal will finally look like:


cpupll: cpupll {
compatible = "marvell,berlin-pll";
reg = <0x922000 0x14>
  

Re: [PATCH v2 2/2] mm/mmap.c: remove incorrect MAP_FIXED flag comparison from mmap_region

[Michal Hocko]

On Fri 20-11-15 17:42:14, Piotr Kwapulinski wrote:
> The following flag comparison in mmap_region makes no sense:
> 
> if (!(vm_flags & MAP_FIXED))
> return -ENOMEM;
> 
> The condition is always false and thus the above "return -ENOMEM" is never
> executed. The vm_flags must not be compared with MAP_FIXED flag.
> The vm_flags may only be compared with VM_* flags.
> MAP_FIXED has the same value as VM_MAYREAD.
> It has no user visible effect.
> 
> Remove the code that makes no sense.
> 
> Signed-off-by: Piotr Kwapulinski 

I think this is preferable. Hitting the rlimit is a slow path and
find_vma_intersection should realize that there is no overlapping
VMA for !MAP_FIXED case pretty quickly.

I would prefer this to be in the changelog rather than/in addition to
"It has no user visible effect" which is really vague.

Acked-by: Michal Hocko 

> ---
> I made a mistake in a changelog in a previous version of this patch.
> I'm Sorry for the confusion.
> This patch may be considered to be applied only in case the patch
> "[PATCH v2 1/2] mm: fix incorrect behavior when process virtual
> address space limit is exceeded"
> is not going to be accepted.
> 
>  mm/mmap.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2ce04a6..42a8259 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1551,9 +1551,6 @@ unsigned long mmap_region(struct file *file, unsigned 
> long addr,
>* MAP_FIXED may remove pages of mappings that intersects with
>* requested mapping. Account for the pages it would unmap.
>*/
> - if (!(vm_flags & MAP_FIXED))
> - return -ENOMEM;
> -
>   nr_pages = count_vma_pages_range(mm, addr, addr + len);
>  
>   if (!may_expand_vm(mm, (len >> PAGE_SHIFT) - nr_pages))
> -- 
> 2.6.2
> 

-- 
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 v3 2/5] mfd: syscon: add a DT property to set value width

[Lee Jones]

On Sat, 21 Nov 2015, Arnd Bergmann wrote:

> On Tuesday 17 November 2015 09:26:49 Guenter Roeck wrote:
> > > 
> > > This syntax is confusing, as we normally associate it with an error
> > > condition.  Instead, I'd use:
> > > 
> > >   if (of_property_read_u32(np, "bus-width", &bus_width) == 0)
> > 
> > Or maybe better
> > 
> > if (!of_property_read_u32(np, "bus-width", &bus_width))
> 
> I would also prefer the latter, but it doesn't matter much either way.
> 
> > > 
> > > Or, for more clarity:
> > > 
> > >   of_property_read_u32(np, "bus-width", &bus_width);
> > >   if (bus_width)
> > > 
> > > If you choose this version (which I think is my preferred method, don't
> > > forget to initialise 'bus_width' to zero.
> > > 
> > Ignoring an error and depending on bus_width==0 to determine if the property
> > was provided seems odd, especially since it would "hide" if the bus-width
> > property is set to 0. In the original code, this would be detected as error.
> 
> Right.
> 
> Another option would be
> 
>   ret = of_property_read_u32(np, "bus-width", &bus_width);
>   /* no bus width provided, default to 32-bit */
>   if (ret)
>   bus_width = 32;
> 
>   syscon_config.val_bits = bus_width;
>   syscon_config.reg_stride = syscon_config.val_bits / 8;
> 
> which has the same effect but seems a little clearer to me.

Works for me.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RESEND PATCH v2] mfd: sec-core: Rename MFD and regulator names differently

[Lee Jones]

On Fri, 20 Nov 2015, Alim Akhtar wrote:

> Currently S2MPSXX multifunction device is named as *-pmic,
> and these MFDs also supports regulator as a one of its MFD cell which
> has the same name, because current name is confusing and we want to
> sort it out.
> 
> We did discussed different approaches about how the MFD and it
> cells need to be named here [1].
> Based in the discussion this patch rename MFD regulator name as
> *-regulator instead of current *-pmic.
> 
> This patch also changes the corresponding entries in the regulator driver
> to keep git-bisect happy.
> 
> [1]-> https://lkml.org/lkml/2015/10/28/417
> 
> Suggested-by: Lee Jones 
> Signed-off-by: Alim Akhtar 
> Reviewed-by: Krzysztof Kozlowski 
> Acked-by: Mark Brown 
> Acked-by: Lee Jones 
> ---
> Resending with collected Reviwed-by, Acked-by tags.
> 
>  drivers/mfd/sec-core.c  |8 
>  drivers/regulator/s2mps11.c |8 
>  2 files changed, 8 insertions(+), 8 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index 7c4e7be17f1e..c9802ba9be72 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -68,7 +68,7 @@ static const struct mfd_cell s5m8767_devs[] = {
>  
>  static const struct mfd_cell s2mps11_devs[] = {
>   {
> - .name = "s2mps11-pmic",
> + .name = "s2mps11-regulator",
>   }, {
>   .name = "s2mps14-rtc",
>   }, {
> @@ -78,7 +78,7 @@ static const struct mfd_cell s2mps11_devs[] = {
>  };
>  
>  static const struct mfd_cell s2mps13_devs[] = {
> - { .name = "s2mps13-pmic", },
> + { .name = "s2mps13-regulator", },
>   { .name = "s2mps13-rtc", },
>   {
>   .name = "s2mps13-clk",
> @@ -88,7 +88,7 @@ static const struct mfd_cell s2mps13_devs[] = {
>  
>  static const struct mfd_cell s2mps14_devs[] = {
>   {
> - .name = "s2mps14-pmic",
> + .name = "s2mps14-regulator",
>   }, {
>   .name = "s2mps14-rtc",
>   }, {
> @@ -116,7 +116,7 @@ static const struct mfd_cell s2mpa01_devs[] = {
>  
>  static const struct mfd_cell s2mpu02_devs[] = {
>   {
> - .name = "s2mpu02-pmic",
> + .name = "s2mpu02-regulator",
>   },
>  };
>  
> diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
> index b2f3a28e720c..3242ffc0cb25 100644
> --- a/drivers/regulator/s2mps11.c
> +++ b/drivers/regulator/s2mps11.c
> @@ -1199,11 +1199,11 @@ out:
>  }
>  
>  static const struct platform_device_id s2mps11_pmic_id[] = {
> - { "s2mps11-pmic", S2MPS11X},
> - { "s2mps13-pmic", S2MPS13X},
> - { "s2mps14-pmic", S2MPS14X},
> + { "s2mps11-regulator", S2MPS11X},
> + { "s2mps13-regulator", S2MPS13X},
> + { "s2mps14-regulator", S2MPS14X},
>   { "s2mps15-regulator", S2MPS15X},
> - { "s2mpu02-pmic", S2MPU02},
> + { "s2mpu02-regulator", S2MPU02},
>   { },
>  };
>  MODULE_DEVICE_TABLE(platform, s2mps11_pmic_id);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arm64: dts: berlin4ct: enable all i2c nodes for the STB board

[Jisheng Zhang]

On Mon, 23 Nov 2015 09:12:18 +0100
Sebastian Hesselbarth  wrote:

> On 23.11.2015 03:49, Jisheng Zhang wrote:
> > On Fri, 20 Nov 2015 22:19:32 +0100
> > Sebastian Hesselbarth wrote:  
> >> On 20.11.2015 10:47, Jisheng Zhang wrote:  
> >>> Enable all i2c nodes for the Marvell berlin BG4CT STB board.
> >>>
> >>> Signed-off-by: Jisheng Zhang 
> >>> ---
> >>>   arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 50 
> >>> +++
> >>>   1 file changed, 50 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts 
> >>> b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> >>> index 348c37e..9e8e2e0 100644
> >>> --- a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> >>> +++ b/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
> >>> @@ -61,6 +61,56 @@
> >>>   };
> >>>   };
> >>>
> >>> +&avio_pinctrl {
> >>> + twsi1_pmux: twsi1-pmux {
> >>> + groups = "TX_EDDC_SCL", "TX_EDDC_SDA";
> >>> + function = "tx_eddc";
> >>> + };  
> >>
> >> Please keep the pinmux sub-nodes in the SoC dtsi as long
> >> as they are not strictly board specific, i.e. gpios.  
> >
> > Hmm, seems all boards configure this pin for EDDC usage, so it's fine
> > to move to soc
> >  
> >>  
> >>> +};
> >>> +
> >>> +&i2c0 {
> >>> + status = "okay";
> >>> + pinctrl-0 = <&twsi0_pmux>;
> >>> + pinctrl-names = "default";  
> >>
> >> If there is only one (or a default) pinctrl-0 option for i2c0,
> >> you can also move it to the SoC dtsi.  
> >
> > Some board may not use i2c0, i2c2, i2c3 host and use the pin as gpio for 
> > other
> > purpose. Considering the above twsi1_pmux usage, what's the better solution?
> > move twsi1_pmux to soc's dtsi and leave i2c0, i2c2, i2c3 pinctrl in board 
> > dts?  
> 
> If some boards don't use i2cN, they do not enable the node in their
> board dts. That is sufficient to not configure the pinmux as it will
> only be set if a driver is loaded for that node.
> 
> If there is only one or two different pinmux settings for a specific
> function _always_ move the pinmux setting into SoC dtsi. If there is
> a well known default out of two or more possible settings, we may also
> have that pinmux as a default in the i2c node and only overwrite it
> when we have a board that uses a different setting.

Got it. Thanks for the detailed explanations.

> 
> So, for i2c: Move all pinctrl/pinctrl-names properties to the SoC
> dtsi.

Will do in v2 when clk stuff is accepted.

Thanks,
Jisheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: dt-bindings: Fix interrupt documentation file path

[Lee Jones]

On Mon, 21 Sep 2015, Andrew F. Davis wrote:

> Fix the incorrect interrupt documentation file path in binding docs.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt | 2 +-
>  Documentation/devicetree/bindings/mfd/arizona.txt  | 2 +-
>  Documentation/devicetree/bindings/mfd/palmas.txt   | 2 +-
>  Documentation/devicetree/bindings/sound/wm8994.txt | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
> b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> index dd5d2c0..4d6c8cd 100644
> --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> @@ -24,7 +24,7 @@ controller.
>  - #interrupt-cells : Specifies the number of cells needed to encode an
>interrupt.  Shall be set to 2.  The first cell defines the interrupt 
> number,
>the second encodes the triger flags encoded as described in
> -  Documentation/devicetree/bindings/interrupts.txt
> +  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>  - interrupt-parent : The parent interrupt controller.
>  - interrupts : The interrupt to the parent controller raised when GPIOs
>generate the interrupts.
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index a8fee60..3d361ec 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -24,7 +24,7 @@ Required properties:
>- #interrupt-cells: the number of cells to describe an IRQ, this should be 
> 2.
>  The first cell is the IRQ number.
>  The second cell is the flags, encoded as the trigger masks from
> -Documentation/devicetree/bindings/interrupts.txt
> +Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>  
>- gpio-controller : Indicates this device is a GPIO controller.
>- #gpio-cells : Must be 2. The first cell is the pin number and the
> diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt 
> b/Documentation/devicetree/bindings/mfd/palmas.txt
> index eda8989..8ae1a32 100644
> --- a/Documentation/devicetree/bindings/mfd/palmas.txt
> +++ b/Documentation/devicetree/bindings/mfd/palmas.txt
> @@ -24,7 +24,7 @@ and also the generic series names
>  - #interrupt-cells : should be set to 2 for IRQ number and flags
>The first cell is the IRQ number.
>The second cell is the flags, encoded as the trigger masks from
> -  Documentation/devicetree/bindings/interrupts.txt
> +  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>  - interrupt-parent : The parent interrupt controller.
>  
>  Optional properties:
> diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt 
> b/Documentation/devicetree/bindings/sound/wm8994.txt
> index e045e90..68c4e8d 100644
> --- a/Documentation/devicetree/bindings/sound/wm8994.txt
> +++ b/Documentation/devicetree/bindings/sound/wm8994.txt
> @@ -30,7 +30,7 @@ Optional properties:
>- #interrupt-cells: the number of cells to describe an IRQ, this should be 
> 2.
>  The first cell is the IRQ number.
>  The second cell is the flags, encoded as the trigger masks from
> -Documentation/devicetree/bindings/interrupts.txt
> +Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>  
>- clocks : A list of up to two phandle and clock specifier pairs
>- clock-names : A list of clock names sorted in the same order as clocks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [regression] 9bd5b8dffd: BUG: unable to handle kernel NULL pointer dereference at (null)

[kernel test robot]

FYI, we noticed the below changes on

https://github.com/alaahl/linux.git for-upstream
commit 9bd5b8dffd77ec3d258425e9f4dd4f31c41a30b0 ("regression: Disable FENTRY")


+--+++
|  | e2f9dc3bd2 | 9bd5b8dffd |
+--+++
| boot_successes   | 68 | 0  |
| boot_failures| 2  | 26 |
| BUG:kernel_test_oversize | 2  ||
| BUG:unable_to_handle_kernel  | 0  | 26 |
| Oops | 0  | 26 |
| RIP:copy_process | 0  | 26 |
| Kernel_panic-not_syncing:Fatal_exception | 0  | 26 |
| backtrace:_do_fork   | 0  | 26 |
+--+++



[   78.786803] Running tests again, along with the function tracer
[   78.788785] Running tests on trace events:
[   78.790384] Testing event sys_exit: 
[   78.791562] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[   78.795018] IP: [] copy_process+0x1f/0x1826
[   78.796916] PGD 0 
[   78.798172] Oops:  [#1] SMP 
[   78.799768] CPU: 0 PID: 2 Comm: kthreadd Not tainted 
4.4.0-rc1-00163-g9bd5b8d #1
[   78.802492] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   78.805397] task: 880013f0e9c0 ti: 880013f24000 task.ti: 
880013f24000
[   78.818230] RIP: 0010:[]  [] 
copy_process+0x1f/0x1826
[   78.821196] RSP: :880013f27db0  EFLAGS: 00010282
[   78.822776] RAX: 810b23a7 RBX: 8800154f44c0 RCX: 
[   78.824760] RDX: 8800154f4498 RSI: 810b23a7 RDI: 00800711
[   78.834825] RBP: 880013f27e80 R08:  R09: 
[   78.838880] R10:  R11: 8202854a R12: 810b23a7
[   78.840819] R13:  R14: 00800711 R15: 8800154f4498
[   78.842683] FS:  () GS:880014a0() 
knlGS:
[   78.845266] CS:  0010 DS:  ES:  CR0: 8005003b
[   78.855092] CR2:  CR3: 01e08000 CR4: 06f0
[   78.859161] Stack:
[   78.860224]   8800154f4498 880013f27e78 
819c0ffe
[   78.863239]  0800 820287ce  
810b2b7c
[   78.874384]  880013f27ef8 8110a90f 81098026 
8800154f44c0
[   78.879410] Call Trace:
[   78.880440]  [] ? trace+0x5f/0x93
[   78.881843]  [] ? event_trace_self_tests_init+0x149/0x149
[   78.883582]  [] ? kthreadd+0xf4/0x13a
[   78.885041]  [] ? ftrace_ops_no_ops+0x151/0x191
[   78.894861]  [] ? kernel_thread+0x4/0x2b
[   78.898665]  [] ? __kthread_parkme+0x87/0x87
[   78.900426]  [] ? __kthread_parkme+0x87/0x87
[   78.902183]  [] ? __kthread_parkme+0x87/0x87
[   78.903943]  [] _do_fork+0xa8/0x361
[   78.913773]  [] ? __kthread_parkme+0x87/0x87
[   78.915511]  [] ? kernel_thread+0x9/0x2b
[   78.919281]  [] kernel_thread+0x29/0x2b
[   78.920931]  [] kthreadd+0xf4/0x13a
[   78.922538]  [] ? kthread_stop+0x10c/0x10c
[   78.924251]  [] ret_from_fork+0x3f/0x70
[   78.933953]  [] ? kthread_stop+0x10c/0x10c
[   78.937784] Code: 01 48 89 de e8 dd 84 0e 00 5b 5d c3 55 48 89 e5 41 57 41 
56 41 55 41 54 41 52 53 4c 8d 55 10 48 81 ec a0 00 00 00 e8 cb ab 92 00 <49> 8b 
02 48 89 7d b8 48 89 b5 50 ff ff ff 48 89 95 48 ff ff ff 
[   78.959947] RIP  [] copy_process+0x1f/0x1826
[   78.961807]  RSP 
[   78.963149] CR2: 
[   78.964464] ---[ end trace bce589f6b0fc4786 ]---
[   78.974094] Kernel panic - not syncing: Fatal exception





Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.4.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
# CONFIG_WANTS_KDUMP is not set
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEB

[PATCH v2 1/7] platform-msi: Allow MSIs to be allocated in chunks

[Marc Zyngier]

MSIs for a given device are normally all allocated in one go.
Make sure the internal code can allocate them one at a time
if required.

Signed-off-by: Marc Zyngier 
---
 drivers/base/platform-msi.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index 5df4575..6148c78 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -25,6 +25,7 @@
 #include 
 
 #define DEV_ID_SHIFT   24
+#define MAX_DEV_MSIS   (1 << (32 - DEV_ID_SHIFT))
 
 /*
  * Internal data structure containing a (made up, but unique) devid
@@ -110,13 +111,16 @@ static void platform_msi_update_chip_ops(struct 
msi_domain_info *info)
chip->irq_write_msi_msg = platform_msi_write_msg;
 }
 
-static void platform_msi_free_descs(struct device *dev)
+static void platform_msi_free_descs(struct device *dev, int base, int nvec)
 {
struct msi_desc *desc, *tmp;
 
list_for_each_entry_safe(desc, tmp, dev_to_msi_list(dev), list) {
-   list_del(&desc->list);
-   free_msi_entry(desc);
+   if (desc->platform.msi_index >= base &&
+   desc->platform.msi_index < (base + nvec)) {
+   list_del(&desc->list);
+   free_msi_entry(desc);
+   }
}
 }
 
@@ -124,17 +128,22 @@ static int platform_msi_alloc_descs(struct device *dev, 
int nvec,
struct platform_msi_priv_data *data)
 
 {
-   int i;
+   struct msi_desc *desc;
+   int i, base = 0;
 
-   for (i = 0; i < nvec; i++) {
-   struct msi_desc *desc;
+   if (!list_empty(dev_to_msi_list(dev))) {
+   desc = list_last_entry(dev_to_msi_list(dev),
+  struct msi_desc, list);
+   base = desc->platform.msi_index + 1;
+   }
 
+   for (i = 0; i < nvec; i++) {
desc = alloc_msi_entry(dev);
if (!desc)
break;
 
desc->platform.msi_priv_data = data;
-   desc->platform.msi_index = i;
+   desc->platform.msi_index = base + i;
desc->nvec_used = 1;
 
list_add_tail(&desc->list, dev_to_msi_list(dev));
@@ -142,7 +151,7 @@ static int platform_msi_alloc_descs(struct device *dev, int 
nvec,
 
if (i != nvec) {
/* Clean up the mess */
-   platform_msi_free_descs(dev);
+   platform_msi_free_descs(dev, base, nvec);
 
return -ENOMEM;
}
@@ -201,8 +210,7 @@ int platform_msi_domain_alloc_irqs(struct device *dev, 
unsigned int nvec,
 * accordingly (which would impact the max number of MSI
 * capable devices).
 */
-   if (!dev->msi_domain || !write_msi_msg || !nvec ||
-   nvec > (1 << (32 - DEV_ID_SHIFT)))
+   if (!dev->msi_domain || !write_msi_msg || !nvec || nvec > MAX_DEV_MSIS)
return -EINVAL;
 
if (dev->msi_domain->bus_token != DOMAIN_BUS_PLATFORM_MSI) {
@@ -238,7 +246,7 @@ int platform_msi_domain_alloc_irqs(struct device *dev, 
unsigned int nvec,
return 0;
 
 out_free_desc:
-   platform_msi_free_descs(dev);
+   platform_msi_free_descs(dev, 0, nvec);
 out_free_id:
ida_simple_remove(&platform_msi_devid_ida, priv_data->devid);
 out_free_data:
@@ -266,5 +274,5 @@ void platform_msi_domain_free_irqs(struct device *dev)
}
 
msi_domain_free_irqs(dev->msi_domain, dev);
-   platform_msi_free_descs(dev);
+   platform_msi_free_descs(dev, 0, MAX_DEV_MSIS);
 }
-- 
2.1.4

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

[PATCH v2 5/7] genirq/msi: Add msi_domain_populate_irqs

[Marc Zyngier]

To be able to allocate interrupts from the MSI layer down,
add a new msi_domain_populate_irqs entry point.

Signed-off-by: Marc Zyngier 
---
 include/linux/msi.h |  2 ++
 kernel/irq/msi.c| 40 
 2 files changed, 42 insertions(+)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index 1c0bb2c..cee102b 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -283,6 +283,8 @@ void platform_msi_domain_free_irqs(struct device *dev);
 /* When an MSI domain is used as an intermediate domain */
 int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
int nvec, msi_alloc_info_t *args);
+int msi_domain_populate_irqs(struct irq_domain *domain, struct device *dev,
+int virq, int nvec, msi_alloc_info_t *args);
 #endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
 
 #ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 9a85613..15b249e 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -266,6 +266,46 @@ int msi_domain_prepare_irqs(struct irq_domain *domain, 
struct device *dev,
return ret;
 }
 
+int msi_domain_populate_irqs(struct irq_domain *domain, struct device *dev,
+int virq, int nvec, msi_alloc_info_t *arg)
+{
+   struct msi_domain_info *info = domain->host_data;
+   struct msi_domain_ops *ops = info->ops;
+   struct msi_desc *desc;
+   int ret = 0;
+
+   for_each_msi_entry(desc, dev) {
+   /* Don't even try the multi-MSI brain damage. */
+   if (WARN_ON(!desc->irq || desc->nvec_used != 1)) {
+   ret = -EINVAL;
+   break;
+   }
+
+   if (!(desc->irq >= virq && desc->irq < (virq + nvec)))
+   continue;
+
+   ops->set_desc(arg, desc);
+   /* Assumes the domain mutex is held! */
+   ret = irq_domain_alloc_irqs_recursive(domain, virq, 1, arg);
+   if (ret)
+   break;
+
+   irq_set_msi_desc_off(virq, 0, desc);
+   }
+
+   if (ret) {
+   /* Mop up the damage */
+   for_each_msi_entry(desc, dev) {
+   if (!(desc->irq >= virq && desc->irq < (virq + nvec)))
+   continue;
+
+   irq_domain_free_irqs_common(domain, desc->irq, 1);
+   }
+   }
+
+   return ret;
+}
+
 /**
  * msi_domain_alloc_irqs - Allocate interrupts from a MSI interrupt domain
  * @domain:The domain to allocate from
-- 
2.1.4

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

[PATCH v2 6/7] platform-msi: Allow creation of a MSI-based stacked irq domain

[Marc Zyngier]

We almost have all the needed bits requiredable to create a irq domain
on top of a MSI domain.

For this, we enable a few things:
- the virq is stored in the msi_desc
- device, msi_alloc_info and domain-specific data
  are stored in the platform_priv_data structure
- we introduce a new API for platform-msi:

  /* Create a MSI-based domain */
  struct irq_domain *
  platform_msi_create_device_domain(struct device *dev,
unsigned int nvec,
irq_write_msi_msg_t write_msi_msg,
const struct irq_domain_ops *ops,
void *host_data);

  /* Allocate MSIs in an MSI domain */
  int platform_msi_domain_alloc(struct irq_domain *domain,
unsigned int virq,
unsigned int nr_irqs);

  /* Free MSIs from an MSI domain */
  void platform_msi_domain_free(struct irq_domain *domain,
unsigned int virq,
unsigned int nvec);

  /* Obtain the host data passed to platform_msi_create_device_domain */
  void *platform_msi_get_host_data(struct irq_domain *domain);

platform_msi_create_device_domain() is a hybrid of irqdomain creation
and interrupt allocation, creating a domain backed by the MSIs associated
to a device. IRQs can then be allocated in that domain using
platform_msi_domain_alloc().

This now allows a wired irq to MSI bridge to be created.

Signed-off-by: Marc Zyngier 
---
 drivers/base/platform-msi.c | 130 +++-
 include/linux/msi.h |  12 
 2 files changed, 140 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index 44b8c0d..a203896 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -32,6 +32,9 @@
  * and the callback to write the MSI message.
  */
 struct platform_msi_priv_data {
+   struct device   *dev;
+   void*host_data;
+   msi_alloc_info_targ;
irq_write_msi_msg_t write_msg;
int devid;
 };
@@ -124,8 +127,9 @@ static void platform_msi_free_descs(struct device *dev, int 
base, int nvec)
}
 }
 
-static int platform_msi_alloc_descs(struct device *dev, int nvec,
-   struct platform_msi_priv_data *data)
+static int platform_msi_alloc_descs_with_irq(struct device *dev, int virq,
+int nvec,
+struct platform_msi_priv_data 
*data)
 
 {
struct msi_desc *desc;
@@ -145,6 +149,7 @@ static int platform_msi_alloc_descs(struct device *dev, int 
nvec,
desc->platform.msi_priv_data = data;
desc->platform.msi_index = base + i;
desc->nvec_used = 1;
+   desc->irq = virq ? virq + i : 0;
 
list_add_tail(&desc->list, dev_to_msi_list(dev));
}
@@ -159,6 +164,13 @@ static int platform_msi_alloc_descs(struct device *dev, 
int nvec,
return 0;
 }
 
+static int platform_msi_alloc_descs(struct device *dev, int nvec,
+   struct platform_msi_priv_data *data)
+
+{
+   return platform_msi_alloc_descs_with_irq(dev, 0, nvec, data);
+}
+
 /**
  * platform_msi_create_irq_domain - Create a platform MSI interrupt domain
  * @fwnode:Optional fwnode of the interrupt controller
@@ -225,6 +237,7 @@ platform_msi_alloc_priv_data(struct device *dev, unsigned 
int nvec,
}
 
datap->write_msg = write_msi_msg;
+   datap->dev = dev;
 
return datap;
 }
@@ -288,3 +301,116 @@ void platform_msi_domain_free_irqs(struct device *dev)
msi_domain_free_irqs(dev->msi_domain, dev);
platform_msi_free_descs(dev, 0, MAX_DEV_MSIS);
 }
+
+/**
+ * platform_msi_get_host_data - Query the private data associated with
+ *  a platform-msi domain
+ * @domain:The platform-msi domain
+ *
+ * Returns the private data provided when calling
+ * platform_msi_create_device_domain.
+ */
+void *platform_msi_get_host_data(struct irq_domain *domain)
+{
+   struct platform_msi_priv_data *data = domain->host_data;
+   return data->host_data;
+}
+
+/**
+ * platform_msi_create_device_domain - Create a platform-msi domain
+ *
+ * @dev:   The device generating the MSIs
+ * @nvec:  The number of MSIs that need to be allocated
+ * @write_msi_msg: Callback to write an interrupt message for @dev
+ * @ops:   The hierarchy domain operations to use
+ * @host_data: Private data associated to this domain
+ *
+ * Returns an irqdomain for @nvec interrupts
+ */
+struct irq_domain *
+platform_msi_create_device_domain(struct device *dev,
+ unsigned int nvec,
+ irq_write_msi_msg_t write_msi

[PATCH v2 3/7] irqdomain: Make irq_domain_alloc_irqs_recursive available

[Marc Zyngier]

We are soon going to need the MSI layer to call into the domain
allocators. Instead of open coding this, make the standard
irq_domain_alloc_irqs_recursive function available to the MSI
layer.

Signed-off-by: Marc Zyngier 
---
 include/linux/irqdomain.h | 3 +++
 kernel/irq/irqdomain.c| 6 +++---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index d5e5c5b..cf96c6a 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -367,6 +367,9 @@ static inline int irq_domain_alloc_irqs(struct irq_domain 
*domain,
return __irq_domain_alloc_irqs(domain, -1, nr_irqs, node, arg, false);
 }
 
+extern int irq_domain_alloc_irqs_recursive(struct irq_domain *domain,
+  unsigned int irq_base,
+  unsigned int nr_irqs, void *arg);
 extern int irq_domain_set_hwirq_and_chip(struct irq_domain *domain,
 unsigned int virq,
 irq_hw_number_t hwirq,
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 22aa961..1c9973e 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1125,9 +1125,9 @@ static void irq_domain_free_irqs_recursive(struct 
irq_domain *domain,
}
 }
 
-static int irq_domain_alloc_irqs_recursive(struct irq_domain *domain,
-  unsigned int irq_base,
-  unsigned int nr_irqs, void *arg)
+int irq_domain_alloc_irqs_recursive(struct irq_domain *domain,
+   unsigned int irq_base,
+   unsigned int nr_irqs, void *arg)
 {
int ret = 0;
struct irq_domain *parent = domain->parent;
-- 
2.1.4

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

[PATCH v2 7/7] irqchip: [Example] dummy wired interrupt/MSI bridge driver

[Marc Zyngier]

In order to demonstrate how to put together a wire/MSI bridge,
add a dummy driver that doesn't do anything at all, except
for allocating interrupts.

It comes together with an even more stupid client driver that
allocates an interrupt and dump the hierarchy of that interrupt.

This is not a candidate for merge, hence the:

Not-Quite-Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/Kconfig   |   7 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-msichip.c | 271 ++
 3 files changed, 279 insertions(+)
 create mode 100644 drivers/irqchip/irq-msichip.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4d7294e..73e38e6 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -193,3 +193,10 @@ config IRQ_MXS
def_bool y if MACH_ASM9260 || ARCH_MXS
select IRQ_DOMAIN
select STMP_DEVICE
+
+config DUMMY_MSICHIP
+   bool "Dummy irqchip on MSI"
+   depends on GENERIC_MSI_IRQ_DOMAIN
+   help
+ Dummy stacked irqchip on top of platform MSI
+
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 177f78f..682e7dc 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_RENESAS_H8S_INTC)+= 
irq-renesas-h8s.o
 obj-$(CONFIG_ARCH_SA1100)  += irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)  += irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)+= irq-imx-gpcv2.o
+obj-$(CONFIG_DUMMY_MSICHIP)+= irq-msichip.o
diff --git a/drivers/irqchip/irq-msichip.c b/drivers/irqchip/irq-msichip.c
new file mode 100644
index 000..e0ff470
--- /dev/null
+++ b/drivers/irqchip/irq-msichip.c
@@ -0,0 +1,271 @@
+/*
+ * Non-functionnal example for a wired irq <-> MSI bridge
+ *
+ * Copyright (C) 2015 ARM Limited, All Rights Reserved.
+ * Author: Marc Zyngier 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+/*
+ * DT fragment to represent the MSI bridge:
+
+   intc: msichip {
+   compatible = "dummy,msichip";
+   num-msis = 32;
+   interrupt-controller;
+   interrupt-parent = <&gic>;
+   #interrupt-cells = <0x2>;
+   msi-parent = <&its 1234>;
+   };
+
+ * DT fragment to represent the device connected to the bridge:
+
+   dummy-dev {
+   compatible = "dummy,device";
+   interrupt-parent = <&intc>;
+   interrupts = <0x5 0x1>;
+   };
+
+ * When "dummy,device" gets probed, it dumps the hierarchy for the
+ * interrupt it has allocated:
+
+   dummydev dummy-dev: Allocated IRQ35
+   dummydev dummy-dev: Probing OK
+   dummydev dummy-dev: IRQ35 hwirq 5 domain msichip_domain_ops
+   dummydev dummy-dev: IRQ35 hwirq 0 domain msi_domain_ops
+   dummydev dummy-dev: IRQ35 hwirq 8192 domain its_domain_ops
+   dummydev dummy-dev: IRQ35 hwirq 8192 domain gic_irq_domain_ops
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void msichip_mask(struct irq_data *data)
+{
+   /* Do something */
+}
+
+static void msichip_unmask(struct irq_data *data)
+{
+   /* Do something */
+}
+
+static void msichip_eoi(struct irq_data *data)
+{
+   /* Do something */
+}
+
+static int msichip_set_type(struct irq_data *data, unsigned int type)
+{
+   /* Do something */
+   return 0;
+}
+
+static int msichip_retrigger(struct irq_data *data)
+{
+   /* Do something */
+   return 0;
+}
+
+static int msichip_set_affinity(struct irq_data *data,
+   const struct cpumask *dest, bool force)
+{
+   /* Do something */
+   return 0;
+}
+
+static struct irq_chip msichip_chip = {
+   .name   = "MSICHIP",
+   .irq_mask   = msichip_mask,
+   .irq_unmask = msichip_unmask,
+   .irq_eoi= msichip_eoi,
+   .irq_set_type   = msichip_set_type,
+   .irq_retrigger  = msichip_retrigger,
+   .irq_set_affinity   = msichip_set_affinity,
+};
+
+static int msichip_domain_translate(struct irq_domain *d,
+   struct irq_fwspec *fwspec,
+   unsigned long *hwirq,
+   unsigned int *type)
+{
+   if (is_of_node(fwspec->fwnode

[PATCH v2 2/7] platform-msi: Factor out allocation/free of private data

[Marc Zyngier]

As we're going to have multiple paths to allocate/free the
platform-msi private data, factor this out into separate
utility functions.

Signed-off-by: Marc Zyngier 
---
 drivers/base/platform-msi.c | 94 +
 1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
index 6148c78..44b8c0d 100644
--- a/drivers/base/platform-msi.c
+++ b/drivers/base/platform-msi.c
@@ -189,21 +189,11 @@ struct irq_domain *platform_msi_create_irq_domain(struct 
fwnode_handle *fwnode,
return domain;
 }
 
-/**
- * platform_msi_domain_alloc_irqs - Allocate MSI interrupts for @dev
- * @dev:   The device for which to allocate interrupts
- * @nvec:  The number of interrupts to allocate
- * @write_msi_msg: Callback to write an interrupt message for @dev
- *
- * Returns:
- * Zero for success, or an error code in case of failure
- */
-int platform_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec,
-  irq_write_msi_msg_t write_msi_msg)
+static struct platform_msi_priv_data *
+platform_msi_alloc_priv_data(struct device *dev, unsigned int nvec,
+irq_write_msi_msg_t write_msi_msg)
 {
-   struct platform_msi_priv_data *priv_data;
-   int err;
-
+   struct platform_msi_priv_data *datap;
/*
 * Limit the number of interrupts to 256 per device. Should we
 * need to bump this up, DEV_ID_SHIFT should be adjusted
@@ -211,33 +201,62 @@ int platform_msi_domain_alloc_irqs(struct device *dev, 
unsigned int nvec,
 * capable devices).
 */
if (!dev->msi_domain || !write_msi_msg || !nvec || nvec > MAX_DEV_MSIS)
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
 
if (dev->msi_domain->bus_token != DOMAIN_BUS_PLATFORM_MSI) {
dev_err(dev, "Incompatible msi_domain, giving up\n");
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
}
 
/* Already had a helping of MSI? Greed... */
if (!list_empty(dev_to_msi_list(dev)))
-   return -EBUSY;
+   return ERR_PTR(-EBUSY);
+
+   datap = kzalloc(sizeof(*datap), GFP_KERNEL);
+   if (!datap)
+   return ERR_PTR(-ENOMEM);
+
+   datap->devid = ida_simple_get(&platform_msi_devid_ida,
+ 0, 1 << DEV_ID_SHIFT, GFP_KERNEL);
+   if (datap->devid < 0) {
+   int err = datap->devid;
+   kfree(datap);
+   return ERR_PTR(err);
+   }
 
-   priv_data = kzalloc(sizeof(*priv_data), GFP_KERNEL);
-   if (!priv_data)
-   return -ENOMEM;
+   datap->write_msg = write_msi_msg;
 
-   priv_data->devid = ida_simple_get(&platform_msi_devid_ida,
- 0, 1 << DEV_ID_SHIFT, GFP_KERNEL);
-   if (priv_data->devid < 0) {
-   err = priv_data->devid;
-   goto out_free_data;
-   }
+   return datap;
+}
+
+static void platform_msi_free_priv_data(struct platform_msi_priv_data *data)
+{
+   ida_simple_remove(&platform_msi_devid_ida, data->devid);
+   kfree(data);
+}
+
+/**
+ * platform_msi_domain_alloc_irqs - Allocate MSI interrupts for @dev
+ * @dev:   The device for which to allocate interrupts
+ * @nvec:  The number of interrupts to allocate
+ * @write_msi_msg: Callback to write an interrupt message for @dev
+ *
+ * Returns:
+ * Zero for success, or an error code in case of failure
+ */
+int platform_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec,
+  irq_write_msi_msg_t write_msi_msg)
+{
+   struct platform_msi_priv_data *priv_data;
+   int err;
 
-   priv_data->write_msg = write_msi_msg;
+   priv_data = platform_msi_alloc_priv_data(dev, nvec, write_msi_msg);
+   if (IS_ERR(priv_data))
+   return PTR_ERR(priv_data);
 
err = platform_msi_alloc_descs(dev, nvec, priv_data);
if (err)
-   goto out_free_id;
+   goto out_free_priv_data;
 
err = msi_domain_alloc_irqs(dev->msi_domain, dev, nvec);
if (err)
@@ -247,10 +266,8 @@ int platform_msi_domain_alloc_irqs(struct device *dev, 
unsigned int nvec,
 
 out_free_desc:
platform_msi_free_descs(dev, 0, nvec);
-out_free_id:
-   ida_simple_remove(&platform_msi_devid_ida, priv_data->devid);
-out_free_data:
-   kfree(priv_data);
+out_free_priv_data:
+   platform_msi_free_priv_data(priv_data);
 
return err;
 }
@@ -261,16 +278,11 @@ out_free_data:
  */
 void platform_msi_domain_free_irqs(struct device *dev)
 {
-   struct msi_desc *desc;
-
-   desc = first_msi_entry(dev);
-   if (desc) {
-   struct platform_msi_priv_data *data;
-
-   data = desc->platform.msi_priv_data;
+   if (!list_empty(dev_to_msi_list(dev))) {
+ 

[PATCH v2 4/7] genirq/msi: Make the .prepare callback reusable

[Marc Zyngier]

The .prepare callbacks are so far only called from msi_domain_alloc_irqs.
In order to reuse that code, split that code and create a
msi_domain_prepare_irqs function that the existing code can call into.

Signed-off-by: Marc Zyngier 
---
 include/linux/msi.h |  4 
 kernel/irq/msi.c| 18 +++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index f71a25e..1c0bb2c 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -279,6 +279,10 @@ struct irq_domain *platform_msi_create_irq_domain(struct 
fwnode_handle *fwnode,
 int platform_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec,
   irq_write_msi_msg_t write_msi_msg);
 void platform_msi_domain_free_irqs(struct device *dev);
+
+/* When an MSI domain is used as an intermediate domain */
+int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
+   int nvec, msi_alloc_info_t *args);
 #endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
 
 #ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 6b0c0b7..9a85613 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -252,6 +252,20 @@ struct irq_domain *msi_create_irq_domain(struct 
fwnode_handle *fwnode,
   &msi_domain_ops, info);
 }
 
+int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
+   int nvec, msi_alloc_info_t *arg)
+{
+   struct msi_domain_info *info = domain->host_data;
+   struct msi_domain_ops *ops = info->ops;
+   int ret;
+
+   ret = ops->msi_check(domain, info, dev);
+   if (ret == 0)
+   ret = ops->msi_prepare(domain, dev, nvec, arg);
+
+   return ret;
+}
+
 /**
  * msi_domain_alloc_irqs - Allocate interrupts from a MSI interrupt domain
  * @domain:The domain to allocate from
@@ -270,9 +284,7 @@ int msi_domain_alloc_irqs(struct irq_domain *domain, struct 
device *dev,
struct msi_desc *desc;
int i, ret, virq = -1;
 
-   ret = ops->msi_check(domain, info, dev);
-   if (ret == 0)
-   ret = ops->msi_prepare(domain, dev, nvec, &arg);
+   ret = msi_domain_prepare_irqs(domain, dev, nvec, &arg);
if (ret)
return ret;
 
-- 
2.1.4

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

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

[Joonsoo Kim]

On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:
> On Fri, 20 Nov 2015 15:33:25 +0900
> Joonsoo Kim  wrote:
> 
> 
> > Steven, is it possible to add tracepoint to inlined fucntion such as
> > get_page() in include/linux/mm.h?
> 
> I highly recommend against it. The tracepoint code adds a bit of bloat,
> and if you inline it, you add that bloat to every use case. Also, it

Is it worse than adding function call to my own stub function into
inlined function such as get_page(). I implemented it as following.

get_page()
{
atomic_inc()
stub_get_page()
}

stub_get_page() in foo.c
{
trace_page_ref_get_page()
}

> makes things difficult if this file is included in other files that
> create tracepoints, which I could easily imagine would be the case.
> That is, if a tracepoint file in include/trace/events/foo.h needs to
> include include/linux/mm.h, when you do CREATE_TRACEPOINTS for foo.h,
> it will create tracepoints for mm.h as to use tracepoints there you
> would need to include the include/trace/events/mm.h (or whatever its
> name is), and that has caused issues in the past.
> 
> Now, if you still want to have these tracepoints in the inlined
> function, it would be best to add a new file mm_trace.h? or something
> that would include it, and then have only the .c files include that
> directly. Do not put it into mm.h as that would definitely cause
> tracepoint include troubles.

Okay. If I choose this way, I have to change too many places and churn
the code. If bloat of my implementation is similar with this suggestion,
I prefer my implementation.

Thanks for good advice.

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 v2 0/7] Adding core support for wire-MSI bridges

[Marc Zyngier]

There seems to be a new class of interrupt controller out there whose
sole purpose (apart from making everybody's life a nightmare) is to
turn wired interrupts into MSIs (see [1] for a prime example of the
what this actually is).

Instead of considering that the MSIs allocated to a device are for the
direct use of that device, we can turn this set of MSIs into a irq
domain, and use this domain to back a stacked irqchip implemented by
the device. When combined with a GICv3 and its ITS, we end-up with the
following stack:

  wireMSI
Client-device > Bridge-Device > Platform-MSI -> ITS -> GICv3

where we have a 1:1 mapping between wired interrupts and MSIs.

This requires some (slightly ugly) surgery in both the generic MSI and
platform MSI layers, but the amount of code is actually relatively
small (about +220 LoC so far).

On top of that, we add a dummy driver for a such a bridge, hoping that
this will give enough information to driver authors so that they can
use this new feature. An even more stupid client driver is provided to
show the interrupt stack allocation:

 dummydev dummy-dev: Probing
 dummydev dummy-dev: Allocated IRQ35
 dummydev dummy-dev: Probing OK
 dummydev dummy-dev: IRQ35 hwirq 5 domain msichip_domain_ops
 dummydev dummy-dev: IRQ35 hwirq 0 domain msi_domain_ops
 dummydev dummy-dev: IRQ35 hwirq 8192 domain its_domain_ops
 dummydev dummy-dev: IRQ35 hwirq 8192 domain gic_irq_domain_ops

Of course, it goes without saying that this last patch is not to be
merged...

While this does work, it is far from being perfect:

- It relies on not declaring this bridge with IRQCHIP_DECLARE in order
  to prevent the DT layer from allocating interrupts behind our back.

- There are probe ordering issues between the bridge and the wired
  interrupt device, leading to the use of -EPROBE_DEFER.

The last two points could be addressed directly in the OF layer, as
this is a generic device ordering issue (and people are already
working on that).

* From v1:
  - Added the error handling that was completely absent from the original
prototype
  - Allow interrupts to be freed
  - Added API documentation
  - Rebased on top of 4.4-rc1

[1] https://lkml.org/lkml/2015/11/22/244

Marc Zyngier (7):
  platform-msi: Allow MSIs to be allocated in chunks
  platform-msi: Factor out allocation/free of private data
  irqdomain: Make irq_domain_alloc_irqs_recursive available
  genirq/msi: Make the .prepare callback reusable
  genirq/msi: Add msi_domain_populate_irqs
  platform-msi: Allow creation of a MSI-based stacked irq domain
  irqchip: [Example] dummy wired interrupt/MSI bridge driver

 drivers/base/platform-msi.c   | 254 ++-
 drivers/irqchip/Kconfig   |   7 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-msichip.c | 271 ++
 include/linux/irqdomain.h |   3 +
 include/linux/msi.h   |  18 +++
 kernel/irq/irqdomain.c|   6 +-
 kernel/irq/msi.c  |  58 -
 8 files changed, 558 insertions(+), 60 deletions(-)
 create mode 100644 drivers/irqchip/irq-msichip.c

-- 
2.1.4

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

[PATCH] lightnvm: free allocated memory when gennvm register fails

[Wenwei Tao]

free allocated nvm block and gennvm lun structures when
gennvm register fails, otherwise it will cause memory leak.

Signed-off-by: Wenwei Tao 
---
 drivers/lightnvm/gennvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c
index ae1fb2b..03fc7a5 100644
--- a/drivers/lightnvm/gennvm.c
+++ b/drivers/lightnvm/gennvm.c
@@ -211,12 +211,15 @@ static int gennvm_register(struct nvm_dev *dev)
ret = gennvm_blocks_init(dev, gn);
if (ret) {
pr_err("gennvm: could not initialize blocks\n");
+   gennvm_blocks_free(dev);
+   gennvm_luns_free(dev);
goto err;
}
 
return 1;
 err:
kfree(gn);
+   dev->mp = NULL;
return ret;
 }
 
-- 
1.8.3.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: WARNING in shmem_evict_inode

[Dmitry Vyukov]

On Mon, Nov 9, 2015 at 9:55 AM, Dmitry Vyukov  wrote:
> Hello,
>
> The following program:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include 
> #include 
> #include 
> #include 
>
> #define SYS_memfd_create 319
>
> long fd;
>
> void *thr(void *p)
> {
> syscall(SYS_ftruncate, fd, 0x8ul, 0, 0, 0, 0);
> return 0;
> }
>
> int main()
> {
> pthread_t th;
>
> syscall(SYS_mmap, 0x2000ul, 0x1ul, 0x3ul, 0x32ul,
> 0xul, 0x0ul);
> memcpy((void*)0x2f96, "\x23\x65\x6d\x31\x07\x2b\x27\x29\x00", 9);
> fd = syscall(SYS_memfd_create, 0x2f96ul, 0x2ul, 0, 0, 0, 0);
> syscall(SYS_fallocate, fd, 0x0ul, 0x31d89288ul, 0x4ul, 0, 0);
> syscall(SYS_mmap, 0x20061000ul, 0xc0ul,
> 0x1a9d91e04768640bul, 0x11ul, fd, 0x0ul);
> pthread_create(&th, 0, thr, 0);
> syscall(SYS_fstat, fd, 0x20550fcful, 0, 0, 0, 0);
> pthread_join(th, 0);
> return 0;
> }
>
>
> triggers WARNING in shmem_evict_inode:
>
> [ cut here ]
> WARNING: CPU: 0 PID: 10442 at mm/shmem.c:625 shmem_evict_inode+0x335/0x480()
> Modules linked in:
> CPU: 1 PID: 8944 Comm: executor Not tainted 4.3.0+ #39
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>   88006c6afab8 81aad406 
>  88006e39ac80 83091660 88006c6afaf8 81100829
>  814192e5 83091660 0271 88003d075aa8
> Call Trace:
>  [] warn_slowpath_null+0x29/0x30 kernel/panic.c:480
>  [] shmem_evict_inode+0x335/0x480 mm/shmem.c:625
>  [] evict+0x26e/0x580 fs/inode.c:542
>  [< inline >] iput_final fs/inode.c:1477
>  [] iput+0x4a0/0x790 fs/inode.c:1504
>  [< inline >] dentry_iput fs/dcache.c:358
>  [] __dentry_kill+0x4fe/0x700 fs/dcache.c:543
>  [< inline >] dentry_kill fs/dcache.c:587
>  [] dput+0x6ab/0x7a0 fs/dcache.c:796
>  [] __fput+0x3fb/0x6e0 fs/file_table.c:226
>  [] fput+0x15/0x20 fs/file_table.c:244
>  [] task_work_run+0x163/0x1f0 kernel/task_work.c:115
>  [< inline >] exit_task_work include/linux/task_work.h:21
>  [] do_exit+0x7f9/0x2b80 kernel/exit.c:748
>  [] do_group_exit+0x108/0x320 kernel/exit.c:878
>  [< inline >] SYSC_exit_group kernel/exit.c:889
>  [] SyS_exit_group+0x1d/0x20 kernel/exit.c:887
> ---[ end trace 43da88a03e29c2a5 ]---
>
>
> Run the program in a loop, as the WARNING seems to be triggered by a race.
>
> On commit d1e41ff11941784f469f17795a4d9425c2eb4b7a (Nov 5).
> But I was also able to reproduce it on a 3.11-based kernel.


Hello,

This is still happening periodically for me. Is anybody looking at this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Sebastian Hesselbarth]

On 23.11.2015 08:21, Jisheng Zhang wrote:

On Fri, 20 Nov 2015 22:06:59 +0100
Sebastian Hesselbarth wrote:

On 20.11.2015 09:42, Jisheng Zhang wrote:

Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.

Signed-off-by: Jisheng Zhang 
---

[...]

+   syspll: syspll {
+   compatible = "marvell,berlin-pll";
+   reg = <0xea0200 0x14>, <0xea0710 4>;
+   #clock-cells = <0>;
+   clocks = <&osc>;
+   bypass-shift = /bits/ 8 <0>;
+   };
+
+   gateclk: gateclk {
+   compatible = "marvell,berlin4ct-gateclk";
+   reg = <0xea0700 4>;
+   #clock-cells = <1>;
+   };
+
+   clk: clk {
+   compatible = "marvell,berlin4ct-clk";
+   reg = <0xea0720 0x144>;


Looking at the reg ranges, I'd say that they are all clock related
and pretty close to each other:

gateclk: reg = <0xea0700 4>;
bypass:  reg = <0xea0710 4>;
clk: reg = <0xea0720 0x144>;


Although these ranges sit close, but we should represent HW structure as you
said.


Then how do you argue that you have to share the gate clock register
with every PLL? The answer is quite simple: You are not separating by
HW either but existing SW API.

If you would really want to just describe the HW, then you'd have to
have a single node for _all_ clocks that get controlled by 0xea0700/0x4,
feed some 32+ clocks into the node, and out again. Obviously, this
isn't what we want, right?

So, the idea of berlin2 sysctrl nodes (and similar other SoCs) is: Some
SoCs just dump some functions into a bunch of registers with no
particular order. We'd never find a good representation for that in DT,
so we don't bother to try but let the driver implementation deal with
the mess. Using "simple-mfd" is a nice solution to scattered registers
please have a look at it and come up with a cleaner separation for bg4
clock.


First of all, let me describe the clks/plls in BG4CT. BG4CT contains:

two kinds of PLL: normal PLL and AVPLL. These PLLs are put with their users
together. For example: mempll pll registers <0xf7940034, 0x14> is put together
with mem controller registers. AVPLL control registers are put with AV devices.


Why didn't you choose to have a memory-controller node that provides
mempll clock then? I am open to having multiple nodes providing clocks
but having a node for every clock in any subsystem is something I'll
not even think about.


You can also check mempll, cpupll and syspll ranges:

cpupll: <0x922000 0x14>

mempll: <0x940034 0x14>

syspll: <0xea0200 0x14>


We have three normal PLLS: cpupll, mempll and syspll. All these three PLLs use
25MHZ osc as clocksource. These plls can be bypassed. when syspll is bypassed
the 25MHZ osc is directly output to syspllclk. When mempll/cpupll is bypassed,
its corresponding fastrefclk is directly output to ddrphyclk/cpuclk:


---25MHZ osc--|\
| |-- syspllclk
---| SYSPLL |-|/



---cpufastrefclk--|\
| |-- cpuclk
---| CPUPLL |-|/


---memfastrefclk--|\
| |-- ddrphyclk
---| MEMPLL |-|/

NOTE: the fastrefclk is the so called normal clk below.



two kinds of clk: normal clk and gate clk. The normal clk supports changing
divider, selecting clock source, disabling/enabling etc. The gate clk only
supports disabling/enabling. normal clks use syspllclk as clocksource, while
gate clks use perifsysclk as clocksource.


So what's the representing HW structure in fact? Here is my proposal:
1. have mempll, cpupll and syspll node in dts


No.


2. one gateclk node in dts for gateclks


No.


3. one normalclk node in dts for normal clks


No.


4. one ccf clock-mux for cpuclk, ddrphyclk and syspllclk.


No.


what do you think?


I think that the current separation is not a good one. I am open for
suggestions but I am not accepting single PLL/clock nodes.


 From another side, let's have a look at driver/clk/mvebu. As can be seen,
different clks register are close each other, for example, gateclk and coreclk
in arch/arm/boot/dts/armada-xp.dtsi.

And drivers/clk/sunxi, arch/arm/boot/dts/sun7i-a20.dtsi, the pll4, pll12, gt_clk
and ahb*, apb* etc...

why these SoCs don't merge clocks/gates/plls to a single clock complex node?
I think that's because they are representing real HW structure.


These SoC (at least mvebu) didn't merge them into a single clock
complex node because nobody had a better idea or an impression of
the consequences. Looking back with the idea of syscon/simple-mfd
we probably would have chosen to separate differently.


So, please just follow the OF/driver structure we already
have for Berlin2.


To repeat: "please just follow the OF/driver structure we already
have for Berlin2"

Sebastian


+ 

Re: [PATCH v4 3/3] usb: chipidea: register driver as a peripheral with the phy

[Peter Chen]

On Fri, Nov 20, 2015 at 03:47:20PM -0800, Tim Bird wrote:
> Register the chipidea driver with the phy, so that the phy
> driver can kick the gadget driver when it resumes from low power.
> The phy-msm-usb (Qualcomm) driver requires this in order to
> recover gadget operation after you disconnect the USB cable
> and reconnect it.
> 
> Signed-off-by: Tim Bird 
> ---
>  drivers/usb/chipidea/udc.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 8223fe7..06234cd 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1890,6 +1890,12 @@ static int udc_start(struct ci_hdrc *ci)
>  
>   ci->gadget.ep0 = &ci->ep0in->ep;
>  
> + if (ci->usb_phy) {
> + retval = otg_set_peripheral(ci->usb_phy->otg, &ci->gadget);
> + if (retval)
> + goto destroy_eps;
> + }
> +
>   retval = usb_add_gadget_udc(dev, &ci->gadget);
>   if (retval)
>   goto destroy_eps;

Hi Tim,

I am afraid it can't work for current chipidea framework (find this
problem after testing), the chipidea core manages its host and device
function using its own API start/stop, it does not define struct usb_otg
APIs. In fact, it is not reasonable control host and device function
at PHY driver.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Deadlock between bind and splice

[Dmitry Vyukov]

On Tue, Nov 10, 2015 at 3:59 AM, Al Viro  wrote:
> On Tue, Nov 10, 2015 at 02:38:54AM +, Al Viro wrote:
>> On Fri, Nov 06, 2015 at 07:42:15AM -0800, Eric Dumazet wrote:
>>
>> > Thank you for this report.
>> >
>> > pipe is part of fs, not net ;)
>>
>> AF_UNIX bind() vs. socketpair() interplay, OTOH...
>
> FWIW, BSD folks unlock the socket for the duration of mknod - mark it as
> "somebody's trying to bind it" to avoid the fun with racing double bind(),
> but that's about it.  Tempting, to be honest...
>
> BTW, why does unix_autobind() do allocation under ->readlock?  The allocation
> will be normally used - that if (u->addr) return; part is just dealing with
> an unlikely race, as far as I can see...


Hello,

This is still happening periodically for me. Is there a proposed fix?
I could test it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lightnvm: free allocated memory when gennvm register fails

[Matias Bjørling]

On 11/23/2015 09:29 AM, Wenwei Tao wrote:

free allocated nvm block and gennvm lun structures when
gennvm register fails, otherwise it will cause memory leak.

Signed-off-by: Wenwei Tao 
---
  drivers/lightnvm/gennvm.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c
index ae1fb2b..03fc7a5 100644
--- a/drivers/lightnvm/gennvm.c
+++ b/drivers/lightnvm/gennvm.c
@@ -211,12 +211,15 @@ static int gennvm_register(struct nvm_dev *dev)
ret = gennvm_blocks_init(dev, gn);
if (ret) {
pr_err("gennvm: could not initialize blocks\n");
+   gennvm_blocks_free(dev);
+   gennvm_luns_free(dev);
goto err;
}

return 1;
  err:
kfree(gn);
+   dev->mp = NULL;
return ret;
  }



Thanks Tao, would it be okay with you if I apply the patch like this:

diff --git i/drivers/lightnvm/gennvm.c w/drivers/lightnvm/gennvm.c
index e20e74e..3969a98 100644
--- i/drivers/lightnvm/gennvm.c
+++ w/drivers/lightnvm/gennvm.c
@@ -207,6 +207,14 @@ static int gennvm_blocks_init(struct nvm_dev *dev, 
struct gen_nvm *gn)

return 0;
 }

+static void gennvm_free(struct nvm_dev *dev)
+{
+   gennvm_blocks_free(dev);
+   gennvm_luns_free(dev);
+   kfree(dev->mp);
+   dev->mp = NULL;
+}
+
 static int gennvm_register(struct nvm_dev *dev)
 {
struct gen_nvm *gn;
@@ -234,16 +242,13 @@ static int gennvm_register(struct nvm_dev *dev)

return 1;
 err:
-   kfree(gn);
+   gennvm_free(dev);
return ret;
 }

 static void gennvm_unregister(struct nvm_dev *dev)
 {
-   gennvm_blocks_free(dev);
-   gennvm_luns_free(dev);
-   kfree(dev->mp);
-   dev->mp = NULL;
+   gennvm_free(dev);
 }


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

Re: [PATCH 4/6] PM / devfreq: Set the freq_table of devfreq device

[Chanwoo Choi]

On Mon, Nov 23, 2015 at 4:29 PM, MyungJoo Ham  wrote:
>>
>>  This patch initialize the freq_table array of each devfreq device by using
>> the devfreq_set_freq_table(). If freq_table is NULL, the devfreq framework
>> is not able to support the frequency transtion information through sysfs.
>>
>> The OPP core uses the integer type for the number of opps in the opp list
>> and uses the 'unsigned long' type for each frequency. So, this patch modifies
>> the type of some variable as following:
>> - the type of freq_table : unsigned int -> unsigned long
>> - the type of max_state  : unsigned int -> int
>>
>> Signed-off-by: Chanwoo Choi 
> []
>> +/**
>>   * devfreq_update_status() - Update statistics of devfreq behavior
>>   * @devfreq: the devfreq instance
>>   * @freq:the update target frequency
>> @@ -477,7 +516,12 @@ struct devfreq *devfreq_add_device(struct device *dev,
>>   devfreq->previous_freq = profile->initial_freq;
>>   devfreq->data = data;
>>   devfreq->nb.notifier_call = devfreq_notifier_call;
>> + mutex_unlock(&devfreq->lock);
>>
>> + if (devfreq->profile->max_state <= 0 && !devfreq->profile->freq_table)
>> + devfreq_set_freq_table(devfreq);
>> +
>> + mutex_lock(&devfreq->lock);
>
> Anyway, what about modifying the block above as:
>
> +   if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
> +   mutex_unlock(&devfreq->lock);
> devfreq_set_freq_table(devfreq);
> +   mutex_lock(&devfreq->lock);
> +   }
>
>>   devfreq->trans_table =  devm_kzalloc(dev, sizeof(unsigned int) *
>>   devfreq->profile->max_state *
>>   devfreq->profile->max_state,
> []
>
> If that's not a problem, I'll squash
> https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/commit/?h=for-rafael&id=55df2b43cdb5ac82d26b64d739f3d758c9b7486c
> with the given patch.

I agree. Thanks for fixing this.

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

Re: Re: [PATCH 6/6] PM / devfreq: Set the min_freq and max_freq of devfreq device

[Chanwoo Choi]

On Mon, Nov 23, 2015 at 4:21 PM, MyungJoo Ham  wrote:
> []
>> >
>> > The value 0 is used for min/max_freq to declare
>> > that min/max_freq is deactivated. Therefore, it is not
>> > required to do so; they are not intended to show the hardware
>> > configuration as well.
>>
>> This case consider the devfreq device using OPP because 
>> devfreq_set_freq_table()
>> get the number of OPP entry in OPP list before setting the min_freq/max_freq.
>> If the devfreq device don't use the OPP entry, devfreq_set_freq_table()
>> will return without any operation.
>>
>> IMHO, when devfreq device uses the OPP table including the frequency,
>> min_freq/max_freq should show the correct value as CPUFREQ framework.
>>
>
> The side effect of this patch shows up when opp_disable() and opp_enable()
> are used.

Ah. You're right.
I was not considering the the case of using opp_disable() and opp_enable().
I'll consider it again including the usage case of opp_diable/opp_enable.

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

Re: [PATCHSET v3] netfilter, cgroup: implement cgroup2 path match in xt_cgroup

[Daniel Wagner]

On 11/23/2015 08:11 AM, Daniel Wagner wrote:
> [3.217648] systemd[1]: tmp.mount: Directory /tmp to mount over is not 
> empty, mounting anyway.
> [3.224665] BUG: spinlock bad magic on CPU#1, systemd/1
> [3.225653]  lock: cgroup_sk_update_lock+0x0/0x60, .magic: , 
> .owner: systemd/1, .owner_cpu: 1
> [3.227034] CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #195
> [3.227862] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> [3.228906]  834a2160 88007c043ad0 81551edc 
> 88007c028000
> [3.229512]  88007c043af0 81136868 834a2160 
> 88007aff5940
> [3.230105]  88007c043b08 81136b05 834a2160 
> 88007c043b20
> [3.230716] Call Trace:
> [3.230906]  [] dump_stack+0x4e/0x82
> [3.231289]  [] spin_dump+0x78/0xc0
> [3.231642]  [] do_raw_spin_unlock+0x75/0xd0
> [3.232039]  [] _raw_spin_unlock+0x27/0x50
> [3.232431]  [] update_classid_sock+0x68/0x80
> [3.232836]  [] iterate_fd+0x71/0x150
> [3.233197]  [] update_classid+0x47/0x80
> [3.233571]  [] cgrp_attach+0x14/0x20
> [3.233929]  [] cgroup_taskset_migrate+0x1e1/0x330
> [3.234366]  [] cgroup_migrate+0xf5/0x190
> [3.234747]  [] ? cgroup_migrate+0x5/0x190
> [3.235130]  [] cgroup_attach_task+0x176/0x200
> [3.235543]  [] ? cgroup_attach_task+0x5/0x200
> [3.235953]  [] __cgroup_procs_write+0x2ad/0x460
> [3.236377]  [] ? __cgroup_procs_write+0x5e/0x460
> [3.236805]  [] cgroup_procs_write+0x14/0x20
> [3.237205]  [] cgroup_file_write+0x35/0x1c0
> [3.237600]  [] kernfs_fop_write+0x141/0x190
> [3.237998]  [] __vfs_write+0x28/0xe0
> [3.238361]  [] ? percpu_down_read+0x57/0xa0
> [3.238761]  [] ? __sb_start_write+0xb4/0xf0
> [3.239154]  [] ? __sb_start_write+0xb4/0xf0
> [3.239554]  [] vfs_write+0xac/0x1a0
> [3.239930]  [] ? __fget_light+0x66/0x90
> [3.240308]  [] SyS_write+0x49/0xb0
> [3.240656]  [] entry_SYSCALL_64_fastpath+0x12/0x76

I have enabled a few additional cgroup controllers as well, because I was
trying to figure out why I only see the 'memory' cgroup controller in 
cgroup.controllers. pid and io show up but not net_prio or net_cls.
Not sure why systemd (v227) is not mounting them.

Though, after a while a similar call trace is produced. I guess this
has nothing to do with the current changes.

[   11.594536] [ cut here ]
[   11.595274] WARNING: CPU: 1 PID: 1 at kernel/cgroup_pids.c:97 
pids_cancel.constprop.6+0x31/0x40()
[   11.595958] Modules linked in:
[   11.596199] CPU: 1 PID: 1 Comm: systemd Not tainted 4.4.0-rc1+ #196
[   11.596689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
[   11.597632]  81f66d8b 88007c04bb90 8155ccdc 

[   11.598234]  88007c04bbc8 810de202 8800793dda00 
88007a096800
[   11.598877]  88007c04bc80 88007a6b6200 0001 
88007c04bbd8
[   11.599547] Call Trace:
[   11.599784]  [] dump_stack+0x4e/0x82
[   11.600197]  [] warn_slowpath_common+0x82/0xc0
[   11.600705]  [] warn_slowpath_null+0x1a/0x20
[   11.601208]  [] pids_cancel.constprop.6+0x31/0x40
[   11.601764]  [] pids_can_attach+0x6d/0xf0
[   11.602245]  [] cgroup_taskset_migrate+0x6a/0x330
[   11.602795]  [] cgroup_migrate+0xf5/0x190
[   11.603276]  [] ? cgroup_migrate+0x5/0x190
[   11.603788]  [] cgroup_attach_task+0x176/0x200
[   11.604308]  [] ? cgroup_attach_task+0x5/0x200
[   11.604831]  [] __cgroup_procs_write+0x2ad/0x460
[   11.605367]  [] ? __cgroup_procs_write+0x5e/0x460
[   11.605929]  [] cgroup_procs_write+0x14/0x20
[   11.606448]  [] cgroup_file_write+0x35/0x1c0
[   11.606931]  [] kernfs_fop_write+0x141/0x190
[   11.607401]  [] __vfs_write+0x28/0xe0
[   11.607834]  [] ? percpu_down_read+0x57/0xa0
[   11.608366]  [] ? __sb_start_write+0xb4/0xf0
[   11.608874]  [] ? __sb_start_write+0xb4/0xf0
[   11.609343]  [] vfs_write+0xac/0x1a0
[   11.609843]  [] ? __fget_light+0x66/0x90
[   11.610315]  [] SyS_write+0x49/0xb0
[   11.610756]  [] entry_SYSCALL_64_fastpath+0x12/0x76
[   11.611305] ---[ end trace 7f953d0ce5af99ea ]---

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

[Daniel Vetter]

On Sat, Nov 21, 2015 at 03:22:07PM +0100, Christian König wrote:
> On 20.11.2015 16:52, cp...@redhat.com wrote:
> >From: Stephen Chandler Paul 
> >
> >HPD signals on DVI ports can be fired off before the pins required for
> >DDC probing actually make contact, due to the pins for HPD making
> >contact first. This results in a HPD signal being asserted but DDC
> >probing failing, resulting in hotplugging occasionally failing.
> >
> >This is somewhat rare on most cards (depending on what angle you plug
> >the DVI connector in), but on some cards it happens constantly. The
> >Radeon R5 on the machine used for testing this patch for instance, runs
> >into this issue just about every time I try to hotplug a DVI monitor and
> >as a result hotplugging almost never works.
> >
> >Rescheduling the hotplug work for a second when we run into an HPD
> >signal with a failing DDC probe usually gives enough time for the rest
> >of the connector's pins to make contact, and fixes this issue.
> >
> >Signed-off-by: Stephen Chandler Paul 
> 
> Yeah, that's something I always wondered a about bit as well.
> 
> Debouncing is something very common done in electronics, but as far as I
> know the HPD pins don't necessary have an RC circuit so we might need to
> handle this case in software here.
> 
> A delay of something between 10-30ms between the last HPD interrupt and
> further processing of the signal doesn't sounds like such a bad idea.
> 
> Retrying on the other hand doesn't necessarily improve the situation cause
> the delay introduced by this might not be enough.
> 
> So I would rather vote for a fixed delay between an HPD interrupt and
> actually starting to process anything.

Might be interesting to compare what we do in i915 in latest kernels:

- in the hpd handler we check the hpd status bits before probing the edid.
  This will take care of slow unplug case where we get the hpd
  interrupt/status change, but i2c is still working.

- but because crap screens (or whatever it is) if hpd is _not_ set we
  retest the status for 30ms (and bail out as soon as hpd status is
  asserted). This seems to be enough time to settle all screens.

Note that this is in intel_hdmi.c since native dvi ports on intel hw also
always supported hdmi features. Not sure whether we could extract this
into some kind of helper and share.
-Daniel


> 
> Regards,
> Christian.
> 
> >---
> >So this one has kind of been a tough sell with Jerome, mostly because it's
> >somewhat of a hack. Unfortunately however I've managed to find machines where
> >DVI hotplugging literally doesn't work without a patch like this. We've 
> >already
> >tried a couple of ways of handling the situation of retriggering ddc probes:
> >
> >* Trying the DDC probe in the radeon_dvi_detect() function multiple times.
> >* Trying to reschedule the hotplug_work task whenever DDC probing fails on 
> >DVI
> >   but we got a hpd signal (this ended up being a much more complicated patch
> >   then anticipated)
> >* Doing what we do right now, which is just triggering userspace to rescan 
> >all
> >   the ports when the hpd signal is asserted by the DVI port but there's no 
> > DDC
> >   probe, and repeating until at least a second passes.
> >
> >All of these actually work, but I guess it's a question of which one is less 
> >of
> >a hack. If anyone here can think of a cleaner way of handling this feel free 
> >to
> >let me know.
> >
> >  drivers/gpu/drm/radeon/radeon.h|  3 +++
> >  drivers/gpu/drm/radeon/radeon_connectors.c | 20 +---
> >  drivers/gpu/drm/radeon/radeon_irq_kms.c|  2 ++
> >  3 files changed, 22 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/radeon/radeon.h 
> >b/drivers/gpu/drm/radeon/radeon.h
> >index b6cbd81..d63f0fe 100644
> >--- a/drivers/gpu/drm/radeon/radeon.h
> >+++ b/drivers/gpu/drm/radeon/radeon.h
> >@@ -2460,6 +2460,9 @@ struct radeon_device {
> > /* amdkfd interface */
> > struct kfd_dev  *kfd;
> >+/* last time we received an hpd signal */
> >+unsigned long hpd_time;
> >+
> > struct mutexmn_lock;
> > DECLARE_HASHTABLE(mn_hash, 7);
> >  };
> >diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> >b/drivers/gpu/drm/radeon/radeon_connectors.c
> >index 5a2cafb..4ee9440 100644
> >--- a/drivers/gpu/drm/radeon/radeon_connectors.c
> >+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> >@@ -1228,19 +1228,33 @@ radeon_dvi_detect(struct drm_connector *connector, 
> >bool force)
> > const struct drm_encoder_helper_funcs *encoder_funcs;
> > int i, r;
> > enum drm_connector_status ret = connector_status_disconnected;
> >-bool dret = false, broken_edid = false;
> >+bool dret = false, broken_edid = false, hpd_unchanged;
> > r = pm_runtime_get_sync(connector->dev->dev);
> > if (r < 0)
> > return connector_status_disconnected;
> >-if (!force && radeon_check_hpd_status_unchanged(connector)) {
> >+hpd_unchanged = radeon_check_hpd_status_unchanged

Re: [PATCH] staging: panel: Fixed line over 80 characters long

[Sudip Mukherjee]

On Sat, Nov 21, 2015 at 09:26:32AM +0530, Anjali Menon wrote:
> Moved the comments to the next line to remove the warning
> detected by the checkpatch.pl.
> 
> WARNING: line over 80 characters
> 
> Signed-off-by: Anjali Menon 
> ---
>  drivers/staging/panel/panel.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/panel/panel.c b/drivers/staging/panel/panel.c
> index 79ac192..a810f6f 100644
> --- a/drivers/staging/panel/panel.c
> +++ b/drivers/staging/panel/panel.c
> @@ -947,7 +947,9 @@ static void lcd_clear_fast_s(void)
>   lcd_send_serial(0x5F);  /* R/W=W, RS=1 */
>   lcd_send_serial(' ' & 0x0F);
>   lcd_send_serial((' ' >> 4) & 0x0F);
> - usleep_range(40, 100);  /* the shortest data takes at least 40 
> us */
> + usleep_range(40, 100);
> + /* the shortest data takes at least 40 us */
> + usleep_range(40, 100);

You introduced one new usleep_range(40, 100).

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

Re: [PATCH] ASoC: pxa: remove incorrect do_div() call

[Arnd Bergmann]

On Monday 23 November 2015 16:10:49 zhangfei wrote:
> On 11/20/2015 05:32 PM, Arnd Bergmann wrote:
> > diff --git a/sound/soc/pxa/brownstone.c b/sound/soc/pxa/brownstone.c
> > index 6147e86e9b0f..416ea646c3b1 100644
> > --- a/sound/soc/pxa/brownstone.c
> > +++ b/sound/soc/pxa/brownstone.c
> > @@ -63,8 +63,7 @@ static int brownstone_wm8994_hw_params(struct 
> > snd_pcm_substream *substream,
> >   sysclk= params_rate(params) * 512;
> >   sspa_mclk = params_rate(params) * 64;
> >   }
> > - sspa_div = freq_out;
> > - do_div(sspa_div, sspa_mclk);
> > + sspa_div = freq_out / sspa_mclk;
> >
> >   snd_soc_dai_set_sysclk(cpu_dai, MMP_SSPA_CLK_AUDIO, freq_out, 0);
> >   snd_soc_dai_set_pll(cpu_dai, MMP_SYSCLK, 0, freq_out, sysclk);
> >
> 
> Thanks Arnd.
> 
> Looks sspa_div is not used at all.
> So we can remove sspa_div as well as do_div.
> 
> What do you think.

Good idea. I see that Mark has already applied the original patch, and with
my new version, gcc should be smart enough to completely optimize out the
division and the unused variable. This means the effect of the patch
is very small, but if Mark wants it, he can apply the below.

Arnd

8<---
Subject: ASoC: remove unused variable

As pointed out by Zhangfei Gao, the sspa_div variable in
brownstone_wm8994_hw_params() is completely unused, so as a cleanup
following a prior patch, this removes both the variable and the division.

Signed-off-by: Arnd Bergmann 

diff --git a/sound/soc/pxa/brownstone.c b/sound/soc/pxa/brownstone.c
index 416ea646c3b1..ec522e94b0e2 100644
--- a/sound/soc/pxa/brownstone.c
+++ b/sound/soc/pxa/brownstone.c
@@ -52,7 +52,6 @@ static int brownstone_wm8994_hw_params(struct 
snd_pcm_substream *substream,
struct snd_soc_dai *codec_dai = rtd->codec_dai;
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
int freq_out, sspa_mclk, sysclk;
-   int sspa_div;
 
if (params_rate(params) > 11025) {
freq_out  = params_rate(params) * 512;
@@ -63,7 +62,6 @@ static int brownstone_wm8994_hw_params(struct 
snd_pcm_substream *substream,
sysclk= params_rate(params) * 512;
sspa_mclk = params_rate(params) * 64;
}
-   sspa_div = freq_out / sspa_mclk;
 
snd_soc_dai_set_sysclk(cpu_dai, MMP_SSPA_CLK_AUDIO, freq_out, 0);
snd_soc_dai_set_pll(cpu_dai, MMP_SYSCLK, 0, freq_out, sysclk);

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

[PATCH v7 1/4] usb: gadget: bind UDC by name passed via usb_gadget_driver structure

[Marek Szyprowski]

From: Ruslan Bilovol 

Introduce new 'udc_name' member to usb_gadget_driver structure.
The 'udc_name' is a name of UDC that usb_gadget_driver should
be bound to. If udc_name is NULL, it will be bound to any
available UDC.

Tested-by: Maxime Ripard 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Marek Szyprowski 
Tested-by: Peter Chen 
---
 drivers/usb/gadget/udc/udc-core.c | 24 +++-
 include/linux/usb/gadget.h|  4 
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index f660afb..429d64e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -549,21 +549,35 @@ EXPORT_SYMBOL_GPL(usb_udc_attach_driver);
 int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
 {
struct usb_udc  *udc = NULL;
-   int ret;
+   int ret = -ENODEV;
 
if (!driver || !driver->bind || !driver->setup)
return -EINVAL;
 
mutex_lock(&udc_lock);
-   list_for_each_entry(udc, &udc_list, list) {
-   /* For now we take the first one */
-   if (!udc->driver)
+   if (driver->udc_name) {
+   list_for_each_entry(udc, &udc_list, list) {
+   ret = strcmp(driver->udc_name, dev_name(&udc->dev));
+   if (!ret)
+   break;
+   }
+   if (ret)
+   ret = -ENODEV;
+   else if (udc->driver)
+   ret = -EBUSY;
+   else
goto found;
+   } else {
+   list_for_each_entry(udc, &udc_list, list) {
+   /* For now we take the first one */
+   if (!udc->driver)
+   goto found;
+   }
}
 
pr_debug("couldn't find an available UDC\n");
mutex_unlock(&udc_lock);
-   return -ENODEV;
+   return ret;
 found:
ret = udc_bind_to_driver(udc, driver);
mutex_unlock(&udc_lock);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 3d583a1..63963c2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1012,6 +1012,8 @@ static inline int usb_gadget_activate(struct usb_gadget 
*gadget)
  * @reset: Invoked on USB bus reset. It is mandatory for all gadget drivers
  * and should be called in_interrupt.
  * @driver: Driver model state for this driver.
+ * @udc_name: A name of UDC this driver should be bound to. If udc_name is 
NULL,
+ * this driver will be bound to any available UDC.
  *
  * Devices are disabled till a gadget driver successfully bind()s, which
  * means the driver will handle setup() requests needed to enumerate (and
@@ -1072,6 +1074,8 @@ struct usb_gadget_driver {
 
/* FIXME support safe rmmod */
struct device_driverdriver;
+
+   char*udc_name;
 };
 
 
-- 
1.9.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] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

[Daniel Vetter]

On Sat, Nov 21, 2015 at 02:49:20PM +, Daniel Stone wrote:
> Hi,
> 
> On 21 November 2015 at 14:22, Christian König  
> wrote:
> > On 20.11.2015 16:52, cp...@redhat.com wrote:
> >> This is somewhat rare on most cards (depending on what angle you plug
> >> the DVI connector in), but on some cards it happens constantly. The
> >> Radeon R5 on the machine used for testing this patch for instance, runs
> >> into this issue just about every time I try to hotplug a DVI monitor and
> >> as a result hotplugging almost never works.
> >>
> >> Rescheduling the hotplug work for a second when we run into an HPD
> >> signal with a failing DDC probe usually gives enough time for the rest
> >> of the connector's pins to make contact, and fixes this issue.
> >>
> >> Signed-off-by: Stephen Chandler Paul 
> >
> >
> > Yeah, that's something I always wondered a about bit as well.
> >
> > Debouncing is something very common done in electronics, but as far as I
> > know the HPD pins don't necessary have an RC circuit so we might need to
> > handle this case in software here.
> >
> > A delay of something between 10-30ms between the last HPD interrupt and
> > further processing of the signal doesn't sounds like such a bad idea.
> >
> > Retrying on the other hand doesn't necessarily improve the situation cause
> > the delay introduced by this might not be enough.
> >
> > So I would rather vote for a fixed delay between an HPD interrupt and
> > actually starting to process anything.
> 
> Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. those
> on marginal power) which send you HPD storms as well. But DP relies on
> 'short HPD' pulses which can be as brief as 2ms. So attempting to
> totally debounce all HPD won't work.

In our experience in i915 DP hpd works perfectly on all machines. At least
we never had to add timeout hacks to settle hpd, storm handling code isn't
enabled for DP either and we always checked hpd status bits to decide
whether something is connected or not.

hdmi/dvi is the troublemaker which needs settling time and storm handling.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 2/4] usb: gadget: configfs: pass UDC name via usb_gadget_driver struct

[Marek Szyprowski]

From: Ruslan Bilovol 

Now when udc-core supports binding to specific UDC by passing
its name via 'udc_name' member of usb_gadget_driver struct,
switch to this generic approach.

Tested-by: Maxime Ripard 
Signed-off-by: Ruslan Bilovol 
[rebased and fixed checkpatch issues]
Signed-off-by: Marek Szyprowski 
Tested-by: Peter Chen 
---
 drivers/usb/gadget/configfs.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 163d305..590c449 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -56,7 +56,6 @@ struct gadget_info {
struct list_head string_list;
struct list_head available_func;
 
-   const char *udc_name;
struct usb_composite_driver composite;
struct usb_composite_dev cdev;
bool use_os_desc;
@@ -233,21 +232,23 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct 
config_item *item,
 
 static ssize_t gadget_dev_desc_UDC_show(struct config_item *item, char *page)
 {
-   return sprintf(page, "%s\n", to_gadget_info(item)->udc_name ?: "");
+   char *udc_name = to_gadget_info(item)->composite.gadget_driver.udc_name;
+
+   return sprintf(page, "%s\n", udc_name ?: "");
 }
 
 static int unregister_gadget(struct gadget_info *gi)
 {
int ret;
 
-   if (!gi->udc_name)
+   if (!gi->composite.gadget_driver.udc_name)
return -ENODEV;
 
ret = usb_gadget_unregister_driver(&gi->composite.gadget_driver);
if (ret)
return ret;
-   kfree(gi->udc_name);
-   gi->udc_name = NULL;
+   kfree(gi->composite.gadget_driver.udc_name);
+   gi->composite.gadget_driver.udc_name = NULL;
return 0;
 }
 
@@ -271,14 +272,16 @@ static ssize_t gadget_dev_desc_UDC_store(struct 
config_item *item,
if (ret)
goto err;
} else {
-   if (gi->udc_name) {
+   if (gi->composite.gadget_driver.udc_name) {
ret = -EBUSY;
goto err;
}
-   ret = usb_udc_attach_driver(name, &gi->composite.gadget_driver);
-   if (ret)
+   gi->composite.gadget_driver.udc_name = name;
+   ret = usb_gadget_probe_driver(&gi->composite.gadget_driver);
+   if (ret) {
+   gi->composite.gadget_driver.udc_name = NULL;
goto err;
-   gi->udc_name = name;
+   }
}
mutex_unlock(&gi->lock);
return len;
@@ -427,9 +430,9 @@ static int config_usb_cfg_unlink(
 * remove the function.
 */
mutex_lock(&gi->lock);
-   if (gi->udc_name)
+   if (gi->composite.gadget_driver.udc_name)
unregister_gadget(gi);
-   WARN_ON(gi->udc_name);
+   WARN_ON(gi->composite.gadget_driver.udc_name);
 
list_for_each_entry(f, &cfg->func_list, list) {
if (f->fi == fi) {
@@ -873,10 +876,10 @@ static int os_desc_unlink(struct config_item *os_desc_ci,
struct usb_composite_dev *cdev = &gi->cdev;
 
mutex_lock(&gi->lock);
-   if (gi->udc_name)
+   if (gi->composite.gadget_driver.udc_name)
unregister_gadget(gi);
cdev->os_desc_config = NULL;
-   WARN_ON(gi->udc_name);
+   WARN_ON(gi->composite.gadget_driver.udc_name);
mutex_unlock(&gi->lock);
return 0;
 }
-- 
1.9.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 v4 5/6] ARM: dts: sunxi: Add Allwinner H3 DTSI

[Maxime Ripard]

Hi,

On Sun, Nov 01, 2015 at 02:33:23PM +0100, Jens Kuske wrote:
> >> +   bus_gates: clk@01c20060 {
> >> +   #clock-cells = <1>;
> >> +   compatible = "allwinner,sun8i-h3-bus-gates-clk";
> >> +   reg = <0x01c20060 0x14>;
> >> +   clocks = <&ahb1>, <&ahb2>, <&apb1>, <&apb2>;
> >> +   clock-names = "ahb1", "ahb2", "apb1", "apb2";
> >> +   clock-indices = <5>, <6>, <8>,
> >> +   <9>, <10>, <13>,
> >> +   <14>, <17>, <18>,
> >> +   <19>, <20>,
> >> +   <21>, <23>,
> >> +   <24>, <25>,
> >> +   <26>, <27>,
> >> +   <28>, <29>,
> >> +   <30>, <31>, <32>,
> >> +   <35>, <36>, <37>,
> >> +   <40>, <41>, <43>,
> >> +   <44>, <52>, <53>,
> >> +   <54>, <64>,
> >> +   <65>, <69>, <72>,
> >> +   <76>, <77>, <78>,
> >> +   <96>, <97>, <98>,
> >> +   <112>, <113>,
> >> +   <114>, <115>, <116>,
> >> +   <128>, <135>;
> >> +   clock-output-names = "ahb1_ce", "ahb1_dma", 
> >> "ahb1_mmc0",
> >> +   "ahb1_mmc1", "ahb1_mmc2", 
> >> "ahb1_nand",
> >> +   "ahb1_sdram", "ahb2_gmac", 
> >> "ahb1_ts",
> >> +   "ahb1_hstimer", "ahb1_spi0",
> >> +   "ahb1_spi1", "ahb1_otg",
> >> +   "ahb1_otg_ehci0", "ahb1_ehic1",
> > 
> > ahb1_ehci1? Same for the following 3 lines.
> I'll fix them...
> > 
> >> +   "ahb1_ehic2", "ahb1_ehic3",
> >> +   "ahb1_otg_ohci0", "ahb2_ohic1",
> >> +   "ahb2_ohic2", "ahb2_ohic3", 
> >> "ahb1_ve",
> >> +   "ahb1_lcd0", "ahb1_lcd1", 
> >> "ahb1_deint",
> >> +   "ahb1_csi", "ahb1_tve", 
> >> "ahb1_hdmi",
> >> +   "ahb1_de", "ahb1_gpu", 
> >> "ahb1_msgbox",
> >> +   "ahb1_spinlock", "apb1_codec",
> >> +   "apb1_spdif", "apb1_pio", 
> >> "apb1_ths",
> >> +   "apb1_i2s0", "apb1_i2s1", 
> >> "apb1_i2s2",
> >> +   "apb2_i2c0", "apb2_i2c1", 
> >> "apb2_i2c2",
> >> +   "apb2_uart0", "apb2_uart1",
> >> +   "apb2_uart2", "apb2_uart3", 
> >> "apb2_scr",
> >> +   "ahb1_ephy", "ahb1_dbg";
> > 
> > If it weren't for the last 2 clocks, we could cleanly split out apb1 and 
> > apb2
> > gates. Having a separate AHB clock gate taking 2 addresses seems messy
> > as well. :(
> 
> Well, maybe we still should do that, if we split the resets too at least
> apb[12]  would line up again.
> 
> I don't know what to do with these bus things any more, all variants I
> sent had issues somewhere...

AFAIK, Arnd had some objections, but he never got back to us when we
explained how the hardware was laid out, so I don't know if they still
apply.

> >> +   };
> >> +
> >> +   mmc0_clk: clk@01c20088 {
> >> +   #clock-cells = <1>;
> >> +   compatible = "allwinner,sun4i-a10-mmc-clk";
> >> +   reg = <0x01c20088 0x4>;
> >> +   clocks = <&osc24M>, <&pll6 0>, <&pll8 0>;
> >> +   clock-output-names = "mmc0",
> >> +"mmc0_output",
> >> +"mmc0_sample";
> >> +   };
> >> +
> >> +   mmc1_clk: clk@01c2008c {
> >> +   #clock-cells = <1>;
> >> +   compatible = "allwinner,sun4i-a10-mmc-clk";
> >> +   reg = <0x01c2008c 0x4>;
> >> +   clocks = <&osc24M>, <&pll6 0>, <&pll8 0>;
> >> +   clock-output-names = "mmc1",
> >> +"mmc1_output",
> >> +"mmc1_sample";
> >> +   };
> >> +
> >> +   mmc2_clk: clk@01c20090 {
> >> +   #clock-cells = <1>;
> >> +   compatible = "allwinner

[PATCH v7 0/4] usb/gadget: independent registration of gadgets and gadget drivers

[Marek Szyprowski]

Hello,

This is a resurrection of the patches initially submitted by Ruslan
Bilovol in the following thread: https://lkml.org/lkml/2015/6/22/554

The changes since the original submission (v5) includes rebase onto
latest linux-next branch, simplification of the code requested by Alan
Stern and Felipe Balbi, removal of a patch, which deleted __init/__exit
attributes (this change has been already merged) and fixes of the
checkpatch issues.

This feature is urgently needed, because it is not longer possible to
use workaround to avoid deferred probe in UDC drivers due to
not-yet-probed i2c regulator drivers (for more information see
https://lkml.org/lkml/2015/10/30/374 ).

This patchset has been successfully tested on Odroid XU3 boards with
DWC3 UDC driver being deferred by missing regulator drivers.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Patch summary:

Ruslan Bilovol (4):
  usb: gadget: bind UDC by name passed via usb_gadget_driver structure
  usb: gadget: configfs: pass UDC name via usb_gadget_driver struct
  usb: gadget: udc-core: remove unused usb_udc_attach_driver()
  usb: gadget: udc-core: independent registration of gadgets and gadget
drivers

 drivers/usb/gadget/configfs.c | 29 +++---
 drivers/usb/gadget/udc/udc-core.c | 79 ++-
 include/linux/usb/gadget.h|  8 +++-
 3 files changed, 67 insertions(+), 49 deletions(-)

-- 
1.9.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 v7 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Marek Szyprowski]

From: Ruslan Bilovol 

Change behavior during registration of gadgets and
gadget drivers in udc-core. Instead of previous
approach when for successful probe of usb gadget driver
at least one usb gadget should be already registered
use another one where gadget drivers and gadgets
can be registered in udc-core independently.

Independent registration of gadgets and gadget drivers
is useful for built-in into kernel gadget and gadget
driver case - because it's possible that gadget is
really probed only on late_init stage (due to deferred
probe) whereas gadget driver's probe is silently failed
on module_init stage due to no any UDC added.

Also it is useful for modules case - now there is no
difference what module to insert first: gadget module
or gadget driver one.

Tested-by: Maxime Ripard 
Signed-off-by: Ruslan Bilovol 
[simplified code as requested by Alan Stern and Felipe Balbi,
 fixed checkpatch issues]
Signed-off-by: Marek Szyprowski 
Tested-by: Peter Chen 
---
 drivers/usb/gadget/udc/udc-core.c | 41 ++-
 include/linux/usb/gadget.h|  2 ++
 2 files changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index f76ebc8..fd73a3e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -51,8 +51,12 @@ struct usb_udc {
 
 static struct class *udc_class;
 static LIST_HEAD(udc_list);
+static LIST_HEAD(gadget_driver_pending_list);
 static DEFINE_MUTEX(udc_lock);
 
+static int udc_bind_to_driver(struct usb_udc *udc,
+   struct usb_gadget_driver *driver);
+
 /* - */
 
 #ifdef CONFIG_HAS_DMA
@@ -356,6 +360,7 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
void (*release)(struct device *dev))
 {
struct usb_udc  *udc;
+   struct usb_gadget_driver *driver;
int ret = -ENOMEM;
 
udc = kzalloc(sizeof(*udc), GFP_KERNEL);
@@ -403,6 +408,18 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
 
+   /* pick up one of pending gadget drivers */
+   list_for_each_entry(driver, &gadget_driver_pending_list, pending) {
+   if (!driver->udc_name || strcmp(driver->udc_name,
+   dev_name(&udc->dev)) == 0) {
+   ret = udc_bind_to_driver(udc, driver);
+   if (ret)
+   goto err4;
+   list_del(&driver->pending);
+   break;
+   }
+   }
+
mutex_unlock(&udc_lock);
 
return 0;
@@ -473,10 +490,14 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
 
mutex_lock(&udc_lock);
list_del(&udc->list);
-   mutex_unlock(&udc_lock);
 
-   if (udc->driver)
+   if (udc->driver) {
+   struct usb_gadget_driver *driver = udc->driver;
+
usb_gadget_remove_driver(udc);
+   list_add(&driver->pending, &gadget_driver_pending_list);
+   }
+   mutex_unlock(&udc_lock);
 
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
flush_work(&gadget->work);
@@ -535,11 +556,7 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
*driver)
if (!ret)
break;
}
-   if (ret)
-   ret = -ENODEV;
-   else if (udc->driver)
-   ret = -EBUSY;
-   else
+   if (!ret && !udc->driver)
goto found;
} else {
list_for_each_entry(udc, &udc_list, list) {
@@ -549,9 +566,11 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
*driver)
}
}
 
-   pr_debug("couldn't find an available UDC\n");
+   list_add_tail(&driver->pending, &gadget_driver_pending_list);
+   pr_info("udc-core: couldn't find an available UDC - added [%s] to list 
of pending drivers\n",
+   driver->function);
mutex_unlock(&udc_lock);
-   return ret;
+   return 0;
 found:
ret = udc_bind_to_driver(udc, driver);
mutex_unlock(&udc_lock);
@@ -577,6 +596,10 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver 
*driver)
break;
}
 
+   if (ret) {
+   list_del(&driver->pending);
+   ret = 0;
+   }
mutex_unlock(&udc_lock);
return ret;
 }
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index ce2188d..92467ee 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1014,6 +1014,7 @@ static inline int usb_gadget_activate(struct usb_gadget 
*gadget)
  * @driver: Driver model state for this 

Re: [PATCH v2 6/6] arm64: dts: berlin4ct: add pll and clock nodes

[Jisheng Zhang]

On Mon, 23 Nov 2015 09:30:42 +0100
Sebastian Hesselbarth wrote:

> On 23.11.2015 08:21, Jisheng Zhang wrote:
> > On Fri, 20 Nov 2015 22:06:59 +0100
> > Sebastian Hesselbarth wrote:  
> >> On 20.11.2015 09:42, Jisheng Zhang wrote:  
> >>> Add syspll, mempll, cpupll, gateclk and berlin-clk nodes.
> >>>
> >>> Signed-off-by: Jisheng Zhang 
> >>> ---  
> [...]
> >>> + syspll: syspll {
> >>> + compatible = "marvell,berlin-pll";
> >>> + reg = <0xea0200 0x14>, <0xea0710 4>;
> >>> + #clock-cells = <0>;
> >>> + clocks = <&osc>;
> >>> + bypass-shift = /bits/ 8 <0>;
> >>> + };
> >>> +
> >>> + gateclk: gateclk {
> >>> + compatible = "marvell,berlin4ct-gateclk";
> >>> + reg = <0xea0700 4>;
> >>> + #clock-cells = <1>;
> >>> + };
> >>> +
> >>> + clk: clk {
> >>> + compatible = "marvell,berlin4ct-clk";
> >>> + reg = <0xea0720 0x144>;  
> >>
> >> Looking at the reg ranges, I'd say that they are all clock related
> >> and pretty close to each other:
> >>
> >> gateclk: reg = <0xea0700 4>;
> >> bypass:  reg = <0xea0710 4>;
> >> clk: reg = <0xea0720 0x144>;  
> >
> > Although these ranges sit close, but we should represent HW structure as you
> > said.  
> 
> Then how do you argue that you have to share the gate clock register
> with every PLL? The answer is quite simple: You are not separating by
> HW either but existing SW API.

No, PLLs don't share register any more. You can find what all clock nodes will
look like in:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387322.html

> 
> If you would really want to just describe the HW, then you'd have to
> have a single node for _all_ clocks that get controlled by 0xea0700/0x4,
> feed some 32+ clocks into the node, and out again. Obviously, this
> isn't what we want, right?

I represented the HW by "kind", for example, gateclks, common-clks, pllclk.
And let common PLLs follow this rule as well:

one node for all common plls

reg <0x922000 0x14>, <0x940034 0x14>, <0xea0200 0x14>

> 
> So, the idea of berlin2 sysctrl nodes (and similar other SoCs) is: Some
> SoCs just dump some functions into a bunch of registers with no
> particular order. We'd never find a good representation for that in DT,
> so we don't bother to try but let the driver implementation deal with
> the mess. Using "simple-mfd" is a nice solution to scattered registers
> please have a look at it and come up with a cleaner separation for bg4
> clock.
> 
> > First of all, let me describe the clks/plls in BG4CT. BG4CT contains:
> >
> > two kinds of PLL: normal PLL and AVPLL. These PLLs are put with their users
> > together. For example: mempll pll registers <0xf7940034, 0x14> is put 
> > together
> > with mem controller registers. AVPLL control registers are put with AV 
> > devices.  
> 
> Why didn't you choose to have a memory-controller node that provides
> mempll clock then? I am open to having multiple nodes providing clocks
> but having a node for every clock in any subsystem is something I'll
> not even think about.

OK. As you said, "SoCs just dump some functions into a bunch of registers with
no particular order", BG4CT is now cleaner, all common-clks are put together,
gate-clks are put together, pllclks are put together, only the common PLLs
are dumped here and there. So how about representing the HW by "kind", one
node for common plls, one node for gateclks, one node for common clks and 
one node for pllclks?

pll: pll {
compatible = "marvell,berlin4ct-pll";
reg = <0x922000 0x14>, <0x940034 0x14>, <0xea0200 0x14>
#clock-cells = <0>;
clocks = <&osc>;
};

pllclk: pllclk {
compatible = "marvell,berlin4ct-pllclk";
reg = <0xea0710 4>
#clock-cells = <1>;
};

gateclk: gateclk {
compatible = "marvell,berlin4ct-gateclk";
reg = <0xea0700 4>;
#clock-cells = <1>;
};

clk: clk {
compatible = "marvell,berlin4ct-clk";
reg = <0xea0720 0x144>;
#clock-cells = <1>;
clocks = <&pllclk SYSPLLCLK>;
};

thanks

> 
> > You can also check mempll, cpupll and syspll ranges:
> >
> > cpupll: <0x922000 0x14>
> >
> > mempll: <0x940034 0x14>
> >
> > syspll: <0xea0200 0x14>
> >
> >
> > We have three normal PLLS: cpupll, mempll and syspll. All these three PLLs 
> > use
> > 25MHZ osc as clocksource. These plls can be bypassed. when syspll is 
> > bypassed
> > the 25MHZ osc is directly output to syspllclk. When mempll/cpupll is 
> > bypassed,
> > its corresponding f

[PATCH v7 3/4] usb: gadget: udc-core: remove unused usb_udc_attach_driver()

[Marek Szyprowski]

From: Ruslan Bilovol 

Now when last user of usb_udc_attach_driver() is switched
to passing UDC name via usb_gadget_driver struct, it's safe
to remove this function

Tested-by: Maxime Ripard 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Marek Szyprowski 
Tested-by: Peter Chen 
---
 drivers/usb/gadget/udc/udc-core.c | 26 --
 include/linux/usb/gadget.h|  2 --
 2 files changed, 28 deletions(-)

diff --git a/drivers/usb/gadget/udc/udc-core.c 
b/drivers/usb/gadget/udc/udc-core.c
index 429d64e..f76ebc8 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -520,32 +520,6 @@ err1:
return ret;
 }
 
-int usb_udc_attach_driver(const char *name, struct usb_gadget_driver *driver)
-{
-   struct usb_udc *udc = NULL;
-   int ret = -ENODEV;
-
-   mutex_lock(&udc_lock);
-   list_for_each_entry(udc, &udc_list, list) {
-   ret = strcmp(name, dev_name(&udc->dev));
-   if (!ret)
-   break;
-   }
-   if (ret) {
-   ret = -ENODEV;
-   goto out;
-   }
-   if (udc->driver) {
-   ret = -EBUSY;
-   goto out;
-   }
-   ret = udc_bind_to_driver(udc, driver);
-out:
-   mutex_unlock(&udc_lock);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(usb_udc_attach_driver);
-
 int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
 {
struct usb_udc  *udc = NULL;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 63963c2..ce2188d 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1121,8 +1121,6 @@ extern int usb_add_gadget_udc_release(struct device 
*parent,
struct usb_gadget *gadget, void (*release)(struct device *dev));
 extern int usb_add_gadget_udc(struct device *parent, struct usb_gadget 
*gadget);
 extern void usb_del_gadget_udc(struct usb_gadget *gadget);
-extern int usb_udc_attach_driver(const char *name,
-   struct usb_gadget_driver *driver);
 
 /*-*/
 
-- 
1.9.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 v1 3/7] test_hexdump: go through all possible lengths of buffer

[Rasmus Villemoes]

On Fri, Nov 20 2015, Andy Shevchenko  wrote:

> On Thu, 2015-11-19 at 11:07 +0100, Rasmus Villemoes wrote:
>> 
>> 
>> Why keep the variable l when it is just a synonym for the new
>> parameter buflen? It is quite confusing that you change some but not
>> all occurrences of l to buflen. If you want to make the diff minimal
>> but still have a descriptive parameter name, just keep the 'size_t l
>> =
>> buflen;' assignment and don't otherwise refer to buflen. But I think
>> it's better to eliminate 'l' and just change everything to
>> buflen. Don't mix the two approaches, though.
>
> Okay, I got it for the future, though the series is already in linux-
> next, so do we really need to re-hack half of it because of that?

Stuff in -next isn't set in stone. I'm pretty sure Andrew can replace
one set of patches with another.

Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lightnvm: free allocated memory when gennvm register fails

[Wenwei Tao]

This is okay with me.

2015-11-23 16:47 GMT+08:00 Matias Bjørling :
> On 11/23/2015 09:29 AM, Wenwei Tao wrote:
>>
>> free allocated nvm block and gennvm lun structures when
>> gennvm register fails, otherwise it will cause memory leak.
>>
>> Signed-off-by: Wenwei Tao 
>> ---
>>   drivers/lightnvm/gennvm.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c
>> index ae1fb2b..03fc7a5 100644
>> --- a/drivers/lightnvm/gennvm.c
>> +++ b/drivers/lightnvm/gennvm.c
>> @@ -211,12 +211,15 @@ static int gennvm_register(struct nvm_dev *dev)
>> ret = gennvm_blocks_init(dev, gn);
>> if (ret) {
>> pr_err("gennvm: could not initialize blocks\n");
>> +   gennvm_blocks_free(dev);
>> +   gennvm_luns_free(dev);
>> goto err;
>> }
>>
>> return 1;
>>   err:
>> kfree(gn);
>> +   dev->mp = NULL;
>> return ret;
>>   }
>>
>>
> Thanks Tao, would it be okay with you if I apply the patch like this:
>
> diff --git i/drivers/lightnvm/gennvm.c w/drivers/lightnvm/gennvm.c
> index e20e74e..3969a98 100644
> --- i/drivers/lightnvm/gennvm.c
> +++ w/drivers/lightnvm/gennvm.c
> @@ -207,6 +207,14 @@ static int gennvm_blocks_init(struct nvm_dev *dev,
> struct gen_nvm *gn)
> return 0;
>  }
>
> +static void gennvm_free(struct nvm_dev *dev)
> +{
> +   gennvm_blocks_free(dev);
> +   gennvm_luns_free(dev);
> +   kfree(dev->mp);
> +   dev->mp = NULL;
> +}
> +
>  static int gennvm_register(struct nvm_dev *dev)
>  {
> struct gen_nvm *gn;
> @@ -234,16 +242,13 @@ static int gennvm_register(struct nvm_dev *dev)
>
> return 1;
>  err:
> -   kfree(gn);
> +   gennvm_free(dev);
> return ret;
>  }
>
>  static void gennvm_unregister(struct nvm_dev *dev)
>  {
> -   gennvm_blocks_free(dev);
> -   gennvm_luns_free(dev);
> -   kfree(dev->mp);
> -   dev->mp = NULL;
> +   gennvm_free(dev);
>  }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lightnvm: free allocated memory when gennvm register fails

[Matias Bjørling]

On 11/23/2015 10:00 AM, Wenwei Tao wrote:

This is okay with me.


Great, I'll go ahead and apply it.



2015-11-23 16:47 GMT+08:00 Matias Bjørling :

On 11/23/2015 09:29 AM, Wenwei Tao wrote:


free allocated nvm block and gennvm lun structures when
gennvm register fails, otherwise it will cause memory leak.

Signed-off-by: Wenwei Tao 
---
   drivers/lightnvm/gennvm.c | 3 +++
   1 file changed, 3 insertions(+)

diff --git a/drivers/lightnvm/gennvm.c b/drivers/lightnvm/gennvm.c
index ae1fb2b..03fc7a5 100644
--- a/drivers/lightnvm/gennvm.c
+++ b/drivers/lightnvm/gennvm.c
@@ -211,12 +211,15 @@ static int gennvm_register(struct nvm_dev *dev)
 ret = gennvm_blocks_init(dev, gn);
 if (ret) {
 pr_err("gennvm: could not initialize blocks\n");
+   gennvm_blocks_free(dev);
+   gennvm_luns_free(dev);
 goto err;
 }

 return 1;
   err:
 kfree(gn);
+   dev->mp = NULL;
 return ret;
   }



Thanks Tao, would it be okay with you if I apply the patch like this:

diff --git i/drivers/lightnvm/gennvm.c w/drivers/lightnvm/gennvm.c
index e20e74e..3969a98 100644
--- i/drivers/lightnvm/gennvm.c
+++ w/drivers/lightnvm/gennvm.c
@@ -207,6 +207,14 @@ static int gennvm_blocks_init(struct nvm_dev *dev,
struct gen_nvm *gn)
 return 0;
  }

+static void gennvm_free(struct nvm_dev *dev)
+{
+   gennvm_blocks_free(dev);
+   gennvm_luns_free(dev);
+   kfree(dev->mp);
+   dev->mp = NULL;
+}
+
  static int gennvm_register(struct nvm_dev *dev)
  {
 struct gen_nvm *gn;
@@ -234,16 +242,13 @@ static int gennvm_register(struct nvm_dev *dev)

 return 1;
  err:
-   kfree(gn);
+   gennvm_free(dev);
 return ret;
  }

  static void gennvm_unregister(struct nvm_dev *dev)
  {
-   gennvm_blocks_free(dev);
-   gennvm_luns_free(dev);
-   kfree(dev->mp);
-   dev->mp = NULL;
+   gennvm_free(dev);
  }




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

Re: [PATCH v2] drm/mm: rewrite drm_mm_for_each_hole

[Daniel Vetter]

On Sat, Nov 21, 2015 at 10:04:04PM +0800, Geliang Tang wrote:
> When backwards is 0, __drm_mm_for_each_hole is same as
> drm_mm_for_each_hole. So I rewrite drm_mm_for_each_hole
> by using __drm_mm_for_each_hole.
> 
> Signed-off-by: Geliang Tang 

Applied to drm-misc, thanks.
-Daniel

> ---
> Changes in v2:
>  - fix make htmldocs warning
> ---
>  include/drm/drm_mm.h | 23 +--
>  1 file changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
> index 0de6290..a58cc6c 100644
> --- a/include/drm/drm_mm.h
> +++ b/include/drm/drm_mm.h
> @@ -180,6 +180,14 @@ static inline u64 drm_mm_hole_node_end(struct 
> drm_mm_node *hole_node)
>   &(mm)->head_node.node_list, \
>   node_list)
>  
> +#define __drm_mm_for_each_hole(entry, mm, hole_start, hole_end, backwards) \
> + for (entry = list_entry((backwards) ? (mm)->hole_stack.prev : 
> (mm)->hole_stack.next, struct drm_mm_node, hole_stack); \
> +  &entry->hole_stack != &(mm)->hole_stack ? \
> +  hole_start = drm_mm_hole_node_start(entry), \
> +  hole_end = drm_mm_hole_node_end(entry), \
> +  1 : 0; \
> +  entry = list_entry((backwards) ? entry->hole_stack.prev : 
> entry->hole_stack.next, struct drm_mm_node, hole_stack))
> +
>  /**
>   * drm_mm_for_each_hole - iterator to walk over all holes
>   * @entry: drm_mm_node used internally to track progress
> @@ -200,20 +208,7 @@ static inline u64 drm_mm_hole_node_end(struct 
> drm_mm_node *hole_node)
>   * going backwards.
>   */
>  #define drm_mm_for_each_hole(entry, mm, hole_start, hole_end) \
> - for (entry = list_entry((mm)->hole_stack.next, struct drm_mm_node, 
> hole_stack); \
> -  &entry->hole_stack != &(mm)->hole_stack ? \
> -  hole_start = drm_mm_hole_node_start(entry), \
> -  hole_end = drm_mm_hole_node_end(entry), \
> -  1 : 0; \
> -  entry = list_entry(entry->hole_stack.next, struct drm_mm_node, 
> hole_stack))
> -
> -#define __drm_mm_for_each_hole(entry, mm, hole_start, hole_end, backwards) \
> - for (entry = list_entry((backwards) ? (mm)->hole_stack.prev : 
> (mm)->hole_stack.next, struct drm_mm_node, hole_stack); \
> -  &entry->hole_stack != &(mm)->hole_stack ? \
> -  hole_start = drm_mm_hole_node_start(entry), \
> -  hole_end = drm_mm_hole_node_end(entry), \
> -  1 : 0; \
> -  entry = list_entry((backwards) ? entry->hole_stack.prev : 
> entry->hole_stack.next, struct drm_mm_node, hole_stack))
> + __drm_mm_for_each_hole(entry, mm, hole_start, hole_end, 0)
>  
>  /*
>   * Basic range manager support (drm_mm.c)
> -- 
> 2.5.0
> 
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] arm64: dts: Add msm8996 SoC and MTP board support

[Rajendra Nayak]

On 11/18/2015 06:42 AM, Stephen Boyd wrote:
> Add initial device tree support for the Qualcomm MSM8996 SoC and
> MTP8996 evaluation board.
> 
> Signed-off-by: Stephen Boyd 
> ---
[]...

> +
> + spmi_bus: qcom,spmi@400f000 {
> + compatible = "qcom,spmi-pmic-arb";
> + reg = <0x400f000 0x1000>,
> +   <0x440 0x80>,
> +   <0x4c0 0x80>,
> +   <0x580 0x20>,
> +   <0x400a000 0x002100>;
> + reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
> + interrupt-names = "periph_irq";
> + interrupts = ;
> + qcom,ee = <0>;
> + qcom,channel = <0>;
> + #address-cells = <2>;
> + #size-cells = <0>;
> + interrupt-controller;
> + #interrupt-cells = <4>;
> + };
> +
> + mmcc: clock-controller@8c {
> + compatible = "qcom,mmcc-msm8996";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + reg = <0x8c 0xc>;

I think the size here should be 0x4 and not 0xc

regards,
Rajendra

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: Re: [PATCH 6/6] PM / devfreq: Set the min_freq and max_freq of devfreq device

[MyungJoo Ham]

> On Mon, Nov 23, 2015 at 4:21 PM, MyungJoo Ham  
> wrote:
> > []
> >> >
> >> > The value 0 is used for min/max_freq to declare
> >> > that min/max_freq is deactivated. Therefore, it is not
> >> > required to do so; they are not intended to show the hardware
> >> > configuration as well.
> >>
> >> This case consider the devfreq device using OPP because 
> >> devfreq_set_freq_table()
> >> get the number of OPP entry in OPP list before setting the 
> >> min_freq/max_freq.
> >> If the devfreq device don't use the OPP entry, devfreq_set_freq_table()
> >> will return without any operation.
> >>
> >> IMHO, when devfreq device uses the OPP table including the frequency,
> >> min_freq/max_freq should show the correct value as CPUFREQ framework.
> >>
> >
> > The side effect of this patch shows up when opp_disable() and opp_enable()
> > are used.
> 
> Ah. You're right.
> I was not considering the the case of using opp_disable() and opp_enable().
> I'll consider it again including the usage case of opp_diable/opp_enable.
> 

Even without the side effect, what would be the meaning of initializing
min/max-freq to the device min/max capabilities when the users may
override it with arbitrary lower/higher values?


Cheers,
MyungJoo

ps. you will be one or two floors away from my office next week. :)
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [linux-sunxi] [PATCH] spi: dts: sun4i: Add support for inter-word wait cycles using the SPI Wait Clock Register

[Marcus Weseloh]

2015-11-22 20:45 GMT+01:00 Maxime Ripard :
>> Julien, Rob: thanks for your comments! Ok, I will make the following changes:
>>
>> - remove "sun4i,spi-wdelay" from the sun4i binding and add the
>> property to the spi-bus.txt binding instead
>> - remove the comment about the additional 3 cycles from the documentation
>> - modfy the spi-sun4i driver to take care of the minimum 3 cycle period
>>
>> Does that sound right?
>>
>> And maybe I could also use a more descriptive name for the property,
>> maybe "spi-word-wait-cycles"?
>
> I don't think it should be in a clock-rate dependant unit. Using micro
> or nano-seconds would be more appropriate I guess.

Thanks Maxime, using a time based value instead of cycles sounds like
a much better approach.

However... I'm starting to think that the proposed inter-word wait
time DT property is just an ugly workaround. Let me explain my
use-case:

I'm developing a driver for a sensor that requires a minimum wait time
between words. The wait time depends on the mode the sensor is set to:
37.5us in slow mode, 12.5us in fast mode. I initially used spidev to
test the sensor from userspace. And for that use case, the
"spi-wdelay" property that I proposed works well. But now I am writing
the proper protocol driver and suddenly the explicit wait time setting
seems just wrong. Ideally, the protocol driver would just expose a DT
property that allows to choose between "slow" and "fast" mode.

I think that the correct approach would be to extend the SPI
controller API to allow protocol drivers to set an inter-word delay.
That would keep the magic numbers inside my protocol driver and out of
the devicetree. And an additional ioctl call could set that inter-word
delay from spidev, allowing userspace to set this value as well if
needed.

Mark: would you be open to such a change to the SPI controller API?

I could use the already available spi_transfer.delay_usecs for this,
but I would require that I wrap each word in a single transfer, which
adds significant processing overhead to the communication with the
sensor.

Cheers,

Marcus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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-sunxi] [PATCH v2 2/5] clk: sunxi: Add driver for the H3 THS clock

[LABBE Corentin]

On Mon, Nov 23, 2015 at 09:02:49AM +0100, Josef Gajdusek wrote:
> This patch adds a driver for the THS clock which is present on the
> Allwinner H3.
> 
> Signed-off-by: Josef Gajdusek 
> ---

Hello
Just a minor comment below.

> +static void __init sun8i_h3_ths_clk_setup(struct device_node *node)
> +{
> + struct clk *clk;
> + struct clk_gate *gate;
> + struct clk_divider *div;
> + const char *parent;
> + const char *clk_name = node->name;
> + void __iomem *reg;
> + int err;
> +
> + reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> +
> + if (IS_ERR(reg))
> + return;
> +
> + gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> + if (!gate)
> + goto err_unmap;
> +
> + div = kzalloc(sizeof(*gate), GFP_KERNEL);
copy/paste error, you mean sizeof(*div) ?

> + if (!div)
> + goto err_gate_free;
> +
> + of_property_read_string(node, "clock-output-names", &clk_name);

Regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: rockchip: dmc: support rk3399 dmc clock driver

[hl]

Hi Heiko,

On 22/11/15 02:30, Heiko Stuebner wrote:

Hi Lin,

Am Freitag, 20. November 2015, 09:37:15 schrieb hl:

On 20/11/15 05:47, Heiko Stuebner wrote:

Hi Lin,

Am Donnerstag, 19. November 2015, 18:21:10 schrieb Lin Huang:

support rk3399 dmc clock driver. Note, ddr set rate function will
use dcf controller which run in ATF, it need to fishish it when rk3399
arm trust firmware ready.

this unfinalized state is slightly unfortunate and I think this code will
need to wait until CRU and DDRC specs are available.

Because this is clearly part of the CRU (labeled CRU_CLKSEL6_CON etc)
so shouldn't be a separate driver at all and also what your driver currently
only does can still simply be described in the regular scheme as part of
a full clock driver like

PNAME(mux_ddrc_p) = { "pll_dpll", "pll_gpll", "pll_alpll", "pll_abpll" };
COMPOSITE_NOGATE(0, "ddrc", mux_ddrc_p, 0,
RK3399_CLKSEL_CON(6), 4, 2, MFLAGS, 0, 
3,
DFLAGS | CLK_DIVIDER_POWER_OF_TWO),

So the code needs to actually demonstrate why a separate clock type is
really necessary.

I do understand that we will probably need a special way to talk to this
dcf controller but seeing how this interaction will work is really a
prequisite to finding a correct solution.

  if we can use common clock driver, i can put the dfi controller as
a  independent driver
  into devfreq,  this is the best way. But how do we separate the ddr
clk_set_rate() ,
  so we can manipulate dcf controller(actually, we use SMC handle dcf
controller in arm trust firmware ),
  i check clock driver code, it seem there is not way to do that for now.

the core problem I have right now is, that I don't understand how the
interaction with the dfi controller works at all :-) .

One thing that might work, is that your dfi-driver takes the ddrc-clock
from the clock controller and then registers a clock notifier to get
notified before and after the clock-rate changes. But that depends as
stated above on how the dfi-controller needs to be handled.

For example the current armclk-handling uses a clock notifier around the
actual rate change ... so you could use that as inspiration.
Thank you for your inspiration. I think i can handle ddrc clk like 
the armclk.
About the dfi, it will monitor ddr utilization, according this 
result to do
ddr frequency scaling. I think i can implement a dfi drvier, and 
register it to devfreq,
then call the dmc_set_rate fucntion in the dfi drvier, meanwhile i 
will implement a ddrc clk driver
like the armclk, implement set rate funciton, and call the 
dcf(implement in ATF) in this function.



Heiko






--
Lin Huang


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Deadlock between bind and splice

[Hannes Frederic Sowa]

On Mon, Nov 23, 2015, at 09:32, Dmitry Vyukov wrote:
> On Tue, Nov 10, 2015 at 3:59 AM, Al Viro  wrote:
> > On Tue, Nov 10, 2015 at 02:38:54AM +, Al Viro wrote:
> >> On Fri, Nov 06, 2015 at 07:42:15AM -0800, Eric Dumazet wrote:
> >>
> >> > Thank you for this report.
> >> >
> >> > pipe is part of fs, not net ;)
> >>
> >> AF_UNIX bind() vs. socketpair() interplay, OTOH...
> >
> > FWIW, BSD folks unlock the socket for the duration of mknod - mark it as
> > "somebody's trying to bind it" to avoid the fun with racing double bind(),
> > but that's about it.  Tempting, to be honest...
> >
> > BTW, why does unix_autobind() do allocation under ->readlock?  The 
> > allocation
> > will be normally used - that if (u->addr) return; part is just dealing with
> > an unlikely race, as far as I can see...
> 
> 
> Hello,
> 
> This is still happening periodically for me. Is there a proposed fix?
> I could test it.

No, we currently have no fix for that report. :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: Atmel: ClassD: add GCK's parent clock in DT binding

[Songjun Wu]

Set GCK's parent as audio clock.

Signed-off-by: Songjun Wu 
---

 .../devicetree/bindings/sound/atmel-classd.txt |6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/atmel-classd.txt 
b/Documentation/devicetree/bindings/sound/atmel-classd.txt
index 0018451..549e701 100644
--- a/Documentation/devicetree/bindings/sound/atmel-classd.txt
+++ b/Documentation/devicetree/bindings/sound/atmel-classd.txt
@@ -16,6 +16,10 @@ Required properties:
Required elements: "pclk", "gclk" and "aclk".
 - clocks
Please refer to clock-bindings.txt.
+- assigned-clocks
+   Should be <&classd_gclk>.
+- assigned-clock-parents
+   Should be <&audio_pll_pmc>.
 
 Optional properties:
 - pinctrl-names, pinctrl-0
@@ -43,6 +47,8 @@ classd: classd@fc048000 {
dma-names = "tx";
clocks = <&classd_clk>, <&classd_gclk>, <&audio_pll_pmc>;
clock-names = "pclk", "gclk", "aclk";
+   assigned-clocks = <&classd_gclk>;
+   assigned-clock-parents = <&audio_pll_pmc>;
 
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_classd_default>;
-- 
1.7.9.5

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

Re: [PATCH 1/2] clk: rockchip: dmc: support rk3399 dmc clock driver

[hl]

Hi MyungJoo,

On 23/11/15 16:09, MyungJoo Ham wrote:

+static unsigned long rk3399_dmcclk_recalc_rate(struct clk_hw *hw,
+  unsigned long parent_rate)
+{
+   struct rk3399_dmcclk *dmc = to_rk3399_dmcclk(&hw);
+   u32 val;
+
+   /*
+* Get parent rate since it changed in this clks set_rate op. The parent
+* rate passed into this function is cached before set_rate is called in
+* the common clk code, so we have to get it here.
+*/
+   parent_rate = clk_get_rate(clk_get_parent(hw->clk));
+
+   val = readl(dmc->cru + CRU_CLKSEL6_CON);
+   val = (val >> CLK_DDRC_DIV_CON_SHIFT) & CLK_DDRC_DIV_CON_MASK;
+
+   return parent_rate / (val + 1);
+}
+
+/*
+ * TODO: set ddr frequcney in dcf which run in ATF
+ */
+static int rk3399_dmcclk_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   return 0;
+}

Is it correct that you didn't fill this up because your
Trustzone driver (SMC) is not ready yet?

Yep, the SMC is not ready yet.


Then, why don't you fill that function assuming that TrustZone is not activated
and add SMC call functions with if or #if after its TrustZone driver is ready?

Or does your SoC mandate the usage ot TrustZone, restricting the usage
of CRU_CLKSEL6_CON write? (I don't see why SoC vendors will do this..)


I'll be ready to merge the RK3399 devfreq driver if you
fill this up (assuming that TZ is not enabled) or
add TZ driver and SMC calls.
Thank you for your reply,  it is good idea use if or #if to 
distinguish the TrustZone whether ready,
i will handle it in next version. I may follow Heiko advice to do 
some modify in dmc clock and rk3399 devfreq driver,

I will upload new version when it's ready.


Cheers,
MyungJoo
ps. according to rk339_dmcclk_recalc_rate(), filling rk339_dmcclk_set_rate
assuming that TZ is not enabled seems trivial.


--
Lin Huang


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Gta04-owner] [PATCH v2 0/3] Fixes for twl4030 charger

[H. Nikolaus Schaller]

ping.

Am 13.11.2015 um 11:28 schrieb H. Nikolaus Schaller :

> ping.
> 
> Am 02.11.2015 um 12:27 schrieb H. Nikolaus Schaller :
> 
>> Changes V2:
>> * worked in comments by Nishanth Menon 
>> * added another patch which solves a probing/boot stall problem (irq 
>> allocation vs. -EPROBE_DEFER)
>> 
>> V1:
>> 4.3-rc1 introduced a new charger driver for the twl4030.
>> 
>> While making it operable and testing on GTA04 and OpenPandora
>> we have found some issues.
>> 
>> 
>> H. Nikolaus Schaller (3):
>> drivers:power:twl4030-charger: fix problem with EPROBE_DEFER
>> drivers:power:twl4030-charger: don't return after allocating irq
>> drivers:power:twl4030-charger: don't check if battery is present
>> 
>> drivers/power/twl4030_charger.c | 39 ++-
>> 1 file changed, 18 insertions(+), 21 deletions(-)
>> 
>> -- 
>> 2.5.1
>> 
> 
> ___
> Gta04-owner mailing list
> gta04-ow...@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 5/7] test_hexdump: check all bytes in real buffer

[Rasmus Villemoes]

On Fri, Nov 20 2015, Andy Shevchenko  wrote:

> On Thu, 2015-11-19 at 11:11 +0100, Rasmus Villemoes wrote:
>> 
>> First of all, ' ' is one of the characters which hexdump is certainly
>> supposed to spit out, so I think it's better to use some other
>> character for prefilling. Otherwise we wouldn't be able to detect a
>> stray write of a space which wasn't properly guarded by a size
>> check. I'd suggest '\xff' or any other non-ascii
>
> Okay, I may change the ' ' to something, but somehow printable. See
> also below.
>
>> > -  a = r == e && buf[l - 1] == '\0' && buf[l
>> > - 2] == ' ';
>> > -  else
>> > -  a = r == e && buf[50] == '\0' && buf[49]
>> > == '.';
>> > +  memset(test, ' ', sizeof(test));
>> > +  test[sizeof(buf) - 1] = '\0';
>> > +
>> > +  a = r == e && !memchr_inv(buf, ' ', sizeof(buf));
>> 
>> test and buf happen to have the same size, but
>> "test[sizeof(buf) - 1] = '\0'" is rather odd. But you don't even seem
>> to use test in this branch?
>
> Here I feel the test buffer just to print below if any error happens
> when buflen == 0.
>
> That's why I would like to have a somehow printable character.

Oh, but that's wrong! That is, printing the filled test buffer does not
actually show what was "expected", whether you were filling with spaces,
$ or \xff. I really can't think of a situation where you'd want to print
the supposedly unused part of the buffer, so the character used for
filling shouldn't matter.

In any case, the most important thing is to stay away from [ a-f0-9]
which hexdump is certainly expected to produce - the reason I suggested
a non-ascii character was because hexdump might produce any printable
ascii character in the ascii part (but I suppose one could use e.g. '#'
which isn't among the characters we feed it).

>> >    } else {
>> > -  a = r == e && buf[e] == '\0';
>> > +  int f = min_t(int, e + 1, buflen);
>> > +
>> > +  test_hexdump_prepare_test(len, rs, gs, test,
>> > sizeof(test), ascii);
>> > +  test[f - 1] = '\0';
>> > +
>> > +  a = r == e && !memchr_inv(buf + f, ' ',
>> > sizeof(buf) - f) && !strcmp(buf, test);
>> >    }
>> 
>> There's also a bit of duplication in the !buflen and buflen
>> branches. Why not pull the computation of f (the number of expected
>> bytes written) outside and do
>
> See above. buflen == 0 is a special case where buffer shouldn't be
> touched at all.

No, buflen==0 is not that special. We expect hexdump to touch exactly
the first buflen bytes (or only e+1, whichever is smaller), and the
remaining bytes should be untouched. A memcmp handles the first part, a
memchr_inv the second.

Rasmus



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] leds/powernv : removing NULL check

[Saurabh Sengar]

no need to explicitly check for pointer to be null,
of_prop_next_string anyways return NULL, if passed pointer is NULL
and hence loop will continue

Signed-off-by: Saurabh Sengar 
---
 drivers/leds/leds-powernv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index 1e75e1f..bc2d76e 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -256,8 +256,6 @@ static int powernv_led_classdev(struct platform_device 
*pdev,
 
for_each_child_of_node(led_node, np) {
p = of_find_property(np, "led-types", NULL);
-   if (!p)
-   continue;
 
while ((cur = of_prop_next_string(p, cur)) != NULL) {
powernv_led = devm_kzalloc(dev, sizeof(*powernv_led),
-- 
1.9.1

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

[PATCH v3 1/6] PCI: designware: remove wrong io_base assignment

[Stanimir Varbanov]

The io_base is used to keep the cpu physical address parsed
from ranges dt property. After issue pci_remap_iospace the
io_base has been assigned with io->start, which is not correct
cause io->start is a PCI bus address.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pci/host/pcie-designware.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 540f077c37ea..02a7452bdf23 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -440,7 +440,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
 ret, pp->io);
continue;
}
-   pp->io_base = pp->io->start;
break;
case IORESOURCE_MEM:
pp->mem = win->res;
-- 
1.7.9.5

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

Re: [PATCH] mm, oom: Give __GFP_NOFAIL allocations access to memory reserves

[Michal Hocko]

On Sun 22-11-15 13:55:31, Vlastimil Babka wrote:
> On 11.11.2015 14:48, mho...@kernel.org wrote:
> >  mm/page_alloc.c | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 8034909faad2..d30bce9d7ac8 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2766,8 +2766,16 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int 
> > order,
> > goto out;
> > }
> > /* Exhausted what can be done so it's blamo time */
> > -   if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL))
> > +   if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
> > *did_some_progress = 1;
> > +
> > +   if (gfp_mask & __GFP_NOFAIL) {
> > +   page = get_page_from_freelist(gfp_mask, order,
> > +   ALLOC_NO_WATERMARKS|ALLOC_CPUSET, ac);
> > +   WARN_ONCE(!page, "Unable to fullfil gfp_nofail 
> > allocation."
> > +   " Consider increasing min_free_kbytes.\n");
> 
> It seems redundant to me to keep the WARN_ON_ONCE also above in the if () 
> part?

They are warning about two different things. The first one catches a
buggy code which uses __GFP_NOFAIL from oom disabled context while the
second one tries to help the administrator with a hint that memory
reserves are too small.

> Also s/gfp_nofail/GFP_NOFAIL/ for consistency?

Fair enough, changed.

> Hm and probably out of scope of your patch, but I understand the WARN_ONCE
> (WARN_ON_ONCE) to be _ONCE just to prevent a flood from a single task looping
> here. But for distinct tasks and potentially far away in time, wouldn't we 
> want
> to see all the warnings? Would that be feasible to implement?

I was thinking about that as well some time ago but it was quite
hard to find a good enough API to tell when to warn again. The first
WARN_ON_ONCE should trigger for all different _code paths_ no matter
how frequently they appear to catch all the buggy callers. The second
one would benefit from a new warning after min_free_kbytes was updated
because it would tell the administrator that the last update was not
sufficient for the workload.

> 
> > +   }
> > +   }
> >  out:
> > mutex_unlock(&oom_lock);
> > return page;
> > 

Thanks!
-- 
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 v3 0/6] Qualcomm PCIe driver and designware fixes

[Stanimir Varbanov]

This patch set is continuation of previous v2 at [1]. This time I
decided to drop the PHY driver needed by pcie driver for apq8084
and send it separately soon (when sort out the need of separate phy
driver).

First two patches in the set are fixes in pcie designware driver
found during testing the qcom pcie driver. The second patch can
be treated as an RFC.

Next two patches adds DT binding document and the driver itself.

The last two patches just adds relevant dt node for apq8064 and
enable pcie usage on ifc6410 development board. The testing has been
made on ifc6410 development board.

Comments are welcome!

Here is edited description:

This patchset introduces a Qualcomm PCIe root complex driver for
Snapdragon 805 (APQ8084) and Snapdragon 600 (APQ8064). The PCIe
hardware use Designware IP core plus Qualcomm application
specific hw wrappers.

[1] https://lkml.org/lkml/2015/5/4/267

Stanimir Varbanov (6):
  PCI: designware: remove wrong io_base assignment
  PCI: designware: add memory barrier after enabling region
  DT: PCI: qcom: Document PCIe devicetree bindings
  PCI: qcom: Add Qualcomm PCIe controller driver
  ARM: dts: apq8064: add pcie devicetree node
  ARM: dts: ifc6410: enable pcie dt node for this board

 .../devicetree/bindings/pci/qcom,pcie.txt  |  231 
 MAINTAINERS|7 +
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 +
 arch/arm/boot/dts/qcom-apq8064.dtsi|   36 ++
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-designware.c |6 +-
 drivers/pci/host/pcie-qcom.c   |  623 
 8 files changed, 939 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt
 create mode 100644 drivers/pci/host/pcie-qcom.c

-- 
1.7.9.5

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

[PATCH v3 2/6] PCI: designware: add memory barrier after enabling region

[Stanimir Varbanov]

Add 'write memory' barrier after enable region in PCIE_ATU_CR2
register. The barrier is needed to ensure that the region enable
request has been reached it's destination at time when we
read/write to PCI configuration space.

Without this barrier PCI device enumeration during kernel boot
is not reliable, and reading configuration space for particular
PCI device on the bus returns zero aka no device.

Signed-off-by: Stanimir Varbanov 
---
 drivers/pci/host/pcie-designware.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 02a7452bdf23..e15a2ae1583f 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -164,6 +164,11 @@ static void dw_pcie_prog_outbound_atu(struct pcie_port 
*pp, int index,
dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
+   /*
+* ensure that the ATU enable has been happaned before accessing
+* pci configuration/io spaces through dw_pcie_cfg_[read|write].
+*/
+   smp_wmb();
 }
 
 static struct irq_chip dw_msi_irq_chip = {
-- 
1.7.9.5

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

[PATCH v3 6/6] ARM: dts: ifc6410: enable pcie dt node for this board

[Stanimir Varbanov]

Enable pcie dt node and fill pcie dt node with regulator, pinctrl
and reset gpio, to use the pcie on the ifc6410 board.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 11ac608b6d50..bdee36a9b418 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -47,6 +47,18 @@
bias-disable;
};
};
+
+   pcie0_pins: pcie0_pinmux {
+   mux {
+   pins = "gpio27";
+   function = "gpio";
+   };
+   conf {
+   pins = "gpio27";
+   drive-strength = <12>;
+   bias-disable;
+   };
+   };
};
 
rpm@108000 {
@@ -123,6 +135,10 @@
pm8921_lvs1: lvs1 {
bias-pull-down;
};
+
+   pm8921_lvs6: lvs6 {
+   bias-pull-down;
+   };
};
};
 
@@ -231,6 +247,16 @@
status = "okay";
};
 
+   pci@1b50 {
+   status = "ok";
+   vdda-supply = <&pm8921_s3>;
+   vdda_phy-supply = <&pm8921_lvs6>;
+   vdda_refclk-supply = <&ext_3p3v>;
+   pinctrl-0 = <&pcie0_pins>;
+   pinctrl-names = "default";
+   perst-gpio = <&tlmm_pinmux 27 GPIO_ACTIVE_LOW>;
+   };
+
qcom,ssbi@50 {
pmic@0 {
gpio@150 {
-- 
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 3/6] DT: PCI: qcom: Document PCIe devicetree bindings

[Stanimir Varbanov]

From: Stanimir Varbanov 

Document Qualcomm PCIe driver devicetree bindings.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Stanimir Varbanov 
---
 .../devicetree/bindings/pci/qcom,pcie.txt  |  231 
 1 file changed, 231 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt 
b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
new file mode 100644
index ..d7640d45fa31
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -0,0 +1,231 @@
+* Qualcomm PCI express root complex
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: Value shall include
+   - "qcom,pcie-v0" for apq/ipq8064
+   - "qcom,pcie-v1" for apq8084
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register ranges as listed in the reg-names property
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: Must include the following entries
+   - "parf"   Qualcomm specific registers
+   - "dbi"Designware PCIe registers
+   - "elbi"   External local bus interface registers
+   - "config" PCIe configuration space
+
+- device_type:
+   Usage: required
+   Value type: 
+   Definition: Should be "pci". As specified in designware-pcie.txt
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be set to 3. As specified in designware-pcie.txt
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be set 2. As specified in designware-pcie.txt
+
+- ranges:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: MSI interrupt
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain "msi"
+
+- #interrupt-cells:
+   Usage: required
+   Value type: 
+   Definition: Should be 1. As specified in designware-pcie.txt
+
+- interrupt-map-mask:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- interrupt-map:
+   Usage: required
+   Value type: 
+   Definition: As specified in designware-pcie.txt
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: List of phandle and clock specifier pairs as listed
+   in clock-names property
+
+- clock-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries
+   * should be populated for v0 and v1
+   - "iface"  Configuration AHB clock
+
+   * should be populated for v0
+   - "core"   Clocks the pcie hw block
+   - "phy"Clocks the pcie PHY block
+
+   * should be populated for v1
+   - "aux"Auxiliary (AUX) clock
+   - "bus_master" Master AXI clock
+   - "bus_slave"  Slave AXI clock
+
+- resets:
+   Usage: required
+   Value type: 
+   Definition: List of phandle and reset specifier pairs as listed
+   in reset-names property
+
+- reset-names:
+   Usage: required
+   Value type: 
+   Definition: Should contain the following entries
+   * should be populated for v0
+   - "axi"  AXI reset
+   - "ahb"  AHB reset
+   - "por"  POR reset
+   - "pci"  PCI reset
+   - "phy"  PHY reset
+
+   * should be populated for v1
+   - "core" Core reset
+
+- power-domains:
+   Usage: required (for v1 only)
+   Value type: 
+   Definition: A phandle and power domain specifier pair to the
+   power domain which is responsible for collapsing
+   and restoring power to the peripheral
+
+- -supply:
+   Usage: required
+   Value type: 
+   Definition: List of phandles to the power supply regulator(s)
+   * should be populated for v0 and v1
+   - "vdda"core analog power supply
+
+   * should be populated for v0
+   - "vdda_phy"analog power supply for PHY
+   - "vdda_refclk" analog power supply for IC which 
generate
+   reference clock
+
+- phys:
+   Usage: required (for v1 only)
+   Value type: 
+   Definition: List of phandle(s) as listed in phy-names property
+
+- phy-names:
+   Usage: required (for v1 only)
+   Value type: 
+   Definition: Should contain "pciephy"
+
+- -gpio:
+   Usage: optional
+ 

Re: [PATCH] powerpc: tracing: don't trace hcalls on offline CPUs

[Denis Kirjanov]

On 11/23/15, Michael Ellerman  wrote:
> On Fri, 2015-11-20 at 15:22 +0300, Denis Kirjanov wrote:
>> On 11/3/15, Denis Kirjanov  wrote:
>> > On 11/3/15, Michael Ellerman  wrote:
>> > > On Thu, 2015-10-29 at 22:10 +0300, Denis Kirjanov wrote:
>> > > > ./drmgr -c cpu -a -r gives the following warning:
>> > > >
>> > > > [ 2327.035563] RCU used illegally from offline CPU!
>> > > >
>> > > > Make the hypervisor tracepoints conditional by introducing
>> > > > TRACE_EVENT_FN_COND similar to TRACE_EVENT_FN
>> > >
>> > > We've fixed other cases like this with RCU_NONIDLE(), but I assume
>> > > that
>> > > doesn't work here because we're actually offline?
>> >
>> > Yes, in this case we're moving the complete core offline through
>> > dlpar...
>> >
>>
>> Hi Michael,
>> Could you pick this patch?
>
> It's mostly a tracing patch, so I'd need an ACK from Steve at least.
>
> It would probably be best if you split it into a "tracing: .. " patch which
> adds the new macros and then a powerpc patch which uses them.

Ok, sounds reasonable.

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

[PATCH v3 4/6] PCI: qcom: Add Qualcomm PCIe controller driver

[Stanimir Varbanov]

From: Stanimir Varbanov 

The PCIe driver reuse the Designware common code for host
and MSI initialization, and also program the Qualcomm
application specific registers.

Signed-off-by: Stanimir Varbanov 
Signed-off-by: Stanimir Varbanov 
---
 MAINTAINERS  |7 +
 drivers/pci/host/Kconfig |   10 +
 drivers/pci/host/Makefile|1 +
 drivers/pci/host/pcie-qcom.c |  623 ++
 4 files changed, 641 insertions(+)
 create mode 100644 drivers/pci/host/pcie-qcom.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b16bffabe70a..878d9068fe75 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8231,6 +8231,13 @@ S:   Maintained
 F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F: drivers/pci/host/pcie-hisi.c
 
+PCIE DRIVER FOR QUALCOMM MSM
+M: Stanimir Varbanov 
+L: linux-...@vger.kernel.org
+L: linux-arm-...@vger.kernel.org
+S: Maintained
+F: drivers/pci/host/*qcom*
+
 PCMCIA SUBSYSTEM
 P: Linux PCMCIA Team
 L: linux-pcm...@lists.infradead.org
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba947dc6..64d33ba3e336 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -172,4 +172,14 @@ config PCI_HISI
help
  Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
 
+config PCIE_QCOM
+   bool "Qualcomm PCIe controller"
+   depends on ARCH_QCOM && OF || COMPILE_TEST
+   select PCIE_DW
+   select PCIEPORTBUS
+   help
+ Say Y here to enable PCIe controller support on Qualcomm SoCs. The
+ PCIe controller use Designware core plus Qualcomm specific hardware
+ wrappers.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6924a1..e523c171febf 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
new file mode 100644
index ..5f1957988503
--- /dev/null
+++ b/drivers/pci/host/pcie-qcom.c
@@ -0,0 +1,623 @@
+/*
+ * Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ * Copyright 2015 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pcie-designware.h"
+
+#define PCIE20_PARF_PHY_CTRL   0x40
+#define PCIE20_PARF_PHY_REFCLK 0x4C
+#define PCIE20_PARF_DBI_BASE_ADDR  0x168
+#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE0x16c
+#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT  0x178
+
+#define PCIE20_ELBI_SYS_CTRL   0x04
+#define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
+
+#define PCIE20_ELBI_SYS_STTS   0x08
+#define XMLH_LINK_UP   BIT(10)
+
+#define PCIE20_CAP 0x70
+#define PCIE20_CAP_LINKCTRLSTATUS  (PCIE20_CAP + 0x10)
+#define PCIE20_CAP_LINKCTRLSTATUS_LINK_UP  BIT(29)
+
+#define PERST_DELAY_MS 1
+
+#define LINKUP_DELAY_US5000
+#define LINKUP_TIMEOUT_US  10
+
+struct qcom_pcie_resources_v0 {
+   struct clk *iface_clk;
+   struct clk *core_clk;
+   struct clk *phy_clk;
+   struct reset_control *pci_reset;
+   struct reset_control *axi_reset;
+   struct reset_control *ahb_reset;
+   struct reset_control *por_reset;
+   struct reset_control *phy_reset;
+   struct regulator *vdda;
+   struct regulator *vdda_phy;
+   struct regulator *vdda_refclk;
+};
+
+struct qcom_pcie_resources_v1 {
+   struct clk *iface;
+   struct clk *aux;
+   struct clk *master_bus;
+   struct clk *slave_bus;
+   struct reset_control *core;
+   struct regulator *vdda;
+};
+
+union qcom_pcie_resources {
+   struct qcom_pcie_resources_v0 v0;
+   struct qcom_pcie_resources_v1 v1;
+};
+
+struct qcom_pcie;
+
+struct qcom_pcie_ops {
+   int (*get_resources)(struct qcom_pcie *pcie);
+   int (*init)(struct qcom_pcie *pcie);
+   void (*deinit)(struct qcom_pcie *pcie);
+};
+
+struct qcom_pcie {
+   struct pcie_port

[PATCH v3 5/6] ARM: dts: apq8064: add pcie devicetree node

[Stanimir Varbanov]

Add the pcie dt node so that it can probe and used.

Signed-off-by: Stanimir Varbanov 
---
 arch/arm/boot/dts/qcom-apq8064.dtsi |   36 +++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index a4c1762b53ea..bb7181e8ef2f 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -659,5 +659,41 @@
compatible = "qcom,tcsr-apq8064", "syscon";
reg = <0x1a40 0x100>;
};
+
+   pcie: pci@1b50 {
+   compatible = "qcom,pcie-v0", "snps,dw-pcie";
+   reg = <0x1b50 0x1000
+  0x1b502000 0x80
+  0x1b60 0x100
+  0x0ff0 0x10>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges = <0x8100 0 0 0x0fe0 0 0x0010   /* 
I/O */
+ 0x8200 0 0 0x0800 0 0x07e0>; /* 
memory */
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1 &intc 0 36 
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2 &intc 0 37 
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3 &intc 0 38 
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4 &intc 0 39 
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+   clocks = <&gcc PCIE_A_CLK>,
+<&gcc PCIE_H_CLK>,
+<&gcc PCIE_PHY_REF_CLK>;
+   clock-names = "core", "iface", "phy";
+   resets = <&gcc PCIE_ACLK_RESET>,
+<&gcc PCIE_HCLK_RESET>,
+<&gcc PCIE_POR_RESET>,
+<&gcc PCIE_PCI_RESET>,
+<&gcc PCIE_PHY_RESET>;
+   reset-names = "axi", "ahb", "por", "pci", "phy";
+   status = "disabled";
+   };
};
 };
-- 
1.7.9.5

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

Re: lapic_suspend/lapic_resume wrong?

[Juergen Gross]

On 23/11/15 09:01, Ingo Molnar wrote:
> 
> * Juergen Gross  wrote:
> 
>> Hi,
>>
>> while trying to find the reason for a hanging kernel during resume
>> handling I found a strange inconsistency in arch/x86/kernel/apic/apic.c
>> regarding usage of config options.
>>
>> Attached patch addresses this, no test done as I'm not sure whether
>> this is a correct approach. Can you have a look at it, please?
>>
>>
>> Juergen
>>
>> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
>> index 2f69e3b..bc06c9d 100644
>> --- a/arch/x86/kernel/apic/apic.c
>> +++ b/arch/x86/kernel/apic/apic.c
>> @@ -2270,6 +2270,7 @@ static struct {
>>  unsigned int apic_tmict;
>>  unsigned int apic_tdcr;
>>  unsigned int apic_thmr;
>> +unsigned int apic_cmci;
>>  } apic_pm_state;
>>  
>>  static int lapic_suspend(void)
>> @@ -2299,6 +2300,10 @@ static int lapic_suspend(void)
>>  if (maxlvt >= 5)
>>  apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
>>  #endif
>> +#ifdef CONFIG_X86_MCE_INTEL
>> +if (maxlvt >= 6)
>> +apic_pm_state.apic_cmci = apic_read(APIC_LVTCMCI);
>> +#endif
>>  
>>  local_irq_save(flags);
>>  disable_local_APIC();
>> @@ -2355,10 +2360,14 @@ static void lapic_resume(void)
>>  apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
>>  apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
>>  apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
>> -#if defined(CONFIG_X86_MCE_INTEL)
>> +#if defined(CONFIG_X86_THERMAL_VECTOR)
>>  if (maxlvt >= 5)
>>  apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
>>  #endif
>> +#if defined(CONFIG_X86_MCE_INTEL)
>> +if (maxlvt >= 6)
>> +apic_write(APIC_LVTCMCI, apic_pm_state.apic_cmci);
>> +#endif
>>  if (maxlvt >= 4)
>>  apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
>>  apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
> 
> the x86 bit looks absolutely sensible to me.

Thanks. I'll give it a suspend/resume test and send out a patch.

> Have you checked whether we indeed lose this value over S/R, or is this 
> mostly 
> working fine by accident, due to us executing the CMCI vector initialization 
> via:
> 
>   
> mce_syscore_resume()->__mcheck_cpu_init_vendor()->mce_intel_feature_init()->intel_init_cmci()
>  
> 
> on every resume event?

I don't know. I was more concerned what might happen in a kernel
configured with CONFIG_X86_MCE_INTEL but not CONFIG_X86_THERMAL_VECTOR.
I guess on such a kernel the THMR vector could be set to zero causing
some pain (enabled, vector 0?).

> The Xen fix is unrelated, just put into the same patch, right?

Uuh, yes, sorry. Just a relict of testing another fix.


Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: do not loop over ALLOC_NO_WATERMARKS without triggering reclaim

[Michal Hocko]

It seems this patch hasn't reached the mmotm tree. Are there any
unresolved concerns left?

On Mon 16-11-15 14:22:19, mho...@kernel.org wrote:
> From: Michal Hocko 
> 
> __alloc_pages_slowpath is looping over ALLOC_NO_WATERMARKS requests if
> __GFP_NOFAIL is requested. This is fragile because we are basically
> relying on somebody else to make the reclaim (be it the direct reclaim
> or OOM killer) for us. The caller might be holding resources (e.g.
> locks) which block other other reclaimers from making any progress for
> example. Remove the retry loop and rely on __alloc_pages_slowpath to
> invoke all allowed reclaim steps and retry logic.
> 
> We have to be careful about __GFP_NOFAIL allocations from the
> PF_MEMALLOC context even though this is a very bad idea to begin with
> because no progress can be gurateed at all.  We shouldn't break the
> __GFP_NOFAIL semantic here though. It could be argued that this is
> essentially GFP_NOWAIT context which we do not support but PF_MEMALLOC
> is much harder to check for existing users because they might happen
> deep down the code path performed much later after setting the flag
> so we cannot really rule out there is no kernel path triggering this
> combination.
> 
> Acked-by: Mel Gorman 
> Signed-off-by: Michal Hocko 
> ---
>  mm/page_alloc.c | 32 ++--
>  1 file changed, 18 insertions(+), 14 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index b153fa3d0b9b..df7746280427 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3046,32 +3046,36 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int 
> order,
>* allocations are system rather than user orientated
>*/
>   ac->zonelist = node_zonelist(numa_node_id(), gfp_mask);
> - do {
> - page = get_page_from_freelist(gfp_mask, order,
> - ALLOC_NO_WATERMARKS, 
> ac);
> - if (page)
> - goto got_pg;
> -
> - if (gfp_mask & __GFP_NOFAIL)
> - wait_iff_congested(ac->preferred_zone,
> -BLK_RW_ASYNC, HZ/50);
> - } while (gfp_mask & __GFP_NOFAIL);
> + page = get_page_from_freelist(gfp_mask, order,
> + ALLOC_NO_WATERMARKS, ac);
> + if (page)
> + goto got_pg;
>   }
>  
>   /* Caller is not willing to reclaim, we can't balance anything */
>   if (!can_direct_reclaim) {
>   /*
> -  * All existing users of the deprecated __GFP_NOFAIL are
> -  * blockable, so warn of any new users that actually allow this
> -  * type of allocation to fail.
> +  * All existing users of the __GFP_NOFAIL are blockable, so warn
> +  * of any new users that actually allow this type of allocation
> +  * to fail.
>*/
>   WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL);
>   goto nopage;
>   }
>  
>   /* Avoid recursion of direct reclaim */
> - if (current->flags & PF_MEMALLOC)
> + if (current->flags & PF_MEMALLOC) {
> + /*
> +  * __GFP_NOFAIL request from this context is rather bizarre
> +  * because we cannot reclaim anything and only can loop waiting
> +  * for somebody to do a work for us.
> +  */
> + if (WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
> + cond_resched();
> + goto retry;
> + }
>   goto nopage;
> + }
>  
>   /* Avoid allocations with no watermarks from looping endlessly */
>   if (test_thread_flag(TIF_MEMDIE) && !(gfp_mask & __GFP_NOFAIL))
> -- 
> 2.6.2
> 

-- 
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] USB: serial: cp210x: Remove CP2110 ID from compatibility list

[Johan Hovold]

On Tue, Nov 10, 2015 at 04:40:13PM -0600, Konstantin Shkolnyy wrote:
> CP2110 ID (0x10c4, 0xea80) doesn't belong here because it's a HID
> and completely different from CP210x devices.
> 
> Signed-off-by: Konstantin Shkolnyy 

Now applied, 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 v1 6/7] test_hexdump: test all possible group sizes for overflow

[Rasmus Villemoes]

On Fri, Nov 20 2015, Andy Shevchenko  wrote:

> On Thu, 2015-11-19 at 11:14 +0100, Rasmus Villemoes wrote:
>> 
>> aren't you missing a
>> 
>>   test_hexdump_overflow(buflen, rounddown(len, gs), 32, gs, ascii);
>> 
>> here to also exercise the rowsize==32 code?
>
> I could add that as well, though it seems minor since the idea is to go
> for all branches, which 16 covers anyway.

Well, I didn't look into the implementation when I wrote that; it just
seemed like an obvious thing to check all allowed combinations of
rowsize, groupsize and ascii.

>>  static int __init test_hexdump_init(void)
>> >  {
>> >    unsigned int i;
>> > @@ -186,10 +199,10 @@ static int __init test_hexdump_init(void)
>> >    test_hexdump_set(rowsize, true);
>> >  
>> >    for (i = 0; i <= TEST_HEXDUMP_BUF_SIZE; i++)
>> > -  test_hexdump_overflow(i, false);
>> > +  test_hexdump_overflow_set(i, false);
>> >  
>> >    for (i = 0; i <= TEST_HEXDUMP_BUF_SIZE; i++)
>> > -  test_hexdump_overflow(i, true);
>> > +  test_hexdump_overflow_set(i, true);
>> 
>> It seems neater to do one loop:
>> 
>> for (i = 0; i <= TEST_HEXDUMP_BUF_SIZE; i++) {
>>   test_hexdump_overflow_set(i, false);
>>   test_hexdump_overflow_set(i, true);
>> }
>
> I would like to keep them separately, though I'm also okay to do it in
> one loop.

Your code, your call.

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

nfnetlink warnings

[Borislav Petkov]

Hey,

so I keep getting those since recently:

net/netfilter/nfnetlink_queue.c:519:19: warning: ‘nfnl_ct’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  if (ct && nfnl_ct->build(skb, ct, ctinfo, NFQA_CT, NFQA_CT_INFO) < 0)
   ^
net/netfilter/nfnetlink_queue.c:316:23: note: ‘nfnl_ct’ was declared here
  struct nfnl_ct_hook *nfnl_ct;
   ^
net/netfilter/nfnetlink_queue.c: In function ‘nfqnl_recv_verdict’:
net/netfilter/nfnetlink_queue.c:1083:11: warning: ‘nfnl_ct’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
nfnl_ct->seq_adjust(entry->skb, ct, ctinfo, diff);
   ^

and was thinking can we shut them up like this? I know, it is ugly :-\

I mean, it is obvious in both cases that nfnl_ct won't be used if ct is
not set but apparently gcc can't see that far...

---
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
index 7d81d280cb4f..cd61b0b5c413 100644
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -372,6 +372,8 @@ nfqnl_build_packet_message(struct net *net, struct 
nfqnl_instance *queue,
if (ct != NULL)
size += nfnl_ct->build_size(ct);
}
+   } else {
+   nfnl_ct = NULL;
}
 
if (queue->flags & NFQA_CFG_F_UID_GID) {
@@ -1069,6 +1071,8 @@ nfqnl_recv_verdict(struct sock *ctnl, struct sk_buff *skb,
nfnl_ct = rcu_dereference(nfnl_ct_hook);
if (nfnl_ct != NULL)
ct = nfqnl_ct_parse(nfnl_ct, nlh, nfqa, entry, &ctinfo);
+   } else {
+   nfnl_ct = NULL;
}
 
if (nfqa[NFQA_PAYLOAD]) {

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: rcar: remove unused variable

[Arnd Bergmann]

After a recent cleanup, the soc_card variable became unused
and now produces a warning:

soc/sh/rcar/core.c: In function '__rsnd_kctrl_new':
soc/sh/rcar/core.c:801:23: warning: unused variable 'soc_card' 
[-Wunused-variable]

This removes the variable.

Fixes: 1a497983a5ae ("ASoC: Change the PCM runtime array to a list")
Signed-off-by: Arnd Bergmann 

diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index c6685f14b9cb..90b244c1f526 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -798,7 +798,6 @@ static int __rsnd_kctrl_new(struct rsnd_mod *mod,
void (*update)(struct rsnd_dai_stream *io,
   struct rsnd_mod *mod))
 {
-   struct snd_soc_card *soc_card = rtd->card;
struct snd_card *card = rtd->card->snd_card;
struct snd_kcontrol *kctrl;
struct snd_kcontrol_new knew = {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/14] net: tcp_memcontrol: simplify linkage between socket and page counter

[Vladimir Davydov]

On Fri, Nov 20, 2015 at 01:56:48PM -0500, Johannes Weiner wrote:
> On Fri, Nov 20, 2015 at 03:42:16PM +0300, Vladimir Davydov wrote:
> > On Thu, Nov 12, 2015 at 06:41:28PM -0500, Johannes Weiner wrote:
> > > There won't be any separate counters for socket memory consumed by
> > > protocols other than TCP in the future. Remove the indirection and
> > 
> > I really want to believe you're right. And with vmpressure propagation
> > implemented properly you are likely to be right.
> > 
> > However, we might still want to account other socket protos to
> > memcg->memory in the unified hierarchy, e.g. UDP, or SCTP, or whatever
> > else. Adding new consumers should be trivial, but it will break the
> > legacy usecase, where only TCP sockets are supposed to be accounted.
> > What about adding a check to sock_update_memcg() so that it would enable
> > accounting only for TCP sockets in case legacy hierarchy is used?
> 
> Yup, I was thinking the same thing. But we can cross that bridge when
> we come to it and are actually adding further packet types.

Fair enough.

> 
> > For the same reason, I think we'd better rename memcg->tcp_mem to
> > something like memcg->sk_mem or we can even drop the cg_proto struct
> > altogether embedding its fields directly to mem_cgroup struct.
> > 
> > Also, I don't see any reason to have tcp_memcontrol.c file. It's tiny
> > and with this patch it does not depend on tcp code any more. Let's move
> > it to memcontrol.c?
> 
> I actually had all this at first, but then wondered if it makes more
> sense to keep the legacy code in isolation. Don't you think it would
> be easier to keep track of what's v1 and what's v2 if we keep the
> legacy stuff physically separate as much as possible? In particular I
> found that 'tcp_mem.' marker really useful while working on the code.
> 
> In the same vein, tcp_memcontrol.c doesn't really hurt anybody and I'd
> expect it to remain mostly unopened and unchanged in the future. But
> if we merge it into memcontrol.c, that code will likely be in the way
> and we'd have to make it explicit somehow that this is not actually
> part of the new memory controller anymore.
> 
> What do you think?

There isn't much code left in tcp_memcontrol.c, and not all of it is
legacy. We still want to call tcp_init_cgroup and tcp_destroy_cgroup
from memcontrol.c - in fact, it's the only call site, so I think we'd
better keep these functions there. Apart from init/destroy, there is
only stuff for handling legacy files, which is relatively small and
isolated. We can just put it along with memsw and kmem legacy files in
the end of memcontrol.c adding a comment that it's legacy. Personally,
I'd find the code easier to follow then, because currently the logic
behind the ACTIVE flag as well as memcg->tcp_mem init/use/destroy turns
out to be scattered between two files in different subsystems for no
apparent reason now, as it does not need tcp_prot any more. Besides,
this would allow us to accurately reuse the ACTIVE flag in init/destroy
for inc/dec static branch and probably in sock_update_memcg instead of
sprinkling cgroup_subsys_on_dfl all over the place, which would make the
code a bit cleaner IMO (in fact, that's why I proposed to drop ACTIVATED
bit and replace cg_proto->flags with ->active bool).

Regarding, tcp_mem marker, well, currently it's OK, because we don't
account anything but TCP sockets, but when it changes (and I'm pretty
sure it will), we'll have to rename it anyway. For now, I'm OK with
leaving it as is though.

Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] restrict /dev/mem to idle io memory ranges

[Ingo Molnar]

* Dan Williams  wrote:

> On Fri, Nov 20, 2015 at 12:12 PM, Russell King - ARM Linux
>  wrote:
> > On Fri, Nov 20, 2015 at 09:31:33AM -0800, Dan Williams wrote:
> >> This effectively promotes IORESOURCE_BUSY to IORESOURCE_EXCLUSIVE
> >> semantics by default.  If userspace really believes it is safe to access
> >> the memory region it can also perform the extra step of disabling an
> >> active driver.  This protects device address ranges with read side
> >> effects and otherwise directs userspace to use the driver.
> >
> > I'm happy with this as long as we retain the option to disable this
> > new behaviour.
> >
> > The reason being, when developing a driver, it is _very_ useful to
> > be able to poke around in the device's (and system memory) address
> > spaces with tools like devmem2 to work out what's going on when
> > things go wrong.
> >
> > To put it another way, I think it's a good idea to disable access to
> > these regions on production systems, but for driver development, we
> > want to retain the ability to poke around in physical address space
> > in any way we so desire.
> >
> 
> Sounds ok to me, but I do think it's a good idea to default it to the
> same value as STRICT_DEVMEM.  Perhaps:
> 
> bool "Filter I/O access to /dev/mem" if EXPERT
> default STRICT_DEVMEM

Agreed, STRICT_DEVMEM=y should grandfather in this new (and very sensible) 
restriction.

Thanks,

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

Re: [PATCH v2 2/2] drm/rockchip: Convert the probe function to the generic drm_of_component_probe()

[Mark yao]

On 2015年11月20日 22:22, Liviu Dudau wrote:

Initial attempt to convert rockchip to drm_of_component_probe() missed the
difference between ports and encoders when using the compare_of() function.
Now that drm_of_component_probe() has been enhanced, let's try again the
conversion.

Signed-off-by: Liviu Dudau


Looks good for me, and it works on popmetal board, so
 Acked-by: Mark Yao 

Thanks.

--
Ｍark Yao


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq: imx: Add cpufreq driver for imx7D/Solo SOC

[Lucas Stach]

Am Montag, den 23.11.2015, 22:07 +0800 schrieb Bai Ping:
> The i.MX7Dual/Solo is a new series of the i.MX SOC family.
> The existing cpufreq driver for 'i.MX6' or 'cpufreq-dt' can
> NOT match the requirement of this new SOC. This patch adds the
> cpufreq driver for i.MX7Dual/Solo.
> 
So, what are those requirements, which could not be matched with
cpufreq-dt? We should really try to not add another cpufreq driver.

I don't see anything special in here. A single regulator and some clocks
needing to be controlled in the right way. That's already handled for
i.MX5 with cpufreq-dt. Please look up how it is done there and try to do
it the same way for MX7, or provide substantial information why it
couldn't be done.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Improve spinlock performance by moving work to one core

[Ling Ma]

Hi Longman,

Attachments include user space application thread.c and kernel patch
spinlock-test.patch based on kernel 4.3.0-rc4

we run thread.c with kernel patch, test original and new spinlock respectively,
perf top -G indicates thread.c cause cache_alloc_refill and
cache_flusharray functions to spend ~25% time on original spinlock,
after introducing new spinlock in two functions, the cost time become ~22%.

The printed data  also tell us the new spinlock improves performance
by about 15%( 93841765576 / 81036259588) on E5-2699V3

Appreciate your comments.

Thanks
Ling

2015-11-07 1:38 GMT+08:00 Waiman Long :
>
> On 11/05/2015 11:28 PM, Ling Ma wrote:
>>
>> Longman
>>
>> Thanks for your suggestion.
>> We will look for real scenario to test, and could you please introduce
>> some benchmarks on spinlock ?
>>
>> Regards
>> Ling
>>
>>
>
> The kernel has been well optimized for most common workloads that spinlock 
> contention is usually not a performance bottleneck. There are still corner 
> cases where there is heavy spinlock contention.
>
> I used a spinlock loop microbenchmark like what you are doing as well as AIM7 
> for application level testing.
>
> Cheers,
> Longman
>
>


spinlock-test.patch
Description: Binary data
/**
	Test Case:
		OpenDir, Get status and close it.
*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define TEST_DIR "/tmp/thread"
#define MAX_TEST_THREAD (80)
#define MAX_TEST_FILE 5000

static unsigned long *result[MAX_TEST_THREAD];
static int stop = 0;

static void* case_function(void *para)
{
	int id = (int)(long)para;
	DIR *pDir;
	struct stat f_stat;
	struct dirent *entry=NULL;
	char path[256];
	char cmd[512];
	
	int filecnt   = 0;
	int dircnt= 0;
	int filetotalsize = 0;
	unsigned long myresult = 0;
	int f = 0;
	
	result[id] = &myresult;

	/* Goto my path and construct empty file */
	sprintf(path, "%s/%d", TEST_DIR, id);
	printf("Creating temp file at %s\n", path);

	sprintf(cmd, "mkdir %s", path);
	system(cmd);
	chdir(path);
	for (f = 0; f < MAX_TEST_FILE; f++)
	{
		char name[256];

		sprintf(name, "%s/%d", path, f);
		int t = open(name,  O_RDWR | O_CREAT | O_TRUNC, S_IRWXU);
		if (t != -1)
			close(t);
		else
		{
			printf("Errno = %d.\n", errno);
			exit(errno);
		}		
	}

again:
	if ((pDir = opendir(path)) == NULL)
	{
		printf("打开 %s 错误：没有那个文件或目录\n", TEST_DIR);
		goto err;
	}
	
	while ((entry = readdir(pDir)) != NULL)
	{
		struct stat buf;
		if (entry->d_name[0] == '.')
			continue;
		
		//f = open(entry->d_name, 0);
		f = stat(entry->d_name, &buf);
		
		if (f)
			close(f);
		myresult++;
		
		
		//printf("Filename %s, size %10d",entry->d_name, f_stat.st_size);
	}

	closedir(pDir);
	

	/* Need to stop */
	if (!stop)
		goto again;
	return 0;

err:
	;
}

void main()
{
	int i;
	pthread_t thread;

	system("mkdir "TEST_DIR);
		
	for (i = 0; i < MAX_TEST_THREAD; i++)
	{
		pthread_create(&thread, NULL, case_function, (void*)(long)i);
	}

	while (1)
	{
		sleep(1);
		printf("Statistics:\n");

		for (i = 0; i < MAX_TEST_THREAD; i++)
		{
			printf("%d\t", *result[i]);
		}
		printf("\n");
		for (i = 0; i < MAX_TEST_THREAD; i++)
			*result[i] = 0;
	}
}

Re: [PATCH] mm, oom: Give __GFP_NOFAIL allocations access to memory reserves

[Vlastimil Babka]

On 11/23/2015 10:29 AM, Michal Hocko wrote:

On Sun 22-11-15 13:55:31, Vlastimil Babka wrote:

On 11.11.2015 14:48, mho...@kernel.org wrote:

  mm/page_alloc.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8034909faad2..d30bce9d7ac8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2766,8 +2766,16 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order,
goto out;
}
/* Exhausted what can be done so it's blamo time */
-   if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL))
+   if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
*did_some_progress = 1;
+
+   if (gfp_mask & __GFP_NOFAIL) {
+   page = get_page_from_freelist(gfp_mask, order,
+   ALLOC_NO_WATERMARKS|ALLOC_CPUSET, ac);
+   WARN_ONCE(!page, "Unable to fullfil gfp_nofail 
allocation."
+   " Consider increasing min_free_kbytes.\n");


It seems redundant to me to keep the WARN_ON_ONCE also above in the if () part?


They are warning about two different things. The first one catches a
buggy code which uses __GFP_NOFAIL from oom disabled context while the


Ah, I see, I misinterpreted what the return values of out_of_memory() 
mean. But now that I look at its code, it seems to only return false 
when oom_killer_disabled is set to true. Which is a global thing and 
nothing to do with the context of the __GFP_NOFAIL allocation?



second one tries to help the administrator with a hint that memory
reserves are too small.


Also s/gfp_nofail/GFP_NOFAIL/ for consistency?


Fair enough, changed.


Hm and probably out of scope of your patch, but I understand the WARN_ONCE
(WARN_ON_ONCE) to be _ONCE just to prevent a flood from a single task looping
here. But for distinct tasks and potentially far away in time, wouldn't we want
to see all the warnings? Would that be feasible to implement?


I was thinking about that as well some time ago but it was quite
hard to find a good enough API to tell when to warn again. The first
WARN_ON_ONCE should trigger for all different _code paths_ no matter
how frequently they appear to catch all the buggy callers. The second
one would benefit from a new warning after min_free_kbytes was updated
because it would tell the administrator that the last update was not
sufficient for the workload.


Hm, what about adding a flag to the struct alloc_context, so that when 
the particular allocation attempt emits the warning, it sets a flag in 
the alloc_context so that it won't emit them again as long as it keeps 
looping and attempting oom. Other allocations will warn independently.


We could also print the same info as the "allocation failed" warnings 
do, since it's very similar, except we can't fail - but the admin/bug 
reporter should be interested in the same details as for an allocation 
failure that is allowed to fail. But it's also true that we have 
probably just printed the info during out_of_memory()... except when we 
skipped that for some reason?





+   }
+   }
  out:
mutex_unlock(&oom_lock);
return page;



Thanks!



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

RE: [PATCH] PCI: pcie-rcar: Fix OF node passed to MSI irq domain

[Phil Edworthy]

Hi Marc,

On 20 November 2015 09:49, Marc Zyngier wrote:
> On 18/11/15 18:01, Phil Edworthy wrote:
> > Hi Marc,
> >
> > On 16 November 2015 18:31, Marc Zyngier wrote:
> >> On 13/11/15 09:36, Phil Edworthy wrote:
> > 
> >>> Since the stack trace doesn't help that much I added some tracing:
> >>> pci_msi_setup_msi_irqs()
> >>>   calls pci_msi_get_domain()
> >>> calls dev_get_msi_domain(), gets a non-NULL domain.
> >>> pci_msi_setup_msi_irqs()
> >>>   calls pci_msi_domain_alloc_irqs()
> >>> calls msi_domain_alloc_irqs()
> >>> msi_domain_alloc_irqs:273: ops=ffc03193a810
> >>> msi_domain_alloc_irqs:274: ops->msi_check=ffc031161418
> >>> systemd-udevd[1311]: undefined instruction: pc=ffc03116141c
> >>> That looks to me as though msi_check is off pointing to the weeds.
> >>
> >> So the next step is to find out who initializes msi_check. Assuming
> >> someone does...
> > Nothing initializes msi_check...
> >
> >
> >>> By passing a NULL domain into irq_domain_add_linear() you get:
> >>> pci_msi_setup_msi_irqs()
> >>>   calls pci_msi_get_domain()
> >>> calls dev_get_msi_domain(), gets a NULL domain.
> >>> calls arch_setup_msi_irq()
> >>> All ok then.
> >>
> >> Yes, because you're sidestepping the issue. Any chance you could dig a
> >> bit deeper? I'd really like to nail this one down (before we convert
> >> your PCI driver to the right API... ;-).
> > The problem appears to be that when the pci host driver enables msi
> > it calls the following:
> > msi->domain = irq_domain_add_linear(pcie->dev->of_node,
> INT_PCI_MSI_NR,
> > &msi_domain_ops, &msi->chip);
> > The last arg is documented as:
> > * @host_data: Controller private data pointer
> > In _irq_domain_add() this ptr is stored in struct irq_domain's host_data.
> >
> > However, msi_domain_alloc_irqs() expects host_data to be a ptr to a
> > struct msi_domain_info.
> >
> > It seems that a number of other pci host drivers do the same, so I am
> > surprised that no one else has seen this.
> 
> Can you please give this hack a go and let me know if that helps?
Works for me!

Many thanks
Phil

> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 53e4632..7eaa4c8 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -54,7 +54,7 @@ static int pci_msi_setup_msi_irqs(struct pci_dev *dev, int
> nvec, int type)
>   struct irq_domain *domain;
> 
>   domain = pci_msi_get_domain(dev);
> - if (domain)
> + if (domain && irq_domain_is_hierarchy(domain))
>   return pci_msi_domain_alloc_irqs(domain, dev, nvec, type);
> 
>   return arch_setup_msi_irqs(dev, nvec, type);
> @@ -65,7 +65,7 @@ static void pci_msi_teardown_msi_irqs(struct pci_dev *dev)
>   struct irq_domain *domain;
> 
>   domain = pci_msi_get_domain(dev);
> - if (domain)
> + if (domain && irq_domain_is_hierarchy(domain))
>   pci_msi_domain_free_irqs(domain, dev);
>   else
>   arch_teardown_msi_irqs(dev);
> 
> --
> Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] pwm: ftm: fix clock enable/disable when using PM

[Thierry Reding]

On Wed, Nov 18, 2015 at 06:04:12PM -0800, Stefan Agner wrote:
> Thierry,
> 
> I realized that this patch did not make it into 4.4-rc1, while others,
> IMHO less important patches which have been posted later (e.g. sunxi
> whitespace fixes) have made it! :-(

The reason why I merged them is because they are low-risk, whereas this
patch of yours changes existing behaviour, and hasn't received any
feedback from anyone. So the choice that I need to make is to either
trust the original author to have tested the driver and it was working,
or you to have verified that it is still working after the patch on all
setups that it used to work on. The first option obviously carries the
least risk, and that's the reason why the patch hasn't been merged.

> Anything wrong with that? Or am I on your spam list? Note that this is
> already a RESEND :-)

If you want to get this merged, you should try to get some feedback from
at least the original author. Xiubo Li and I extensively discussed this
back at the time when he submitted the driver and we came up with the
current code as the best approach to making sure that clocks are on and
off when they should be. So if it's not working for you, I'm fine taking
the patch if Xiubo or somebody else has had the chance to look at it and
review or test it. So a Reviewed-by or Tested-by tag will go a long way
to convince me that it's safe to apply.

Also you enumerate all the various bits that are broken, and it would
seem to me that they could each be fixed individually rather than go and
implement something completely different which might have undesirable
side-effects. Such an approach would also make it more likely for me to
merge the patch because it would hopefully be more obvious what is being
fixed and that it's a correct fix.

It's not that I mind the rework, but I'd at least like for someone to
verify that it's all still working on existing setups. Now, I understand
that people can go missing, so if nobody were to give you a Reviewed-by
or Tested-by for a couple of weeks I'd even consider applying without,
but as it is, you didn't even Cc Xiubo on the patch, so he's likely
missed it entirely.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v2 4/5] dt-bindings: document sun8i_ths

[Chen-Yu Tsai]

On Mon, Nov 23, 2015 at 4:02 PM, Josef Gajdusek  wrote:
> This patch adds the binding documentation for the sun8i_ths driver
>
> Signed-off-by: Josef Gajdusek 
> ---
>  .../devicetree/bindings/thermal/sun8i-ths.txt  | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/sun8i-ths.txt
>
> diff --git a/Documentation/devicetree/bindings/thermal/sun8i-ths.txt 
> b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
> new file mode 100644
> index 000..67056bf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/sun8i-ths.txt
> @@ -0,0 +1,31 @@
> +* sun8i THS
> +
> +Required properties:
> +- compatible : "allwinner,sun8i-h3-ths"
> +- reg : Address range of the thermal registers and location of the 
> calibration
> +value

You are now using nvmem for the calibration data. You don't need the second
entry.

> +- resets : Must contain an entry for each entry in reset-names.
> +   see ../reset/reset.txt for details
> +- reset-names : Must include the name "ahb"
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
> +  clock
> +
> +Optional properties:
> +- nvmem-cells : Must contain an entry for each entry in nvmem-cell-names
> +- nvmem-cell-names : Must contain "calibration" for the cell containing the
> +  temperature calibration cell, if available
> +
> +Example:
> +ths: ths@01c25000 {
> +   #thermal-sensor-cells = <0>;
> +   compatible = "allwinner,sun8i-h3-ths";
> +   reg = <0x01c25000 0x88>, <0x01c14234 0x4>;

Same here.

ChenYu

> +   interrupts = ;
> +   resets = <&bus_rst 136>;
> +   reset-names = "ahb";
> +   clocks = <&bus_gates 72>, <&ths_clk>;
> +   clock-names = "ahb", "ths";
> +   nvmem-cells = <&ths_calibration>;
> +   nvmem-cell-names = "calibration";
> +};
> --
> 2.4.10
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3 v8] livepatch: function,sympos scheme in livepatch sysfs directory

[Miroslav Benes]

On Fri, 20 Nov 2015, Chris J Arges wrote:

> The following directory structure will allow for cases when the same
> function name exists in a single object.
>   /sys/kernel/livepatch///
> 
> The sympos number corresponds to the nth occurrence of the symbol name in
> kallsyms for the patched object.
> 
> An example of patching multiple symbols can be found here:
>   https://github.com/dynup/kpatch/issues/493
> 
> Signed-off-by: Chris J Arges 

Reviewed-by: Miroslav Benes 

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