Re: [PATCH 18/28] of: create default early_init_dt_add_memory_arch

[Rob Herring]

On Tue, Sep 17, 2013 at 10:33 PM, Grant Likely  wrote:
> On Mon, 16 Sep 2013 18:09:14 -0500, Rob Herring  wrote:
>> From: Rob Herring 
>>
>> Create a weak version of early_init_dt_add_memory_arch which uses
>> memblock or is an empty function when memblock is not enabled. This
>> will unify all architectures except ones with custom memory bank
>> structs.
>
> Two comments below, but otherwise:
>
> Acked-by: Grant Likely 
>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 0714dd4..a9dce7a 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -688,6 +688,17 @@ u64 __init dt_mem_next_cell(int s, __be32 **cellp)
>>   return of_read_number(p, s);
>>  }
>>
>> +void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
>> +{
>> +#ifdef CONFIG_HAVE_MEMBLOCK
>> + base &= PAGE_MASK;
>> + size &= PAGE_MASK;
>> + memblock_add(base, size);
>> +#else
>> + pr_err("%s: ignoring memory (%llx, %llx)\n", __func__, base, size);
>> +#endif
>> +}
>> +
>
> Can you do it this way instead:
>
> #ifdef CONFIG_HAVE_MEMBLOCK
> void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> base &= PAGE_MASK;
> size &= PAGE_MASK;
> memblock_add(base, size);
> }
> #endif
>
> If the platform doesn't provide an early_init_dt_add_memory_arch()
> function and it doesn't have a memblock implementation, then the build
> should outright fail. I don't see a scenario where we would want to
> successfully build the kernel without a working add memory function.

metag and x86 both have empty functions. I guess they get memory from
a different boot interface.

Rob

>
> Also, can you group this function with the common __weak
> early_init_dt_alloc_memory_arch() implementation? It would be good to
> group all the memblock specific functions together.
>
> g.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: problem booting linux with qemu-system-arm -M spitz

[Waldemar Brodkorb]

Hi,
Andrea Adami wrote,

> On Wed, Sep 18, 2013 at 12:27 PM, Waldemar Brodkorb  wrote:
> > Hi Kernel hackers,
> >
> > I am trying to run Linux on Qemu/arm emulator with machine type
> > spitz. In the past this worked fine.
> > Now with Linux version 3.9.11 it does not boot anymore.
> > (blank screen, no kernel messages)
> >
> > I used git bisect to find the commit, which breaks the boot:
> > commit 4e8ee7de227e3ab9a72040b448ad728c5428a042
> > Author: Will Deacon 
> > Date:   Wed Nov 23 12:26:25 2011 +
> >
> > I am using Qemu 1.6.0 on a Debian/x86_64 host.
> >
> > Any help would be appreciated.
> >
> > Thanks in advance
> >  Waldemar
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> On real hardware I see the same breakage after 3.2.
> Marko diagnosed it and there is a pending patch:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/198444.html
> 
> There is indeed some MMU-related issue.
> Probably the function could be called elsewhere during machine init
> but I'm not so high in the food chain to dare to touch arm boot code
> ;)
> 
> Regards

Great! Thank you very much, this works fine.

best regards
 Waldemar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Dependency bug in the uvcvideo Kconfig

[Randy Dunlap]

[adding linux-media mailing list]


On 09/18/13 06:18, Jeff P. Zacher wrote:
> Not subscribed, please CC'me in replies:
> 
> There seems to be a dependency bug in the Kconfig for the uvcvideo kernel 
> module.  If uvcvideo is built in and usb support is built as a module, the 
> kernel build will fail with the obviously missing dependanies.
> 
> 
> Error logs:
> 
> * ERROR: Failed to compile the "bzImage" target...
> * 
> * -- Grepping log... --
> * 
> *  SHIPPED scripts/genksyms/keywords.hash.c
> *  SHIPPED scripts/genksyms/parse.tab.h
> *  SHIPPED scripts/genksyms/parse.tab.c
> *  HOSTCC  scripts/genksyms/lex.lex.o
> *scripts/genksyms/lex.lex.c_shipped: In function ‘yylex1’:
> *scripts/genksyms/lex.lex.c_shipped:904:1: warning: ignoring return value of 
> ‘fwrite’, declared with attribute warn_unused_result [-Wunused-result]
> *--
> *  CC  drivers/video/console/font_8x16.o
> *  CC  drivers/video/console/softcursor.o
> *  CC  sound/core/seq/seq_memory.o
> *  CC  drivers/video/console/fbcondecor.o
> *  CC  sound/core/seq/seq_queue.o
> *drivers/video/console/fbcondecor.c:511:6: warning: function declaration 
> isn’t 
> a prototype [-Wstrict-prototypes]
> *--
> *(.text+0xf8fb1): undefined reference to `usb_submit_urb'
> *drivers/built-in.o: In function `uvc_init':
> *uvc_driver.c:(.init.text+0x908a): undefined reference to 
> `usb_register_driver'
> *drivers/built-in.o: In function `uvc_cleanup':
> *uvc_driver.c:(.exit.text+0x67e): undefined reference to `usb_deregister'
> *make: *** [vmlinux] Error 1
> *--
> * Running with options: --lvm --menuconfig all
> * Using genkernel.conf from /etc/genkernel.conf
> * Sourcing arch-specific config.sh from 
> /usr/share/genkernel/arch/x86_64/config.sh ..
> * Sourcing arch-specific modules_load from 
> /usr/share/genkernel/arch/x86_64/modules_load ..
> *
> * ERROR: Failed to compile the "bzImage" target...
> * 
> * -- End log... --
> 
> Compiling uvc as a module allows the compilation to complete.
> 
> Platform x86_64
> 
> Ref: http://forums.gentoo.org/viewtopic-p-7398782.html#7398782
> 
> 
> -- Jeff P. Zacher
> ad_si...@yahoo.com


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

[PATCH 12/12] clk: tegra: introduce common gen4 super clock

[Peter De Schrijver]

Introduce a common function which super clock initialization for Tegra114
and beyond.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/Makefile   |1 +
 drivers/clk/tegra/clk-tegra-super-gen4.c |  220 ++
 drivers/clk/tegra/clk-tegra114.c |  126 +-
 drivers/clk/tegra/clk.h  |2 +
 4 files changed, 226 insertions(+), 123 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-tegra-super-gen4.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 5b78841..a4e5b5a 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -11,6 +11,7 @@ obj-y += clk-tegra-periph.o
 obj-y  += clk-tegra-pmc.o
 obj-y  += clk-tegra-fixed.o
 obj-y  += clk-tegra-osc.o
+obj-y  += clk-tegra-super-gen4.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
diff --git a/drivers/clk/tegra/clk-tegra-super-gen4.c 
b/drivers/clk/tegra/clk-tegra-super-gen4.c
new file mode 100644
index 000..9130025
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra-super-gen4.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+#include "clk-id.h"
+
+#define PLLX_BASE 0xe0
+#define PLLX_MISC 0xe4
+#define PLLX_MISC2 0x514
+#define PLLX_MISC3 0x518
+
+#define PLL_BASE_LOCK BIT(27)
+#define PLL_MISC_LOCK_ENABLE 18
+
+#define CCLKG_BURST_POLICY 0x368
+#define CCLKLP_BURST_POLICY 0x370
+#define SCLK_BURST_POLICY 0x028
+#define SYSTEM_CLK_RATE 0x030
+
+static DEFINE_SPINLOCK(sysrate_lock);
+
+static const char *sclk_parents[] = { "clk_m", "pll_c_out1", "pll_p_out4",
+  "pll_p", "pll_p_out2", "unused",
+  "clk_32k", "pll_m_out1" };
+
+static const char *cclk_g_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
+   "pll_p", "pll_p_out4", "unused",
+   "unused", "pll_x" };
+
+static const char *cclk_lp_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
+"pll_p", "pll_p_out4", "unused",
+"unused", "pll_x", "pll_x_out0" };
+
+static struct tegra_clk_pll_freq_table pll_x_freq_table[] = {
+   /* 1 GHz */
+   {1200, 10, 83, 0, 1},   /* actual: 996.0 MHz */
+   {1300, 10, 76, 0, 1},   /* actual: 988.0 MHz */
+   {1680, 10, 59, 0, 1},   /* actual: 991.2 MHz */
+   {1920, 10, 52, 0, 1},   /* actual: 998.4 MHz */
+   {2600, 10, 76, 1, 1},   /* actual: 988.0 MHz */
+   {0, 0, 0, 0, 0, 0},
+};
+
+static struct div_nmp pllxc_nmp = {
+   .divm_shift = 0,
+   .divm_width = 8,
+   .divn_shift = 8,
+   .divn_width = 8,
+   .divp_shift = 20,
+   .divp_width = 4,
+};
+
+static struct pdiv_map pllxc_p[] = {
+   { .pdiv = 1, .hw_val = 0 },
+   { .pdiv = 2, .hw_val = 1 },
+   { .pdiv = 3, .hw_val = 2 },
+   { .pdiv = 4, .hw_val = 3 },
+   { .pdiv = 5, .hw_val = 4 },
+   { .pdiv = 6, .hw_val = 5 },
+   { .pdiv = 8, .hw_val = 6 },
+   { .pdiv = 10, .hw_val = 7 },
+   { .pdiv = 12, .hw_val = 8 },
+   { .pdiv = 16, .hw_val = 9 },
+   { .pdiv = 12, .hw_val = 10 },
+   { .pdiv = 16, .hw_val = 11 },
+   { .pdiv = 20, .hw_val = 12 },
+   { .pdiv = 24, .hw_val = 13 },
+   { .pdiv = 32, .hw_val = 14 },
+   { .pdiv = 0, .hw_val = 0 },
+};
+
+static struct tegra_clk_pll_params pll_x_params = {
+   .input_min = 1200,
+   .input_max = 8,
+   .cf_min = 1200,
+   .cf_max = 1920, /* s/w policy, h/w capability 50 MHz */
+   .vco_min = 7,
+   .vco_max = 24U,
+   .base_reg = PLLX_BASE,
+   .misc_reg = PLLX_MISC,
+   .lock_mask = PLL_BASE_LOCK,
+   .lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
+   .lock_delay = 300,
+   .iddq_reg = PLLX_MISC3,
+   

Re: doing lots of disk writes causes oom killer to kill processes

[Michal Suchanek]

On 17 September 2013 23:13, Jan Kara  wrote:
>   Hello,
>
> On Tue 17-09-13 15:31:31, Michal Suchanek wrote:
>> On 5 September 2013 12:12, Michal Suchanek  wrote:
>> > On 26 August 2013 15:51, Michal Suchanek  wrote:
>> >> On 12 March 2013 03:15, Hillf Danton  wrote:
>> On 11 March 2013 13:15, Michal Suchanek  wrote:
>> >On 8 February 2013 17:31, Michal Suchanek  wrote:
>> > Hello,
>> >
>> > I am dealing with VM disk images and performing something like wiping
>> > free space to prepare image for compressing and storing on server or
>> > copying it to external USB disk causes
>> >
>> > 1) system lockup in order of a few tens of seconds when all CPU cores
>> > are 100% used by system and the machine is basicaly unusable
>> >
>> > 2) oom killer killing processes
>> >
>> > This all on system with 8G ram so there should be plenty space to work 
>> > with.
>> >
>> > This happens with kernels 3.6.4 or 3.7.1
>> >
>> > With earlier kernel versions (some 3.0 or 3.2 kernels) this was not a
>> > problem even with less ram.
>> >
>> > I have  vm.swappiness = 0 set for a long  time already.
>> >
>> >
>> I did some testing with 3.7.1 and with swappiness as much as 75 the
>> kernel still causes all cores to loop somewhere in system when writing
>> lots of data to disk.
>> 
>> With swappiness as much as 90 processes still get killed on large disk 
>> writes.
>> 
>> Given that the max is 100 the interval in which mm works at all is
>> going to be very narrow, less than 10% of the paramater range. This is
>> a severe regression as is the cpu time consumed by the kernel.
>> 
>> The io scheduler is the default cfq.
>> 
>> If you have any idea what to try other than downgrading to an earlier
>> unaffected kernel I would like to hear.
>> 
>> >>> Can you try commit 3cf23841b4b7(mm/vmscan.c: avoid possible
>> >>> deadlock caused by too_many_isolated())?
>> >>>
>> >>> Or try 3.8 and/or 3.9, additionally?
>> >>>
>> >>
>> >> Hello,
>> >>
>> >> with deadline IO scheduler I experience this issue less often but it
>> >> still happens.
>> >>
>> >> I am on 3.9.6 Debian kernel so 3.8 did not fix this problem.
>> >>
>> >> Do you have some idea what to log so that useful information about the
>> >> lockup is gathered?
>> >>
>> >
>> > This appears to be fixed in vanilla 3.11 kernel.
>> >
>> > I still get short intermittent lockups and cpu usage spikes up to 20%
>> > on a core but nowhere near the minute+ long lockups with all cores
>> > 100% on earlier kernels.
>> >
>>
>> So I did more testing on the 3.11 kernel and while it works OK with
>> tar you can get severe lockups with mc or kvm. The difference is
>> probably the fact that sane tools do fsync() on files they close
>> forcing the file to write out and the kernel returning possible write
>> errors before they move on to next file.
>   Sorry for chiming in a bit late. But is this really writing to a normal
> disk? SATA drive or something else?
>
>> With kvm writing to a file used as virtual disk the system would stall
>> indefinitely until the disk driver in the emulated system would time
>> out, return disk IO error, and the emulated system would stop writing.
>> In top I see all CPU cores 90%+ in wait. System is unusable. With mc
>> the lockups would be indefinite, probably because there is no timeout
>> on writing a file in mc.
>>
>> I tried tuning swappiness and eleveators but the the basic problem is
>> solved by neither: the dirty buffers fill up memory and system stalls
>> trying to resolve the situation.
>   This is really strange. There is /proc/sys/vm/dirty_ratio, which limits
> amount of dirty memory. By default it is set to 20% of memory which tends
> to be too much for 8 GB machine. Can you set it to something like 5% and
> /proc/sys/vm/dirty_background_ratio to 2%? That would be more appropriate
> sizing (assuming standard SATA drive). Does it change anything?

The default for dirty_ratio/dirty_background_ratio is 60/40. Setting
these to 5/2 gives about the same result as running the script that
syncs every 5s. Setting to 30/10 gives larger data chunks and
intermittent lockup before every chunk is written.

It is quite possible to set kernel parameters that kill the kernel but

1) this is the default
2) the parameter is set in units that do not prevent the issue in
general (% RAM vs #blocks)
3) WTH is the system doing? It's 4core 3GHz cpu so it can handle
traversing a structure holding 800M data in the background. Something
is seriously rotten somewhere.

Thanks

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

[PATCH 11/12] clk: tegra: introduce common tegra_osc_clk_init

[Peter De Schrijver]

Introduce a common tegra_osc_clk_init function which handles OSC and
pll ref probing and clock registration.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/Makefile|1 +
 drivers/clk/tegra/clk-tegra-osc.c |   81 +
 drivers/clk/tegra/clk-tegra114.c  |   39 +-
 drivers/clk/tegra/clk.h   |4 ++
 4 files changed, 88 insertions(+), 37 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-tegra-osc.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index a02e9a9..5b78841 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-tegra-audio.o
 obj-y  += clk-tegra-periph.o
 obj-y  += clk-tegra-pmc.o
 obj-y  += clk-tegra-fixed.o
+obj-y  += clk-tegra-osc.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
diff --git a/drivers/clk/tegra/clk-tegra-osc.c 
b/drivers/clk/tegra/clk-tegra-osc.c
new file mode 100644
index 000..bf8f32c
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra-osc.c
@@ -0,0 +1,81 @@
+/*
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+#include "clk-id.h"
+
+#define OSC_CTRL   0x50
+#define OSC_CTRL_OSC_FREQ_SHIFT28
+#define OSC_CTRL_PLL_REF_DIV_SHIFT 26
+
+int __init tegra_osc_clk_init(void __iomem *clk_base,
+   struct tegra_clk *tegra_clks,
+   unsigned long *input_freqs, int num,
+   unsigned long *osc_freq,
+   unsigned long *pll_ref_freq)
+{
+   struct clk *clk;
+   struct clk **dt_clk;
+   u32 val, pll_ref_div;
+   unsigned osc_idx;
+
+   val = readl_relaxed(clk_base + OSC_CTRL);
+   osc_idx = val >> OSC_CTRL_OSC_FREQ_SHIFT;
+
+   if (osc_idx < num)
+   *osc_freq = input_freqs[osc_idx];
+
+   if (!*osc_freq) {
+   WARN_ON(1);
+   return -EINVAL;
+   }
+
+   dt_clk = tegra_lookup_dt_id(tegra_clk_clk_m, tegra_clks);
+   if (!dt_clk)
+   return 0;
+
+   clk = clk_register_fixed_rate(NULL, "clk_m", NULL, CLK_IS_ROOT,
+ *osc_freq);
+   clk_register_clkdev(clk, "clk_m", NULL);
+   *dt_clk = clk;
+
+   /* pll_ref */
+   val = (val >> OSC_CTRL_PLL_REF_DIV_SHIFT) & 3;
+   pll_ref_div = 1 << val;
+   dt_clk = tegra_lookup_dt_id(tegra_clk_pll_ref, tegra_clks);
+   if (!dt_clk)
+   return 0;
+
+   clk = clk_register_fixed_factor(NULL, "pll_ref", "clk_m",
+   CLK_SET_RATE_PARENT, 1, pll_ref_div);
+   clk_register_clkdev(clk, "pll_ref", NULL);
+   *dt_clk = clk;
+
+   *pll_ref_freq = *osc_freq / pll_ref_div;
+
+   return 0;
+}
+
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 2598477..b2ddfbf 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -110,10 +110,6 @@
 #define PMC_CTRL_BLINK_ENB 7
 #define PMC_BLINK_TIMER 0x40
 
-#define OSC_CTRL   0x50
-#define OSC_CTRL_OSC_FREQ_SHIFT28
-#define OSC_CTRL_PLL_REF_DIV_SHIFT 26
-
 #define PLLXC_SW_MAX_P 6
 
 #define CCLKG_BURST_POLICY 0x368
@@ -795,38 +791,6 @@ static struct clk **clks;
 static unsigned long osc_freq;
 static unsigned long pll_ref_freq;
 
-static int __init tegra114_osc_clk_init(void __iomem *clk_base)
-{
-   struct clk *clk;
-   u32 val, pll_ref_div;
-
-   val = readl_relaxed(clk_base + OSC_CTRL);
-
-   osc_freq = tegra114_input_freq[val >> OSC_CTRL_OSC_FREQ_SHIFT];
-   if (!osc_freq) {
-   WARN_ON(1);
-   return -EINVAL;
-   }
-
-   /* clk_m */
-   clk = clk_register_fixed_rate(NULL, "clk_m", NULL, CLK_IS_ROOT,
- osc_freq);
-   clk_register_clkdev(clk, "clk_m", NULL);
-   

[PATCH 10/12] clk: tegra: move fixed clocks to common file

[Peter De Schrijver]

Introduce a new file for fixed clocks common between several Tegra
SoCs and move Tegra114 to this new infrastructure.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/Makefile  |1 +
 drivers/clk/tegra/clk-tegra-fixed.c |   62 +++
 drivers/clk/tegra/clk-tegra114.c|   26 +--
 drivers/clk/tegra/clk.h |1 +
 4 files changed, 65 insertions(+), 25 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-tegra-fixed.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index f415246..a02e9a9 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -9,6 +9,7 @@ obj-y   += clk-super.o
 obj-y  += clk-tegra-audio.o
 obj-y  += clk-tegra-periph.o
 obj-y  += clk-tegra-pmc.o
+obj-y  += clk-tegra-fixed.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
diff --git a/drivers/clk/tegra/clk-tegra-fixed.c 
b/drivers/clk/tegra/clk-tegra-fixed.c
new file mode 100644
index 000..252d710
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra-fixed.c
@@ -0,0 +1,62 @@
+/*
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+#include "clk-id.h"
+
+void __init tegra_fixed_clk_init(struct tegra_clk *tegra_clks)
+{
+   struct clk *clk;
+   struct clk **dt_clk;
+
+   /* clk_32k */
+   dt_clk = tegra_lookup_dt_id(tegra_clk_clk_32k, tegra_clks);
+   if (dt_clk) {
+   clk = clk_register_fixed_rate(NULL, "clk_32k", NULL,
+   CLK_IS_ROOT, 32768);
+   clk_register_clkdev(clk, "clk_32k", NULL);
+   *dt_clk = clk;
+   }
+
+   /* clk_m_div2 */
+   dt_clk = tegra_lookup_dt_id(tegra_clk_clk_m_div2, tegra_clks);
+   if (dt_clk) {
+   clk = clk_register_fixed_factor(NULL, "clk_m_div2", "clk_m",
+   CLK_SET_RATE_PARENT, 1, 2);
+   clk_register_clkdev(clk, "clk_m_div2", NULL);
+   *dt_clk = clk;
+   }
+
+   /* clk_m_div4 */
+   dt_clk = tegra_lookup_dt_id(tegra_clk_clk_m_div4, tegra_clks);
+   if (dt_clk) {
+   clk = clk_register_fixed_factor(NULL, "clk_m_div4", "clk_m",
+   CLK_SET_RATE_PARENT, 1, 4);
+   clk_register_clkdev(clk, "clk_m_div4", NULL);
+   *dt_clk = clk;
+   }
+}
+
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 19cd57b..2598477 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -827,30 +827,6 @@ static int __init tegra114_osc_clk_init(void __iomem 
*clk_base)
return 0;
 }
 
-static void __init tegra114_fixed_clk_init(void __iomem *clk_base)
-{
-   struct clk *clk;
-
-   /* clk_32k */
-   clk = clk_register_fixed_rate(NULL, "clk_32k", NULL, CLK_IS_ROOT,
- 32768);
-   clk_register_clkdev(clk, "clk_32k", NULL);
-   clks[TEGRA114_CLK_CLK_32K] = clk;
-
-   /* clk_m_div2 */
-   clk = clk_register_fixed_factor(NULL, "clk_m_div2", "clk_m",
-   CLK_SET_RATE_PARENT, 1, 2);
-   clk_register_clkdev(clk, "clk_m_div2", NULL);
-   clks[TEGRA114_CLK_CLK_M_DIV2] = clk;
-
-   /* clk_m_div4 */
-   clk = clk_register_fixed_factor(NULL, "clk_m_div4", "clk_m",
-   CLK_SET_RATE_PARENT, 1, 4);
-   clk_register_clkdev(clk, "clk_m_div4", NULL);
-   clks[TEGRA114_CLK_CLK_M_DIV4] = clk;
-
-}
-
 static __init void tegra114_utmi_param_configure(void __iomem *clk_base)
 {
u32 reg;
@@ -1434,7 +1410,7 @@ static void __init tegra114_clock_init(struct device_node 
*np)
if (tegra114_osc_clk_init(clk_base) < 0)
return;
 
-   tegra114_fixed_clk_init(clk_base);
+   tegra_fixed_clk_init(tegra114_clks);
tegra114_pll_init(clk_base, pmc_base);
tegra114_periph_clk_init(clk_base, 

[PATCH 09/12] clk: tegra: move PMC clocks to common file

[Peter De Schrijver]

Introduce a new file for PMC clocks common between several Tegra
SoCs and move Tegra114 to this new infrastructure.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/Makefile|1 +
 drivers/clk/tegra/clk-tegra-pmc.c |  131 +
 drivers/clk/tegra/clk-tegra114.c  |   69 +---
 drivers/clk/tegra/clk.h   |2 +-
 4 files changed, 134 insertions(+), 69 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-tegra-pmc.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 304ea5d..f415246 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -8,6 +8,7 @@ obj-y   += clk-pll-out.o
 obj-y  += clk-super.o
 obj-y  += clk-tegra-audio.o
 obj-y  += clk-tegra-periph.o
+obj-y  += clk-tegra-pmc.o
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
diff --git a/drivers/clk/tegra/clk-tegra-pmc.c 
b/drivers/clk/tegra/clk-tegra-pmc.c
new file mode 100644
index 000..2655acd
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra-pmc.c
@@ -0,0 +1,131 @@
+/*
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+#include "clk-id.h"
+
+#define PMC_CLK_OUT_CNTRL 0x1a8
+#define PMC_DPD_PADS_ORIDE 0x1c
+#define PMC_DPD_PADS_ORIDE_BLINK_ENB 20
+#define PMC_CTRL 0
+#define PMC_CTRL_BLINK_ENB 7
+#define PMC_BLINK_TIMER 0x40
+
+struct pmc_clk_init_data {
+   char *mux_name;
+   char *gate_name;
+   const char **parents;
+   int num_parents;
+   int mux_id;
+   int gate_id;
+   char *dev_name;
+   u8 mux_shift;
+   u8 gate_shift;
+};
+
+#define PMC_CLK(_num, _mux_shift, _gate_shift)\
+   {\
+   .mux_name = "clk_out_" #_num "_mux",\
+   .gate_name = "clk_out_" #_num,\
+   .parents = clk_out ##_num ##_parents,\
+   .num_parents = ARRAY_SIZE(clk_out ##_num ##_parents),\
+   .mux_id = tegra_clk_clk_out_ ##_num ##_mux,\
+   .gate_id = tegra_clk_clk_out_ ##_num,\
+   .dev_name = "extern" #_num,\
+   .mux_shift = _mux_shift,\
+   .gate_shift = _gate_shift,\
+   }
+
+static DEFINE_SPINLOCK(clk_out_lock);
+
+static const char *clk_out1_parents[] = { "clk_m", "clk_m_div2",
+   "clk_m_div4", "extern1",
+};
+
+static const char *clk_out2_parents[] = { "clk_m", "clk_m_div2",
+   "clk_m_div4", "extern2",
+};
+
+static const char *clk_out3_parents[] = { "clk_m", "clk_m_div2",
+   "clk_m_div4", "extern3",
+};
+
+static struct pmc_clk_init_data pmc_clks[] = {
+   PMC_CLK(1, 6, 2),
+   PMC_CLK(2, 14, 10),
+   PMC_CLK(3, 22, 18),
+};
+
+void __init tegra_pmc_clk_init(void __iomem *pmc_base,
+   struct tegra_clk *tegra_clks)
+{
+   struct clk *clk;
+   struct clk **dt_clk;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(pmc_clks); i++) {
+   struct pmc_clk_init_data *data;
+
+   data = pmc_clks + i;
+
+   dt_clk = tegra_lookup_dt_id(data->mux_id, tegra_clks);
+   if (!dt_clk)
+   continue;
+
+   clk = clk_register_mux(NULL, data->mux_name, data->parents,
+   data->num_parents, 0,
+   pmc_base + PMC_CLK_OUT_CNTRL, data->mux_shift,
+   3, 0, _out_lock);
+   *dt_clk = clk;
+
+
+   dt_clk = tegra_lookup_dt_id(data->gate_id, tegra_clks);
+   if (!dt_clk)
+   continue;
+
+   clk = clk_register_gate(NULL, data->gate_name, data->mux_name,
+   0, pmc_base + PMC_CLK_OUT_CNTRL,
+   data->gate_shift, 0, _out_lock);
+   *dt_clk = clk;
+   clk_register_clkdev(clk, data->dev_name, data->gate_name);
+   }
+
+   /* blink */
+   clk = clk_register_gate(NULL, "blink_override", "clk_32k", 0,
+  

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek  wrote:
> Hi!
>
>> >> >> > So will you do that? Or it is needed to resend this one line
>> >> >> > hunk again in new email again?
>> >> >>
>> >> >> new patch, new email
>> >> >
>> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >> >
>> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> >> > another is hassling. So what you want from me? Do all those non
>> >> > sense working only because yesterday you had bad day? Or what?
> ...
>> > Actually, there is need to be rude, because Felipe fails to act as
>> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
>> > patches, points people to random READMEs and wastes everyones time.
>>
>> I don't know what are you talking about (if that happened in another
>> thread then I need more context). Felipe is not bouncing any bugfix
>
> Take a look here:
>
> https://lkml.org/lkml/2013/9/17/286
>
> I clearly state that patch can not be tested as required for "proper"
> submission, but offer patch anyway. I get irrelevant boilerplate on
> patch format.
>

Felipe didn't complain about you not being to be able to test the
patch (most of the times compile tested if enough) what he said was:

"Seriously though, read that file, you're commit log has garbage in it
which shouldn't go to git history".

which is totally true, if you want to comment things that don't have
to go to the backlog you can't comment between the --- after your
s-o-b and before the first diff. That's were you should puts comments
like "Hi! or Here's suggested patch. I don't have the hardware, so it
is completely untested."

>> but just asked to split the patch in two since the patch was solving
>> two separate issues so is way better to have it in two separate
>> patches for the reasons I explained before.
>>
>> So, as far as I can tell Felipe did exactly what I would expect from a
>> maintainer. He took the time to review the patches sent to him and
>
> I'd expect maintainer to, well, maintain code. It means actually
> fixing bugs in his code, when he's pointed at them.
>
>> gave feedback. If the sender doesn't want to take his feedback into
>> account and prefer to send pretty insulting emails instead that is his
>> choice but I would say that is this not the greatest approach to get
>> your code merged (to say the least).
>
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
>

No, you misunderstood the role of the maintainers. Maintainers should
be custodian of a part of the kernel but not responsible for every
single line of code on their sub-systems. If a piece of code is buggy
then the people using and that take care of that should be fixing and
maintainers should review and suggest improvements to the patches. As
long as a piece of code keep compiling then it is harmless even if is
buggy and nobody cares about it. If it is so broken that it doesn't
even compile then the maintainer can decide to just drop it since no
one else seems to care about it.

If someone finds a bug on a piece of code is because that people care
about that functionality. Maintainers are really busy people and can
jump and fix any random bug that someone finds on a piece of code just
because it is the subsystem they maintainer neither they have to
blindly merge any crappy patch just because they don't have time (or
interest) in fixing a reported bug on a piece of code.

> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.
>

Clearly he meant "your commit log has garbage" instead of you're, that's a typo.

> Pavel

But neither Felipe needs someone to defend him nor I have time to keep
arguing with you.

Have nice day!
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 00/16] [RFC PATCH] Signed kexec support

[Andrea Adami]

Hello,

as one of the developers of kexecboot, a kexec-based
linux-as-bootloader, I'm following with interest this thread.
FWIW since the beginning we are compiling kexec-tools statically
against klibc for size constraints.

We have 2.02 and 2.0.4 almost finished (some issue with purgatory in
this last version).

There are some hacks needed but it is surely possible.

Cheers

Andrea



On Mon, Sep 16, 2013 at 4:28 PM, Vivek Goyal  wrote:
> On Thu, Sep 12, 2013 at 02:24:10PM -0400, Mimi Zohar wrote:
>
> [..]
>> > > So existing IMA does not seem to have been written for an environment
>> > > where all the user space is not signed we don't trust root and root can
>> > > attack a signed binary. And my patches try to fill that gap.
>> >
>> > It sounds like your changes should go into the IMA core code to resolve
>> > the issues there, as I'm sure they want to also protect from the issues
>> > you have pointed out here.  Have you talked to those developers about
>> > this?
>>
>> IMA assumes a different threat model and performance tradeoffs.  The
>> solutions suggested for the kexec, single userspace application threat
>> model, presumably wouldn't scale very well.
>
> Hi Mimi,
>
> Does IMA trust root or not? I got a feeling that IMA is assuming that
> root is trusted. Otherwise root can do raw writes to disk and bypass
> all the logic related to appraisal result caching.
>
> In fact on my system root disk belongs to group "disk". So any user in
> "disk" group seems to be a trusted user for IMA to work.
>
> Thanks
> Vivek
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/12] clk: tegra: move audio clk to common file

[Peter De Schrijver]

Move audio clocks and PLLA initialization to a common file so it can be used by
multiple Tegra SoCs.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/Makefile  |1 +
 drivers/clk/tegra/clk-tegra-audio.c |  260 +++
 drivers/clk/tegra/clk-tegra114.c|  254 +--
 drivers/clk/tegra/clk.h |4 +
 4 files changed, 266 insertions(+), 253 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-tegra-audio.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index f49fac2..796ff9a 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -6,6 +6,7 @@ obj-y   += clk-periph-gate.o
 obj-y  += clk-pll.o
 obj-y  += clk-pll-out.o
 obj-y  += clk-super.o
+obj-y  += clk-tegra-audio.o
 
 obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
diff --git a/drivers/clk/tegra/clk-tegra-audio.c 
b/drivers/clk/tegra/clk-tegra-audio.c
new file mode 100644
index 000..b34e385
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra-audio.c
@@ -0,0 +1,260 @@
+/*
+ * Copyright (c) 2012, 2013, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+#include "clk-id.h"
+
+#define AUDIO_SYNC_CLK_I2S0 0x4a0
+#define AUDIO_SYNC_CLK_I2S1 0x4a4
+#define AUDIO_SYNC_CLK_I2S2 0x4a8
+#define AUDIO_SYNC_CLK_I2S3 0x4ac
+#define AUDIO_SYNC_CLK_I2S4 0x4b0
+#define AUDIO_SYNC_CLK_SPDIF 0x4b4
+
+#define AUDIO_SYNC_DOUBLER 0x49c
+
+#define PLLA_BASE 0xb0
+#define PLLA_MISC 0xbc
+#define PLLA_OUT 0xb4
+
+#define PLL_BASE_LOCK BIT(27)
+#define PLL_MISC_LOCK_ENABLE 18
+
+struct tegra_sync_source_initdata {
+   char*name;
+   unsigned long   rate;
+   unsigned long   max_rate;
+   int clk_id;
+};
+
+struct tegra_audio_clk_initdata {
+   char*gate_name;
+   char*mux_name;
+   u32 offset;
+   int gate_clk_id;
+   int mux_clk_id;
+};
+
+#define AUDIO(_name, _offset) \
+   {\
+   .gate_name  = #_name,\
+   .mux_name   = #_name"_mux",\
+   .offset = _offset,\
+   .gate_clk_id= tegra_clk_ ## _name,\
+   .mux_clk_id = tegra_clk_ ## _name ## _mux,\
+   }
+
+struct tegra_audio2x_clk_initdata {
+   char*parent;
+   char*gate_name;
+   char*name_2x;
+   char*div_name;
+   int clk_id;
+   int clk_num;
+   u8  div_offset;
+};
+
+#define AUDIO2X(_name, _num, _offset) \
+   {\
+   .parent = #_name,\
+   .gate_name  = #_name"_2x",\
+   .name_2x= #_name"_doubler",\
+   .div_name   = #_name"_div",\
+   .clk_id = tegra_clk_ ## _name ## _2x,\
+   .clk_num= _num,\
+   }
+
+static DEFINE_SPINLOCK(clk_doubler_lock);
+
+static const char *mux_audio_sync_clk[] = { "spdif_in_sync", "i2s0_sync",
+   "i2s1_sync", "i2s2_sync", "i2s3_sync", "i2s4_sync", "vimclk_sync",
+};
+
+static struct tegra_sync_source_initdata __initdata sync_source_clks[] = {
+   { .name = "spdif_in_sync", .rate = 2400, .max_rate = 2400, 
.clk_id = tegra_clk_spdif_in_sync},
+   { .name = "i2s0_sync", .rate = 2400, .max_rate = 2400, .clk_id 
= tegra_clk_i2s0_sync},
+   { .name = "i2s1_sync", .rate = 2400, .max_rate = 2400, .clk_id 
= tegra_clk_i2s1_sync},
+   { .name = "i2s2_sync", .rate = 2400, .max_rate = 2400, .clk_id 
= tegra_clk_i2s2_sync},
+   { .name = "i2s3_sync", .rate = 2400, .max_rate = 2400, .clk_id 
= tegra_clk_i2s3_sync},
+   { .name = "i2s4_sync", .rate = 2400, .max_rate = 2400, .clk_id 
= tegra_clk_i2s4_sync},
+   { .name = "vimclk_sync", .rate = 2400, .max_rate = 2400, 
.clk_id = tegra_clk_vimclk_sync},
+};
+
+static struct tegra_audio_clk_initdata audio_clks[] = {
+   AUDIO(audio0, AUDIO_SYNC_CLK_I2S0),
+   

[PATCH 06/12] clk: tegra: add common infra for DT clocks

[Peter De Schrijver]

Introduce a common infrastructure for registering DT IDs for tegra clocks and
sharing clock initialization between SoCs. Move Tegra114 to this new
infrastructure.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-tegra114.c |  204 ++
 drivers/clk/tegra/clk.c  |   54 +-
 drivers/clk/tegra/clk.h  |   11 ++-
 3 files changed, 244 insertions(+), 25 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 71470ca..90ae909 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "clk.h"
+#include "clk-id.h"
 
 #define RST_DFLL_DVCO  0x2F4
 #define CPU_FINETRIM_SELECT0x4d4   /* override default prop dlys */
@@ -932,8 +933,187 @@ static const struct clk_div_table pll_re_div_table[] = {
{ .val = 0, .div = 0 },
 };
 
-static struct clk *clks[TEGRA114_CLK_CLK_MAX];
-static struct clk_onecell_data clk_data;
+static struct tegra_clk __initdata tegra114_clks[tegra_clk_max] = {
+   [tegra_clk_rtc] = { .dt_id = TEGRA114_CLK_RTC, .present = true },
+   [tegra_clk_timer] = { .dt_id = TEGRA114_CLK_TIMER, .present = true },
+   [tegra_clk_uarta] = { .dt_id = TEGRA114_CLK_UARTA, .present = true },
+   [tegra_clk_uartd] = { .dt_id = TEGRA114_CLK_UARTD, .present = true },
+   [tegra_clk_sdmmc2] = { .dt_id = TEGRA114_CLK_SDMMC2, .present = true },
+   [tegra_clk_i2s1] = { .dt_id = TEGRA114_CLK_I2S1, .present = true },
+   [tegra_clk_i2c1] = { .dt_id = TEGRA114_CLK_I2C1, .present = true },
+   [tegra_clk_ndflash] = { .dt_id = TEGRA114_CLK_NDFLASH, .present = true 
},
+   [tegra_clk_sdmmc1] = { .dt_id = TEGRA114_CLK_SDMMC1, .present = true },
+   [tegra_clk_sdmmc4] = { .dt_id = TEGRA114_CLK_SDMMC4, .present = true },
+   [tegra_clk_pwm] = { .dt_id = TEGRA114_CLK_PWM, .present = true },
+   [tegra_clk_i2s0] = { .dt_id = TEGRA114_CLK_I2S0, .present = true },
+   [tegra_clk_i2s2] = { .dt_id = TEGRA114_CLK_I2S2, .present = true },
+   [tegra_clk_epp] = { .dt_id = TEGRA114_CLK_EPP, .present = true },
+   [tegra_clk_gr_2d] = { .dt_id = TEGRA114_CLK_GR_2D, .present = true },
+   [tegra_clk_usbd] = { .dt_id = TEGRA114_CLK_USBD, .present = true },
+   [tegra_clk_isp] = { .dt_id = TEGRA114_CLK_ISP, .present = true },
+   [tegra_clk_gr_3d] = { .dt_id = TEGRA114_CLK_GR_3D, .present = true },
+   [tegra_clk_disp2] = { .dt_id = TEGRA114_CLK_DISP2, .present = true },
+   [tegra_clk_disp1] = { .dt_id = TEGRA114_CLK_DISP1, .present = true },
+   [tegra_clk_host1x] = { .dt_id = TEGRA114_CLK_HOST1X, .present = true },
+   [tegra_clk_vcp] = { .dt_id = TEGRA114_CLK_VCP, .present = true },
+   [tegra_clk_apbdma] = { .dt_id = TEGRA114_CLK_APBDMA, .present = true },
+   [tegra_clk_kbc] = { .dt_id = TEGRA114_CLK_KBC, .present = true },
+   [tegra_clk_kfuse] = { .dt_id = TEGRA114_CLK_KFUSE, .present = true },
+   [tegra_clk_sbc1] = { .dt_id = TEGRA114_CLK_SBC1, .present = true },
+   [tegra_clk_nor] = { .dt_id = TEGRA114_CLK_NOR, .present = true },
+   [tegra_clk_sbc2] = { .dt_id = TEGRA114_CLK_SBC2, .present = true },
+   [tegra_clk_sbc3] = { .dt_id = TEGRA114_CLK_SBC3, .present = true },
+   [tegra_clk_i2c5] = { .dt_id = TEGRA114_CLK_I2C5, .present = true },
+   [tegra_clk_dsia] = { .dt_id = TEGRA114_CLK_DSIA, .present = true },
+   [tegra_clk_mipi] = { .dt_id = TEGRA114_CLK_MIPI, .present = true },
+   [tegra_clk_hdmi] = { .dt_id = TEGRA114_CLK_HDMI, .present = true },
+   [tegra_clk_csi] = { .dt_id = TEGRA114_CLK_CSI, .present = true },
+   [tegra_clk_i2c2] = { .dt_id = TEGRA114_CLK_I2C2, .present = true },
+   [tegra_clk_uartc] = { .dt_id = TEGRA114_CLK_UARTC, .present = true },
+   [tegra_clk_mipi_cal] = { .dt_id = TEGRA114_CLK_MIPI_CAL, .present = 
true },
+   [tegra_clk_emc] = { .dt_id = TEGRA114_CLK_EMC, .present = true },
+   [tegra_clk_usb2] = { .dt_id = TEGRA114_CLK_USB2, .present = true },
+   [tegra_clk_usb3] = { .dt_id = TEGRA114_CLK_USB3, .present = true },
+   [tegra_clk_vde] = { .dt_id = TEGRA114_CLK_VDE, .present = true },
+   [tegra_clk_bsea] = { .dt_id = TEGRA114_CLK_BSEA, .present = true },
+   [tegra_clk_bsev] = { .dt_id = TEGRA114_CLK_BSEV, .present = true },
+   [tegra_clk_i2c3] = { .dt_id = TEGRA114_CLK_I2C3, .present = true },
+   [tegra_clk_sbc4] = { .dt_id = TEGRA114_CLK_SBC4, .present = true },
+   [tegra_clk_sdmmc3] = { .dt_id = TEGRA114_CLK_SDMMC3, .present = true },
+   [tegra_clk_owr] = { .dt_id = TEGRA114_CLK_OWR, .present = true },
+   [tegra_clk_csite] = { .dt_id = TEGRA114_CLK_CSITE, .present = true },
+   [tegra_clk_la] = { .dt_id = TEGRA114_CLK_LA, .present = true },
+   [tegra_clk_trace] = { .dt_id = TEGRA114_CLK_TRACE, .present = true },
+   [tegra_clk_soc_therm] = { .dt_id = 

[PATCH 05/12] clk: tegra: add header for common tegra clock IDs

[Peter De Schrijver]

Many clocks are common between several Tegra SoCs. Define an enum to list
them so we can move them to separate files which can be shared between
SoCs. Each SoC specific file will provide an array with the common clocks
which are present on the SoC and their DT binding ID.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-id.h |  197 
 1 files changed, 197 insertions(+), 0 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-id.h

diff --git a/drivers/clk/tegra/clk-id.h b/drivers/clk/tegra/clk-id.h
new file mode 100644
index 000..b2a4d45
--- /dev/null
+++ b/drivers/clk/tegra/clk-id.h
@@ -0,0 +1,197 @@
+/*
+ * This header provides IDs for clocks common between several Tegra SoCs
+ */
+
+#ifndef _TEGRA_CLK_ID_H
+#define _TEGRA_CLK_ID_H
+
+enum clk_id {
+   tegra_clk_rtc,
+   tegra_clk_timer,
+   tegra_clk_uarta,
+   tegra_clk_uartd,
+   tegra_clk_sdmmc2,
+   tegra_clk_i2s1,
+   tegra_clk_i2c1,
+   tegra_clk_ndflash,
+   tegra_clk_sdmmc1,
+   tegra_clk_sdmmc4,
+   tegra_clk_pwm,
+   tegra_clk_i2s0,
+   tegra_clk_i2s2,
+   tegra_clk_epp,
+   tegra_clk_gr_2d,
+   tegra_clk_usbd,
+   tegra_clk_isp,
+   tegra_clk_gr_3d,
+   tegra_clk_disp2,
+   tegra_clk_disp1,
+   tegra_clk_host1x,
+   tegra_clk_vcp,
+
+   tegra_clk_apbdma,
+   tegra_clk_kbc,
+   tegra_clk_kfuse,
+   tegra_clk_sbc1,
+   tegra_clk_nor,
+   tegra_clk_sbc2,
+   tegra_clk_sbc3,
+   tegra_clk_i2c5,
+   tegra_clk_dsia,
+   tegra_clk_mipi,
+   tegra_clk_hdmi,
+   tegra_clk_csi,
+   tegra_clk_i2c2,
+   tegra_clk_uartc,
+   tegra_clk_mipi_cal,
+   tegra_clk_emc,
+   tegra_clk_usb2,
+   tegra_clk_usb3,
+   tegra_clk_vde,
+   tegra_clk_bsea,
+   tegra_clk_bsev,
+
+   tegra_clk_i2c3,
+   tegra_clk_sbc4,
+   tegra_clk_sdmmc3,
+   tegra_clk_owr,
+   tegra_clk_csite,
+   tegra_clk_la,
+   tegra_clk_trace,
+   tegra_clk_soc_therm,
+   tegra_clk_dtv,
+   tegra_clk_ndspeed,
+   tegra_clk_i2cslow,
+   tegra_clk_dsib,
+   tegra_clk_tsec,
+   tegra_clk_xusb_host,
+   tegra_clk_msenc,
+   tegra_clk_csus,
+
+   tegra_clk_mselect,
+   tegra_clk_tsensor,
+   tegra_clk_i2s3,
+   tegra_clk_i2s4,
+   tegra_clk_i2c4,
+   tegra_clk_sbc5,
+   tegra_clk_sbc6,
+   tegra_clk_d_audio,
+   tegra_clk_apbif,
+   tegra_clk_dam0,
+   tegra_clk_dam1,
+   tegra_clk_dam2,
+   tegra_clk_hda2codec_2x,
+   tegra_clk_audio0_2x,
+   tegra_clk_audio1_2x,
+   tegra_clk_audio2_2x,
+   tegra_clk_audio3_2x,
+   tegra_clk_audio4_2x,
+   tegra_clk_spdif_2x,
+   tegra_clk_actmon,
+   tegra_clk_extern1,
+   tegra_clk_extern2,
+   tegra_clk_extern3,
+   tegra_clk_hda,
+   tegra_clk_se,
+
+   tegra_clk_hda2hdmi,
+   tegra_clk_cilab,
+   tegra_clk_cilcd,
+   tegra_clk_cile,
+   tegra_clk_dsialp,
+   tegra_clk_dsiblp,
+   tegra_clk_dds,
+   tegra_clk_dp2,
+   tegra_clk_amx,
+   tegra_clk_adx,
+   tegra_clk_xusb_ss,
+
+   tegra_clk_uartb,
+   tegra_clk_vfir,
+   tegra_clk_spdif_in,
+   tegra_clk_spdif_out,
+   tegra_clk_vi,
+   tegra_clk_vi_sensor,
+   tegra_clk_fuse,
+   tegra_clk_fuse_burn,
+   tegra_clk_clk_32k,
+   tegra_clk_clk_m,
+   tegra_clk_clk_m_div2,
+   tegra_clk_clk_m_div4,
+   tegra_clk_pll_ref,
+   tegra_clk_pll_c,
+   tegra_clk_pll_c_out1,
+   tegra_clk_pll_c2,
+   tegra_clk_pll_c3,
+   tegra_clk_pll_m,
+   tegra_clk_pll_m_out1,
+   tegra_clk_pll_p,
+   tegra_clk_pll_p_out1,
+   tegra_clk_pll_p_out2,
+   tegra_clk_pll_p_out3,
+   tegra_clk_pll_p_out4,
+   tegra_clk_pll_a,
+   tegra_clk_pll_a_out0,
+   tegra_clk_pll_d,
+   tegra_clk_pll_d_out0,
+   tegra_clk_pll_d2,
+   tegra_clk_pll_d2_out0,
+   tegra_clk_pll_u,
+   tegra_clk_pll_u_480m,
+
+   tegra_clk_pll_u_60m,
+   tegra_clk_pll_u_48m,
+   tegra_clk_pll_u_12m,
+   tegra_clk_pll_x,
+   tegra_clk_pll_x_out0,
+   tegra_clk_pll_re_vco,
+   tegra_clk_pll_re_out,
+   tegra_clk_pll_e_out0,
+   tegra_clk_spdif_in_sync,
+   tegra_clk_i2s0_sync,
+   tegra_clk_i2s1_sync,
+   tegra_clk_i2s2_sync,
+   tegra_clk_i2s3_sync,
+   tegra_clk_i2s4_sync,
+   tegra_clk_vimclk_sync,
+   tegra_clk_audio0,
+   tegra_clk_audio1,
+   tegra_clk_audio2,
+   tegra_clk_audio3,
+   tegra_clk_audio4,
+   tegra_clk_spdif,
+   tegra_clk_clk_out_1,
+   tegra_clk_clk_out_2,
+   tegra_clk_clk_out_3,
+   tegra_clk_blink,
+   tegra_clk_xusb_host_src,
+   tegra_clk_xusb_falcon_src,
+   tegra_clk_xusb_fs_src,
+   tegra_clk_xusb_ss_src,
+
+   tegra_clk_xusb_dev_src,
+   tegra_clk_xusb_dev,
+   

[PATCH 04/12] clk: tegra: move some PLLC and PLLXC init to clk-pll.c

[Peter De Schrijver]

vco min clipping, dynamic ramp setup and IDDQ init can be done in the
respective pll clk_register functions if the parent is already registered.
This is done for other some PLLs already.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-pll.c  |   95 +++--
 drivers/clk/tegra/clk-tegra114.c |  109 +++---
 2 files changed, 111 insertions(+), 93 deletions(-)

diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index 197074a..4cb2cec 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -755,6 +755,48 @@ static int _pll_fixed_mdiv(struct tegra_clk_pll_params 
*pll_params,
return 1;
 }
 
+static unsigned long _clip_vco_min(unsigned long vco_min,
+  unsigned long parent_rate)
+{
+   return DIV_ROUND_UP(vco_min, parent_rate) * parent_rate;
+}
+
+static int _setup_dynamic_ramp(struct tegra_clk_pll_params *pll_params,
+  void __iomem *clk_base,
+  unsigned long parent_rate)
+{
+   u32 val;
+   u32 step_a, step_b;
+
+   switch (parent_rate) {
+   case 1200:
+   case 1300:
+   case 2600:
+   step_a = 0x2B;
+   step_b = 0x0B;
+   break;
+   case 1680:
+   step_a = 0x1A;
+   step_b = 0x09;
+   break;
+   case 1920:
+   step_a = 0x12;
+   step_b = 0x08;
+   break;
+   default:
+   pr_err("%s: Unexpected reference rate %lu\n",
+   __func__, parent_rate);
+   WARN_ON(1);
+   return -EINVAL;
+   }
+
+   val = step_a << pll_params->stepa_shift;
+   val |= step_b << pll_params->stepb_shift;
+   writel_relaxed(val, clk_base + pll_params->dyn_ramp_reg);
+
+   return 0;
+}
+
 static int clk_pll_iddq_enable(struct clk_hw *hw)
 {
struct tegra_clk_pll *pll = to_clk_pll(hw);
@@ -1393,11 +1435,39 @@ struct clk *tegra_clk_register_pllxc(const char *name, 
const char *parent_name,
  spinlock_t *lock)
 {
struct tegra_clk_pll *pll;
-   struct clk *clk;
+   struct clk *clk, *parent;
+   unsigned long parent_rate;
+   int err;
+   u32 val, val_iddq;
+
+   parent = __clk_lookup(parent_name);
+   if (IS_ERR(parent)) {
+   WARN(1, "parent clk %s of %s must be registered first\n",
+   name, parent_name);
+   return ERR_PTR(-EINVAL);
+   }
 
if (!pll_params->pdiv_tohw)
return ERR_PTR(-EINVAL);
 
+   parent_rate = __clk_get_rate(parent);
+
+   pll_params->vco_min = _clip_vco_min(pll_params->vco_min, parent_rate);
+
+   err = _setup_dynamic_ramp(pll_params, clk_base, parent_rate);
+   if (err)
+   return ERR_PTR(err);
+
+   val = readl_relaxed(clk_base + pll_params->base_reg);
+   val_iddq = readl_relaxed(clk_base + pll_params->iddq_reg);
+
+   if (val & BIT(30))
+   WARN_ON(val_iddq & BIT(pll_params->iddq_bit_idx));
+   else {
+   val_iddq |= BIT(pll_params->iddq_bit_idx);
+   writel_relaxed(val_iddq, clk_base + pll_params->iddq_reg);
+   }
+
pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
  freq_table, lock);
@@ -1425,6 +1495,9 @@ struct clk *tegra_clk_register_pllre(const char *name, 
const char *parent_name,
struct clk *clk;
 
pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE | TEGRA_PLL_LOCK_MISC;
+
+   pll_params->vco_min = _clip_vco_min(pll_params->vco_min, parent_rate);
+
pll = _tegra_init_pll(clk_base, pmc, fixed_rate, pll_params, pll_flags,
  freq_table, lock);
if (IS_ERR(pll))
@@ -1468,11 +1541,23 @@ struct clk *tegra_clk_register_pllm(const char *name, 
const char *parent_name,
  spinlock_t *lock)
 {
struct tegra_clk_pll *pll;
-   struct clk *clk;
+   struct clk *clk, *parent;
+   unsigned long parent_rate;
 
if (!pll_params->pdiv_tohw)
return ERR_PTR(-EINVAL);
 
+   parent = __clk_lookup(parent_name);
+   if (IS_ERR(parent)) {
+   WARN(1, "parent clk %s of %s must be registered first\n",
+   name, parent_name);
+   return ERR_PTR(-EINVAL);
+   }
+
+   parent_rate = __clk_get_rate(parent);
+
+   pll_params->vco_min = _clip_vco_min(pll_params->vco_min, parent_rate);
+
pll_flags |= TEGRA_PLL_BYPASS;
pll_flags |= TEGRA_PLL_HAS_LOCK_ENABLE;
pll_flags |= TEGRA_PLLM;
@@ -1513,14 +1598,16 @@ struct clk *tegra_clk_register_pllc(const char *name, 
const char *parent_name,
return ERR_PTR(-EINVAL);
}
 
+   parent_rate = 

Re: [PATCH 00/12] Introduce common infra for tegra clocks

[Peter De Schrijver]

On Wed, Sep 18, 2013 at 04:40:52PM +0200, Peter De Schrijver wrote:
> This patchset introduces common infrastructure for clocks which exist in
> several Tegra SoCs. We also move Tegra114 to this new infrastructure.
> Tegra20 and Tegra30 will be moved later in separate patchsets.
> 
> Peter De Schrijver (12):
>   clk: tegra: simplify periph clock data
>   clk: tegra: periph_clk_enb_refcnt as common infra
>   clk: tegra: Add TEGRA_PERIPH_NO_DIV flag
>   clk: tegra: move some PLLC and PLLXC init to clk-pll.c
>   clk: tegra: add header for common tegra clock IDs
>   clk: tegra: add common infra for DT clocks
>   clk: tegra: move audio clk to common file
>   clk: tegra: move periph clocks to common file
>   clk: tegra: move PMC clocks to common file
>   clk: tegra: move fixed clocks to common file
>   clk: tegra: introduce common tegra_osc_clk_init
>   clk: tegra: introduce common gen4 super clock

Forgot to mention that this patchset relies on 

[PATCH] clk: tegra: replace enum tegra114_clk by binding header 

and obsoletes:

[PATCH v2 0/4] Introduce table driven initializations
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/12] clk: tegra: Add TEGRA_PERIPH_NO_DIV flag

[Peter De Schrijver]

This flag indicates the peripheral clock does not have a divider. It will
simply the initialization tables and avoids some very similar code.

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

diff --git a/drivers/clk/tegra/clk-periph.c b/drivers/clk/tegra/clk-periph.c
index 55ab4b1..becbeee 100644
--- a/drivers/clk/tegra/clk-periph.c
+++ b/drivers/clk/tegra/clk-periph.c
@@ -173,11 +173,12 @@ const struct clk_ops tegra_clk_periph_nodiv_ops = {
 static struct clk *_tegra_clk_register_periph(const char *name,
const char **parent_names, int num_parents,
struct tegra_clk_periph *periph,
-   void __iomem *clk_base, u32 offset, bool div,
+   void __iomem *clk_base, u32 offset,
unsigned long flags)
 {
struct clk *clk;
struct clk_init_data init;
+   bool div = !(periph->gate.flags & TEGRA_PERIPH_NO_DIV);
 
init.name = name;
init.ops = div ? _clk_periph_ops : _clk_periph_nodiv_ops;
@@ -210,7 +211,7 @@ struct clk *tegra_clk_register_periph(const char *name,
u32 offset, unsigned long flags)
 {
return _tegra_clk_register_periph(name, parent_names, num_parents,
-   periph, clk_base, offset, true, flags);
+   periph, clk_base, offset, flags);
 }
 
 struct clk *tegra_clk_register_periph_nodiv(const char *name,
@@ -218,6 +219,7 @@ struct clk *tegra_clk_register_periph_nodiv(const char 
*name,
struct tegra_clk_periph *periph, void __iomem *clk_base,
u32 offset)
 {
+   periph->gate.flags |= TEGRA_PERIPH_NO_DIV;
return _tegra_clk_register_periph(name, parent_names, num_parents,
-   periph, clk_base, offset, false, CLK_SET_RATE_PARENT);
+   periph, clk_base, offset, CLK_SET_RATE_PARENT);
 }
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index a133279..1b951a1 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -397,6 +397,7 @@ struct tegra_clk_periph_gate {
 #define TEGRA_PERIPH_MANUAL_RESET BIT(1)
 #define TEGRA_PERIPH_ON_APB BIT(2)
 #define TEGRA_PERIPH_WAR_1005168 BIT(3)
+#define TEGRA_PERIPH_NO_DIV BIT(4)
 
 void tegra_periph_reset(struct tegra_clk_periph_gate *gate, bool assert);
 extern const struct clk_ops tegra_clk_periph_gate_ops;
-- 
1.7.7.rc0.72.g4b5ea.dirty

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

Re: [PATCH 0/2] vsprintf: ignore %n again

[Kees Cook]

On Wed, Sep 18, 2013 at 6:14 AM, Tetsuo Handa
 wrote:
> Kees Cook wrote:
>> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
>> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
>> > and __vsnprintf(0, s, n, fmt, ...) otherwise.  Now,
>> > int __sprintf(int safe, char *buf, const char *fmt, ...)
>> > {
>> > va_list args;
>> > int i;
>> >
>> > va_start(args, fmt);
>> > i = __vsnprintf(safe, buf, INT_MAX, fmt, args);
>> > va_end(args);
>> >
>> > return i;
>> > }
>>
>> Unless I've misunderstood, I think we'd already get very close to this
>> with the gcc options instead. This patch set is what I've been using
>> to generate the format string fixes over the last few months, with 7
>> sent this last round:
>
> Can we utilize __builtin_constant_p() ?
>
> -- source start --
> #include 
>
> #define func(fmt)   \
> if (__builtin_constant_p(fmt))  \
> printf("const : %s\n", fmt);\
> else\
> printf("not const : %s\n", fmt);\
>
>
> int main(int argc, char *argv[])
> {
> const char *fmt1 = "const char *";
> const char fmt2[] = "const char []";
> const char * const fmt3 = "const char * const";
> func("literal");
> func(fmt1);
> func(fmt2);
> func(fmt3);

I wonder if we can get at the read-only knowledge. Doing this shows
that gcc knows they're read-only:

fmt1[2] = 'A';
fmt2[2] = 'A';
fmt3[2] = 'A';

/tmp/const.c:27:5: error: assignment of read-only location ‘*(fmt1 + 2u)’
/tmp/const.c:29:5: error: assignment of read-only location ‘fmt2[2]’
/tmp/const.c:31:5: error: assignment of read-only location ‘*(fmt3 + 2u)’

I didn't see a builtin for this in the gcc documentation I've been reading.

-Kees

> return 0;
> }
> -- source end --
>
> -- output start --
> const : literal
> not const : const char *
> not const : const char []
> const : const char * const
> -- output end --
>
> __builtin_constant_p() seems to enforce use of either "literal" or "* const".
>
> An example change
>
> -- patch start --
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -120,8 +120,9 @@ asmlinkage int printk_emit(int facility, int level,
>const char *dict, size_t dictlen,
>const char *fmt, ...);
>
> -asmlinkage __printf(1, 2) __cold
> -int printk(const char *fmt, ...);
> +//asmlinkage __printf(1, 2) __cold
> +//int printk(const char *fmt, ...);
> +#define printk(fmt, ...) compiletime_assert(__builtin_constant_p(fmt), 
> "Non-c  onstant format string")
>
>  /*
>   * Special printk facility for scheduler use only, _DO_NOT_USE_ !
> -- patch end --
>
> caught errors like below.
>
>   CC [M]  drivers/scsi/esas2r/esas2r_log.o
> drivers/scsi/esas2r/esas2r_log.c: In function 'esas2r_log_master':
> drivers/scsi/esas2r/esas2r_log.c:174: error: call to 
> '__compiletime_assert_174' declared with attribute error: Non-constant format 
> string



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

[PATCH 02/12] clk: tegra: periph_clk_enb_refcnt as common infra

[Peter De Schrijver]

This patch makes periph_clk_enb_refcnt a global array, dynamically allocated
at boottime. It simplifies the macros somewhat and allows clocks common to
several Tegra SoCs to be defined in a separate files.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-periph.c   |1 +
 drivers/clk/tegra/clk-tegra114.c |   36 +++-
 drivers/clk/tegra/clk-tegra20.c  |   16 +---
 drivers/clk/tegra/clk-tegra30.c  |   19 +++
 drivers/clk/tegra/clk.c  |2 ++
 drivers/clk/tegra/clk.h  |   14 +++---
 6 files changed, 33 insertions(+), 55 deletions(-)

diff --git a/drivers/clk/tegra/clk-periph.c b/drivers/clk/tegra/clk-periph.c
index b2309d3..55ab4b1 100644
--- a/drivers/clk/tegra/clk-periph.c
+++ b/drivers/clk/tegra/clk-periph.c
@@ -191,6 +191,7 @@ static struct clk *_tegra_clk_register_periph(const char 
*name,
periph->mux.reg = clk_base + offset;
periph->divider.reg = div ? (clk_base + offset) : NULL;
periph->gate.clk_base = clk_base;
+   periph->gate.enable_refcnt = periph_clk_enb_refcnt;
 
clk = clk_register(NULL, >hw);
if (IS_ERR(clk))
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 2ec3488..9970f87 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -57,8 +57,6 @@
 #define CPU_FINETRIM_R_FCPU_6_SHIFT10  /* ftop */
 #define CPU_FINETRIM_R_FCPU_6_MASK (0x3 << CPU_FINETRIM_R_FCPU_6_SHIFT)
 
-#define CLK_OUT_ENB_NUM6
-
 #define PLLC_BASE 0x80
 #define PLLC_MISC2 0x88
 #define PLLC_MISC 0x8c
@@ -264,8 +262,6 @@ static struct cpu_clk_suspend_context {
 } tegra114_cpu_clk_sctx;
 #endif
 
-static int periph_clk_enb_refcnt[CLK_OUT_ENB_NUM * 32];
-
 static void __iomem *clk_base;
 static void __iomem *pmc_base;
 
@@ -710,78 +706,68 @@ static unsigned long tegra114_input_freq[] = {
_clk_num, _gate_flags, _clk_id) \
TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
30, MASK(2), 0, 0, 8, 1, 0, 0,\
-   _clk_num, periph_clk_enb_refcnt, _gate_flags,\
-_clk_id, _parents##_idx, 0)
+   _clk_num,  _gate_flags, _clk_id, _parents##_idx, 0)
 
 #define TEGRA_INIT_DATA_MUX_FLAGS(_name, _con_id, _dev_id, _parents, _offset,\
_clk_num, _gate_flags, _clk_id, flags)\
TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
30, MASK(2), 0, 0, 8, 1, 0, 0, _clk_num,\
-   periph_clk_enb_refcnt, _gate_flags, _clk_id,\
-   _parents##_idx, flags)
+   _gate_flags, _clk_id, _parents##_idx, flags)
 
 #define TEGRA_INIT_DATA_MUX8(_name, _con_id, _dev_id, _parents, _offset, \
 _clk_num, _gate_flags, _clk_id)\
TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
29, MASK(3), 0, 0, 8, 1, 0, 0, _clk_num,\
-   periph_clk_enb_refcnt, _gate_flags, _clk_id,\
-   _parents##_idx, 0)
+   _gate_flags, _clk_id, _parents##_idx, 0)
 
 #define TEGRA_INIT_DATA_INT(_name, _con_id, _dev_id, _parents, _offset,
\
_clk_num, _gate_flags, _clk_id) \
TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
30, MASK(2), 0, 0, 8, 1, TEGRA_DIVIDER_INT, 0,\
-   _clk_num, periph_clk_enb_refcnt, _gate_flags,   \
-   _clk_id, _parents##_idx, 0)
+   _clk_num, _gate_flags, _clk_id, _parents##_idx, 0)
 
 #define TEGRA_INIT_DATA_INT_FLAGS(_name, _con_id, _dev_id, _parents, _offset,\
_clk_num, _gate_flags, _clk_id, flags)\
TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
30, MASK(2), 0, 0, 8, 1, TEGRA_DIVIDER_INT, 0,\
-   _clk_num, periph_clk_enb_refcnt, _gate_flags,   \
-   _clk_id, _parents##_idx, flags)
+   _clk_num,  _gate_flags, _clk_id, _parents##_idx, flags)
 
 #define TEGRA_INIT_DATA_INT8(_name, _con_id, _dev_id, _parents, _offset,\
_clk_num, _gate_flags, _clk_id) \
TEGRA_INIT_DATA_TABLE(_name, _con_id, _dev_id, _parents, _offset,\
29, MASK(3), 0, 0, 8, 1, TEGRA_DIVIDER_INT, 0,\
-   _clk_num, periph_clk_enb_refcnt, _gate_flags,   \
-   _clk_id, _parents##_idx, 0)
+   _clk_num, _gate_flags, _clk_id, _parents##_idx, 0)
 
 #define TEGRA_INIT_DATA_UART(_name, _con_id, _dev_id, _parents, _offset,\
 _clk_num, _clk_id) \
TEGRA_INIT_DATA_TABLE(_name, _con_id, 

[PATCH 01/12] clk: tegra: simplify periph clock data

[Peter De Schrijver]

This patch determines the register bank for clock enable/disable and reset
based on the clock ID instead of hardcoding it in the tables describing the
clocks. This results in less data to be maintained in the tables, making the
code easier to understand. The full benefit of the change will be realized once
also other clocktypes will be table based.

Signed-off-by: Peter De Schrijver 
---
 drivers/clk/tegra/clk-tegra114.c |  483 --
 drivers/clk/tegra/clk.c  |  105 
 drivers/clk/tegra/clk.h  |3 +
 3 files changed, 311 insertions(+), 280 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index a26e5ef..2ec3488 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -27,27 +27,10 @@
 
 #include "clk.h"
 
-#define RST_DEVICES_L  0x004
-#define RST_DEVICES_H  0x008
-#define RST_DEVICES_U  0x00C
 #define RST_DFLL_DVCO  0x2F4
-#define RST_DEVICES_V  0x358
-#define RST_DEVICES_W  0x35C
-#define RST_DEVICES_X  0x28C
-#define RST_DEVICES_SET_L  0x300
-#define RST_DEVICES_CLR_L  0x304
-#define RST_DEVICES_SET_H  0x308
-#define RST_DEVICES_CLR_H  0x30c
-#define RST_DEVICES_SET_U  0x310
-#define RST_DEVICES_CLR_U  0x314
-#define RST_DEVICES_SET_V  0x430
-#define RST_DEVICES_CLR_V  0x434
-#define RST_DEVICES_SET_W  0x438
-#define RST_DEVICES_CLR_W  0x43c
 #define CPU_FINETRIM_SELECT0x4d4   /* override default prop dlys */
 #define CPU_FINETRIM_DR0x4d8   /* rise->rise prop dly 
A */
 #define CPU_FINETRIM_R 0x4e4   /* rise->rise prop dly inc A */
-#define RST_DEVICES_NUM5
 
 /* RST_DFLL_DVCO bitfields */
 #define DVFS_DFLL_RESET_SHIFT  0
@@ -74,24 +57,6 @@
 #define CPU_FINETRIM_R_FCPU_6_SHIFT10  /* ftop */
 #define CPU_FINETRIM_R_FCPU_6_MASK (0x3 << CPU_FINETRIM_R_FCPU_6_SHIFT)
 
-#define CLK_OUT_ENB_L  0x010
-#define CLK_OUT_ENB_H  0x014
-#define CLK_OUT_ENB_U  0x018
-#define CLK_OUT_ENB_V  0x360
-#define CLK_OUT_ENB_W  0x364
-#define CLK_OUT_ENB_X  0x280
-#define CLK_OUT_ENB_SET_L  0x320
-#define CLK_OUT_ENB_CLR_L  0x324
-#define CLK_OUT_ENB_SET_H  0x328
-#define CLK_OUT_ENB_CLR_H  0x32c
-#define CLK_OUT_ENB_SET_U  0x330
-#define CLK_OUT_ENB_CLR_U  0x334
-#define CLK_OUT_ENB_SET_V  0x440
-#define CLK_OUT_ENB_CLR_V  0x444
-#define CLK_OUT_ENB_SET_W  0x448
-#define CLK_OUT_ENB_CLR_W  0x44c
-#define CLK_OUT_ENB_SET_X  0x284
-#define CLK_OUT_ENB_CLR_X  0x288
 #define CLK_OUT_ENB_NUM6
 
 #define PLLC_BASE 0x80
@@ -728,53 +693,6 @@ static struct tegra_clk_pll_params pll_re_vco_params = {
.div_nmp = _nmp,
 };
 
-/* Peripheral clock registers */
-
-static struct tegra_clk_periph_regs periph_l_regs = {
-   .enb_reg = CLK_OUT_ENB_L,
-   .enb_set_reg = CLK_OUT_ENB_SET_L,
-   .enb_clr_reg = CLK_OUT_ENB_CLR_L,
-   .rst_reg = RST_DEVICES_L,
-   .rst_set_reg = RST_DEVICES_SET_L,
-   .rst_clr_reg = RST_DEVICES_CLR_L,
-};
-
-static struct tegra_clk_periph_regs periph_h_regs = {
-   .enb_reg = CLK_OUT_ENB_H,
-   .enb_set_reg = CLK_OUT_ENB_SET_H,
-   .enb_clr_reg = CLK_OUT_ENB_CLR_H,
-   .rst_reg = RST_DEVICES_H,
-   .rst_set_reg = RST_DEVICES_SET_H,
-   .rst_clr_reg = RST_DEVICES_CLR_H,
-};
-
-static struct tegra_clk_periph_regs periph_u_regs = {
-   .enb_reg = CLK_OUT_ENB_U,
-   .enb_set_reg = CLK_OUT_ENB_SET_U,
-   .enb_clr_reg = CLK_OUT_ENB_CLR_U,
-   .rst_reg = RST_DEVICES_U,
-   .rst_set_reg = RST_DEVICES_SET_U,
-   .rst_clr_reg = RST_DEVICES_CLR_U,
-};
-
-static struct tegra_clk_periph_regs periph_v_regs = {
-   .enb_reg = CLK_OUT_ENB_V,
-   .enb_set_reg = CLK_OUT_ENB_SET_V,
-   .enb_clr_reg = CLK_OUT_ENB_CLR_V,
-   .rst_reg = RST_DEVICES_V,
-   .rst_set_reg = RST_DEVICES_SET_V,
-   .rst_clr_reg = RST_DEVICES_CLR_V,
-};
-
-static struct tegra_clk_periph_regs periph_w_regs = {
-   .enb_reg = CLK_OUT_ENB_W,
-   .enb_set_reg = CLK_OUT_ENB_SET_W,
-   .enb_clr_reg = CLK_OUT_ENB_CLR_W,
-   .rst_reg = RST_DEVICES_W,
-   .rst_set_reg = RST_DEVICES_SET_W,
-   .rst_clr_reg = RST_DEVICES_CLR_W,
-};
-
 /* possible OSC frequencies in Hz */
 static unsigned long tegra114_input_freq[] = {
[0] = 1300,
@@ -789,79 +707,79 @@ static unsigned long tegra114_input_freq[] = {
 #define MASK(x) (BIT(x) - 1)
 
 #define TEGRA_INIT_DATA_MUX(_name, _con_id, _dev_id, _parents, _offset,
\
-  

Re: [PATCH] Input: i8042 - i8042_flush fix for a full 8042 buffer

[Dmitry Torokhov]

Hi Andrey,

On Wed, Sep 18, 2013 at 04:35:56PM +0400, Andrey Moiseev wrote:
> When 8042 internal data buffer is full, the driver
> erroneously decides that the controller is not present.
> 
> I've already sent this 2 weeks ago, but that message received no comments.
> 

Sorry about the delay. How about we rework it a bit and make flush
return success/error instead of number of bytes read, like in the patch
below?

Thanks.

-- 
Dmitry

Input: i8042 - i8042_flush fix for a full 8042 buffer

From: Andrey Moiseev 

When 8042 internal data buffer is full, the driver
erroneously decides that the controller is not present.

i8042_flush returns the number of flushed bytes, which is
in 0 - I8042_BUFFER_SIZE range inclusive. Therefore, i8042_flush
has no way to indicate an error. Moreover i8042_controller_check
takes initially full buffer (i8042_flush returned
I8042_BUFFER_SIZE) as a sign of absence of the controller.

Let's change i8042 to return success/error instead and make sure
we do not return error prematurely.

Signed-off-by: Andrey Moiseev 
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/serio/i8042.c |   23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 78e4de4..52c9ebf 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -223,21 +223,26 @@ static int i8042_flush(void)
 {
unsigned long flags;
unsigned char data, str;
-   int i = 0;
+   int count = 0;
+   int retval = 0;
 
spin_lock_irqsave(_lock, flags);
 
-   while (((str = i8042_read_status()) & I8042_STR_OBF) && (i < 
I8042_BUFFER_SIZE)) {
-   udelay(50);
-   data = i8042_read_data();
-   i++;
-   dbg("%02x <- i8042 (flush, %s)\n",
-   data, str & I8042_STR_AUXDATA ? "aux" : "kbd");
+   while ((str = i8042_read_status()) & I8042_STR_OBF) {
+   if (count++ < I8042_BUFFER_SIZE) {
+   udelay(50);
+   data = i8042_read_data();
+   dbg("%02x <- i8042 (flush, %s)\n",
+   data, str & I8042_STR_AUXDATA ? "aux" : "kbd");
+   } else {
+   retval = -EIO;
+   break;
+   }
}
 
spin_unlock_irqrestore(_lock, flags);
 
-   return i;
+   return retval;
 }
 
 /*
@@ -849,7 +854,7 @@ static int __init i8042_check_aux(void)
 
 static int i8042_controller_check(void)
 {
-   if (i8042_flush() == I8042_BUFFER_SIZE) {
+   if (i8042_flush()) {
pr_err("No controller found\n");
return -ENODEV;
}

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

[PATCH 00/12] Introduce common infra for tegra clocks

[Peter De Schrijver]

This patchset introduces common infrastructure for clocks which exist in
several Tegra SoCs. We also move Tegra114 to this new infrastructure.
Tegra20 and Tegra30 will be moved later in separate patchsets.

Peter De Schrijver (12):
  clk: tegra: simplify periph clock data
  clk: tegra: periph_clk_enb_refcnt as common infra
  clk: tegra: Add TEGRA_PERIPH_NO_DIV flag
  clk: tegra: move some PLLC and PLLXC init to clk-pll.c
  clk: tegra: add header for common tegra clock IDs
  clk: tegra: add common infra for DT clocks
  clk: tegra: move audio clk to common file
  clk: tegra: move periph clocks to common file
  clk: tegra: move PMC clocks to common file
  clk: tegra: move fixed clocks to common file
  clk: tegra: introduce common tegra_osc_clk_init
  clk: tegra: introduce common gen4 super clock

 drivers/clk/tegra/Makefile   |7 +-
 drivers/clk/tegra/clk-id.h   |  197 
 drivers/clk/tegra/clk-periph.c   |9 +-
 drivers/clk/tegra/clk-pll.c  |   95 ++-
 drivers/clk/tegra/clk-tegra-audio.c  |  260 +
 drivers/clk/tegra/clk-tegra-fixed.c  |   62 ++
 drivers/clk/tegra/clk-tegra-osc.c|   81 ++
 drivers/clk/tegra/clk-tegra-periph.c |  595 
 drivers/clk/tegra/clk-tegra-pmc.c|  131 +++
 drivers/clk/tegra/clk-tegra-super-gen4.c |  220 +
 drivers/clk/tegra/clk-tegra114.c | 1547 +-
 drivers/clk/tegra/clk-tegra20.c  |   20 +-
 drivers/clk/tegra/clk-tegra30.c  |   23 +-
 drivers/clk/tegra/clk.c  |  149 +++
 drivers/clk/tegra/clk.h  |   48 +-
 15 files changed, 2080 insertions(+), 1364 deletions(-)
 create mode 100644 drivers/clk/tegra/clk-id.h
 create mode 100644 drivers/clk/tegra/clk-tegra-audio.c
 create mode 100644 drivers/clk/tegra/clk-tegra-fixed.c
 create mode 100644 drivers/clk/tegra/clk-tegra-osc.c
 create mode 100644 drivers/clk/tegra/clk-tegra-periph.c
 create mode 100644 drivers/clk/tegra/clk-tegra-pmc.c
 create mode 100644 drivers/clk/tegra/clk-tegra-super-gen4.c

-- 
1.7.7.rc0.72.g4b5ea.dirty

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

Re: [patch 0/7] improve memcg oom killer robustness v2

[Michal Hocko]

On Wed 18-09-13 16:33:06, azurIt wrote:
> > CC: "Johannes Weiner" , "Andrew Morton" 
> > , "David Rientjes" , 
> > "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" 
> > , linux...@kvack.org, 
> > cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, 
> > linux-kernel@vger.kernel.org
> >On Wed 18-09-13 16:03:04, azurIt wrote:
> >[..]
> >> I was finally able to get stack of problematic process :) I saved it
> >> two times from the same process, as Michal suggested (i wasn't able to
> >> take more). Here it is:
> >> 
> >> First (doesn't look very helpfull):
> >> [] 0x
> >
> >No it is not.
> > 
> >> Second:
> >> [] shrink_zone+0x481/0x650
> >> [] do_try_to_free_pages+0xde/0x550
> >> [] try_to_free_pages+0x9b/0x120
> >> [] free_more_memory+0x5d/0x60
> >> [] __getblk+0x14d/0x2c0
> >> [] __bread+0x13/0xc0
> >> [] ext3_get_branch+0x98/0x140
> >> [] ext3_get_blocks_handle+0xd7/0xdc0
> >> [] ext3_get_block+0xc4/0x120
> >> [] do_mpage_readpage+0x38a/0x690
> >> [] mpage_readpages+0xfb/0x160
> >> [] ext3_readpages+0x1d/0x20
> >> [] __do_page_cache_readahead+0x1c5/0x270
> >> [] ra_submit+0x21/0x30
> >> [] filemap_fault+0x380/0x4f0
> >> [] __do_fault+0x78/0x5a0
> >> [] handle_pte_fault+0x84/0x940
> >> [] handle_mm_fault+0x16a/0x320
> >> [] do_page_fault+0x13b/0x490
> >> [] page_fault+0x1f/0x30
> >> [] 0x
> >
> >This is the direct reclaim path. You are simply running out of memory
> >globaly. There is no memcg specific code in that trace.
> 
> 
> No, i'm not. Here is htop and server graphs from this case:

Bahh, right you are. I didn't look at the trace carefully. It is
free_more_memory which calls the direct reclaim shrinking.

Sorry about the confusion
-- 
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: [block:for-next 5/6] drivers/block/skd_main.c:441:3: error: implicit declaration of function 'readq'

[Jens Axboe]

On Wed, Sep 18 2013, Akhil Bhansali wrote:
> Hi Jens,
> 
> Please accept this patch that takes care of warnings related to i386 
> compilation.
> 1. Implicit function declaration of readq and writeq.
> 2. Format related warnings for VPRINTK.

You should get rid of the VPRINTK() as well, we do have debug facilities
in place you can use for printing.

And as mentioned a week or so ago, readq() isn't even used.

-- 
Jens Axboe

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

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> > gave feedback. If the sender doesn't want to take his feedback into
> > account and prefer to send pretty insulting emails instead that is his
> > choice but I would say that is this not the greatest approach to get
> > your code merged (to say the least).
> 
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
> 
> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.

Actually he called me "piece of wood with garbage in it". I guess I
have right to be offended. I'm baby in the next email. Hmm.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Full syscall argument decode in "perf trace"

[Arnaldo Carvalho de Melo]

Em Wed, Sep 18, 2013 at 01:35:13PM +0200, Denys Vlasenko escreveu:
> On 09/17/2013 09:06 PM, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Sep 17, 2013 at 05:10:55PM +0200, Denys Vlasenko escreveu:
> >> I'm trying to figure out how to extend "perf trace".
> >  
> >> Currently, it shows syscall names and arguments, and only them.
> >> Meaning that syscalls such as open(2) are shown as:
> >  
> >> open(filename: 140736118412184, flags: 0, mode: 140736118403776) = 3
> >  
> >> The problem is, of course, that user wants to see the filename
> >> per se, not the address of its first byte.
> >  
> >> To improve that, we need to fetch the pointed-to data.
> >> There are two approaches to this: extending
> >> "raw_syscalls:sys_{enter,exit}" tracepoint so that it returns this data,
> >> or selectively stopping the traced process when it reaches the thacepoint.
> > 
> > We don't want to stop the process at all, this is one of the major
> > advantages of 'perf trace' over 'strace'.
> 
> This is a worthy goal. strace is so slow exactly because it stops
> traced process so often. strace developers do want to avoid
> as many of these stops as possible.
> 
> I'm not sure that "not stopping ever" is achievable, though.
> There are cases where stopping is necessary.

Can't we try first to achieve what is possible with existing
infrastructure so that we can, out of the combo 'perf trace' and
'strace' have something that is better than plain 'strace'?

> For example, after clone() call, depending on the tracer needs,
> there may be operations which must be done on the new child
> before it is allowed to run.
> 
> strace used to use hideous, unsafe workarounds to catch children,
> until ptrace was augmented with features which made children stop
> immediately.
> 
> Do you think you can work around that? I just don't see how.

I haven't even thought about it 8-)
 
> > Look at the tmp.perf/trace2 branch in my git repo, tglx and Ingo added a
> > tracepoint to vfs_getname to use that.
> 
> I know that this is the way how to fetch syscall args without stopping,
> yes.
> 
> The problem: ~100 more tracepoints need to be added merely to get
> to the point where strace already is, wrt quality of syscall decoding.
> strace has nearly 300 separate custom syscall formatting functions,
> some of them quite complex.
> 
> If we need to add syscall stopping feature (which, as I said above,
> will be necessary anyway IMO), then syscall decoding can be as good
> as strace *already*. Then, gradually more tracepoints are added
> to make it faster.
> 
> I am thinking about going into this direction.
> 
> Therefore my question should be restated as:
> 
> Would perf developers accept the "syscall pausing" feature,
> or it won't be accepted?

Do you have some patch for us to try?

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

Re: [patch 0/7] improve memcg oom killer robustness v2

[azurIt]

> CC: "Johannes Weiner" , "Andrew Morton" 
> , "David Rientjes" , 
> "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" 
> , linux...@kvack.org, 
> cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, 
> linux-kernel@vger.kernel.org
>On Wed 18-09-13 16:03:04, azurIt wrote:
>[..]
>> I was finally able to get stack of problematic process :) I saved it
>> two times from the same process, as Michal suggested (i wasn't able to
>> take more). Here it is:
>> 
>> First (doesn't look very helpfull):
>> [] 0x
>
>No it is not.
> 
>> Second:
>> [] shrink_zone+0x481/0x650
>> [] do_try_to_free_pages+0xde/0x550
>> [] try_to_free_pages+0x9b/0x120
>> [] free_more_memory+0x5d/0x60
>> [] __getblk+0x14d/0x2c0
>> [] __bread+0x13/0xc0
>> [] ext3_get_branch+0x98/0x140
>> [] ext3_get_blocks_handle+0xd7/0xdc0
>> [] ext3_get_block+0xc4/0x120
>> [] do_mpage_readpage+0x38a/0x690
>> [] mpage_readpages+0xfb/0x160
>> [] ext3_readpages+0x1d/0x20
>> [] __do_page_cache_readahead+0x1c5/0x270
>> [] ra_submit+0x21/0x30
>> [] filemap_fault+0x380/0x4f0
>> [] __do_fault+0x78/0x5a0
>> [] handle_pte_fault+0x84/0x940
>> [] handle_mm_fault+0x16a/0x320
>> [] do_page_fault+0x13b/0x490
>> [] page_fault+0x1f/0x30
>> [] 0x
>
>This is the direct reclaim path. You are simply running out of memory
>globaly. There is no memcg specific code in that trace.


No, i'm not. Here is htop and server graphs from this case:
http://watchdog.sk/lkml/htop3.jpg (here you can see actual memory usage)
http://watchdog.sk/lkml/server01.jpg

If i was really having global OOM (which i'm not for 101%) where that i/o comes 
from? I have no swap.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] vsprintf: ignore %n again

[Kees Cook]

On Wed, Sep 18, 2013 at 6:14 AM, Tetsuo Handa
 wrote:
> Kees Cook wrote:
>> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
>> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
>> > and __vsnprintf(0, s, n, fmt, ...) otherwise.  Now,
>> > int __sprintf(int safe, char *buf, const char *fmt, ...)
>> > {
>> > va_list args;
>> > int i;
>> >
>> > va_start(args, fmt);
>> > i = __vsnprintf(safe, buf, INT_MAX, fmt, args);
>> > va_end(args);
>> >
>> > return i;
>> > }
>>
>> Unless I've misunderstood, I think we'd already get very close to this
>> with the gcc options instead. This patch set is what I've been using
>> to generate the format string fixes over the last few months, with 7
>> sent this last round:
>
> Can we utilize __builtin_constant_p() ?

This seems promising.

>
> -- source start --
> #include 
>
> #define func(fmt)   \
> if (__builtin_constant_p(fmt))  \
> printf("const : %s\n", fmt);\
> else\
> printf("not const : %s\n", fmt);\
>
>
> int main(int argc, char *argv[])
> {
> const char *fmt1 = "const char *";
> const char fmt2[] = "const char []";
> const char * const fmt3 = "const char * const";
> func("literal");
> func(fmt1);
> func(fmt2);
> func(fmt3);
> return 0;
> }
> -- source end --
>
> -- output start --
> const : literal
> not const : const char *
> not const : const char []
> const : const char * const

What version of gcc did you use? I don't get the last as const, for
some reason. And as Dan mentions, shouldn't const char[] be detected
as const too?

-Kees

> -- output end --
>
> __builtin_constant_p() seems to enforce use of either "literal" or "* const".
>
> An example change
>
> -- patch start --
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -120,8 +120,9 @@ asmlinkage int printk_emit(int facility, int level,
>const char *dict, size_t dictlen,
>const char *fmt, ...);
>
> -asmlinkage __printf(1, 2) __cold
> -int printk(const char *fmt, ...);
> +//asmlinkage __printf(1, 2) __cold
> +//int printk(const char *fmt, ...);
> +#define printk(fmt, ...) compiletime_assert(__builtin_constant_p(fmt), 
> "Non-c  onstant format string")
>
>  /*
>   * Special printk facility for scheduler use only, _DO_NOT_USE_ !
> -- patch end --
>
> caught errors like below.
>
>   CC [M]  drivers/scsi/esas2r/esas2r_log.o
> drivers/scsi/esas2r/esas2r_log.c: In function 'esas2r_log_master':
> drivers/scsi/esas2r/esas2r_log.c:174: error: call to 
> '__compiletime_assert_174' declared with attribute error: Non-constant format 
> string



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

Re: [PATCH 0/2] vsprintf: ignore %n again

[Dan Carpenter]

On Wed, Sep 18, 2013 at 05:11:04PM +0300, Dan Carpenter wrote:
>  asmlinkage __printf(1, 2) __cold
>  int printk(const char *fmt, ...);
> +#define printk(fmt, ...) do {  \
> + compiletime_assert(__builtin_constant_p(fmt), \
> +"Non-constant format string"); \
> + printk(fmt, ##__VA_ARGS__);   \
> +} while (0)

Oops...  That breaks the compile for printk.c.

Also don't we want 'const char fmt[] = "foo %s";' to be a valid format
string?

regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/10] irqdomain: Return errors from irq_create_of_mapping()

[Ralf Baechle]

On Wed, Sep 18, 2013 at 03:24:46PM +0200, Thierry Reding wrote:

For the MIPS bits:

Acked-by: Ralf Baechle 

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

Re: [patch 0/7] improve memcg oom killer robustness v2

[Michal Hocko]

On Wed 18-09-13 16:03:04, azurIt wrote:
[..]
> I was finally able to get stack of problematic process :) I saved it
> two times from the same process, as Michal suggested (i wasn't able to
> take more). Here it is:
> 
> First (doesn't look very helpfull):
> [] 0x

No it is not.
 
> Second:
> [] shrink_zone+0x481/0x650
> [] do_try_to_free_pages+0xde/0x550
> [] try_to_free_pages+0x9b/0x120
> [] free_more_memory+0x5d/0x60
> [] __getblk+0x14d/0x2c0
> [] __bread+0x13/0xc0
> [] ext3_get_branch+0x98/0x140
> [] ext3_get_blocks_handle+0xd7/0xdc0
> [] ext3_get_block+0xc4/0x120
> [] do_mpage_readpage+0x38a/0x690
> [] mpage_readpages+0xfb/0x160
> [] ext3_readpages+0x1d/0x20
> [] __do_page_cache_readahead+0x1c5/0x270
> [] ra_submit+0x21/0x30
> [] filemap_fault+0x380/0x4f0
> [] __do_fault+0x78/0x5a0
> [] handle_pte_fault+0x84/0x940
> [] handle_mm_fault+0x16a/0x320
> [] do_page_fault+0x13b/0x490
> [] page_fault+0x1f/0x30
> [] 0x

This is the direct reclaim path. You are simply running out of memory
globaly. There is no memcg specific code in that trace.
-- 
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 v2 07/10] of/irq: Propagate errors in of_irq_to_resource_table()

[Ralf Baechle]

On Wed, Sep 18, 2013 at 03:24:49PM +0200, Thierry Reding wrote:

For the MIPS bits:

Acked-by: Ralf Baechle 

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] PCI/MSI: Factor out pci_get_msi_cap() interface

[Tejun Heo]

Hello,

On Wed, Sep 18, 2013 at 11:48:00AM +0200, Alexander Gordeev wrote:
> On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
> > How about no?
> > 
> > We have a small number of MSIs available, limited by hardware &
> > firmware, if we don't impose a quota then the first device that probes
> > will get most/all of the MSIs and other devices miss out.
> 
> Out of curiosity - how pSeries has had done it without quotas before
> 448e2ca ("powerpc/pseries: Implement a quota system for MSIs")?

Hmmm... do we need to treat this any differently?  If the platform
can't allocate full range of requested MSIs, just failing should be
enough regardless of why such allocation can't be met, no?

> > Anyway I don't see what problem you're trying to solve? I agree the
> > -ve/0/+ve return value pattern is ugly, but it's hardly the end of the
> > world.
> 
> Well, the interface recently has been re-classified from "ugly" to
> "unnecessarily complex and actively harmful" in Tejun's words ;)

LOL. :)

> Indeed, I checked most of the drivers and it is incredible how people
> are creative in misusing the interface: from innocent pci_disable_msix()
> calls when if pci_enable_msix() failed to assuming MSI-Xs were enabled
> if pci_enable_msix() returned a positive value (apparently untested).
> 
> Roughly third of the drivers just do not care and bail out once
> pci_enable_msix() has not succeeded. Not sure how many of these are
> mandated by the hardware.

Yeah, I mean, this type of interface is a trap.  People have to
actively resist to avoid doing silly stuff which is a lot to ask.

>   /*
>* Retrieving 'nvec' by means other than pci_msix_table_size()
>*/
> 
>   rc = pci_get_msix_limit(pdev);
>   if (rc < 0)
>   return rc;
> 
>   /*
>* nvec = min(rc, nvec);
>*/
> 
>   for (i = 0; i < nvec; i++)
>   msix_entry[i].entry = i;
> 
>   rc = pci_enable_msix(pdev, msix_entry, nvec);
>   if (rc)
>   return rc;

I really think what we should do is

* Determine the number of MSIs the controller wants.  Don't worry
  about quotas or limits or anything.  Just determine the number
  necessary to enable enhanced interrupt handling.

* Try allocating that number of MSIs.  If it fails, then just revert
  to single interrupt mode.  It's not the end of the world and mostly
  guaranteed to work.  Let's please not even try to do partial
  multiple interrupts.  I really don't think it's worth the risk or
  complexity.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dwc3: core: clarify usb-phy array binding

[Felipe Balbi]

Hi,

On Wed, Aug 28, 2013 at 05:01:51PM +0100, Mark Rutland wrote:
> > > So it's not physically possible for someone to just wire up a single phy
> > > to the device, either USB2-only or USB3?
> > 
> > of course it is :-) In fact, TI has done it. But it causes a whole bunch
> > of other problems to support that sort of model. For one, in some
> > systems, a clock generated by the USB3 PHY is backfed into the IP and if
> > USB3 PHY isn't running, the dwc3 IP won't start.
> 
> That sounds like a mess. But unless I've misunderstood, that doesn't

well, it is :-)

> sound like a general problem with having one phy, but rather an
> integration issue on a specific system? Presumably in that case as long
> as the phy was brought up before poking the rest of the IP, the unit
> would function correctly.

right, but what 'brings up' the PHY is usb_phy_init(). If we don't add
usb3phy to DTS or skip usb3phy in case maximum-speed < superspeed, then
we're screwed :-)

> > I even wrote a patch making USB3 PHY optional, but didn't push it
> > exactly because it broke some other systems and I can't guarantee users
> > won't mess up their DTS/pdata.
> 
> Does that mean that their dts or pdata are wrong at the moment, but
> they're spared because the driver bails out due to a missing phy? If
> their pdata's wrong, that should be fixable relatively easily, but if
> the dt is wrong then I'm not sure how we can support those systems
> sensibly. That sounds like an ideal candidate for a dt quirks
> mechanism...

hmm, the idea of the patch was:

switch (maximum-speed) {
case SUPER:
grab_and_initialize_usb3_phy();
grab_and_initialize_usb2_phy();
break;
case HIGH:
case FULL:
case LOW:
grab_and_initialize_usb2_phy();
break;
}

now, imagine someone wants to run his dwc3 in highspeed mode, we
wouldn't initialize USB3 PHY which could cause the whole IP to break.

I tried poking around on device's registers to see if there was any way
to detect that the IP needs somethin back from USB3 PHY, but couldn't
find anything.

Since we can't know how the IP was integrated, it's best to leave it
alone and require NOP xceiv to be used.

> > > You can describe the USB2-only case in the dt by only listing the first
> > > phy (though the driver won't support it as it expects both to be
> > > present), but it's impossible to describe that you've wired up a single
> > > phy that's USB3 capable.
> > 
> > you might be right there...
> 
> Would it be possible to have something like (an optional) usb-phy-names?
> If not present, we assume the current situation, if present then we use
> it to figure out which phys are present. Maybe I'm missing something
> that makes that impossible?

you're missing the point regarding the IP possibly needing something
back from the PHY (e.g. a clock which PHY generates).

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> >> >> > So will you do that? Or it is needed to resend this one line
> >> >> > hunk again in new email again?
> >> >>
> >> >> new patch, new email
> >> >
> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >> >
> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
> >> > another is hassling. So what you want from me? Do all those non
> >> > sense working only because yesterday you had bad day? Or what?
...
> > Actually, there is need to be rude, because Felipe fails to act as
> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
> > patches, points people to random READMEs and wastes everyones time.
> 
> I don't know what are you talking about (if that happened in another
> thread then I need more context). Felipe is not bouncing any bugfix

Take a look here:

https://lkml.org/lkml/2013/9/17/286

I clearly state that patch can not be tested as required for "proper"
submission, but offer patch anyway. I get irrelevant boilerplate on
patch format.

> but just asked to split the patch in two since the patch was solving
> two separate issues so is way better to have it in two separate
> patches for the reasons I explained before.
> 
> So, as far as I can tell Felipe did exactly what I would expect from a
> maintainer. He took the time to review the patches sent to him and

I'd expect maintainer to, well, maintain code. It means actually
fixing bugs in his code, when he's pointed at them.

> gave feedback. If the sender doesn't want to take his feedback into
> account and prefer to send pretty insulting emails instead that is his
> choice but I would say that is this not the greatest approach to get
> your code merged (to say the least).

Clearly not. But Pali found bug in code Felipe should
maintain. Instead of "thank you for bug report, I applied this one
line of your code to fix it", Pali got "new patch, new email" for his
efforts. That is how you train dogs, not how you should treat kernel
contributors.

Now, it is possible that Felipe just has problems with english, as he
called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
he appears more arogant than usual over email.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] perf tools: New comm infrastructure

[Arnaldo Carvalho de Melo]

Em Tue, Sep 17, 2013 at 02:54:22PM +0900, Namhyung Kim escreveu:
> Hi Ingo,
> 
> On Sat, 14 Sep 2013 08:11:49 +0200, Ingo Molnar wrote:
> > * Frederic Weisbecker  wrote:
> >> My patches and Namhyung's should improve the comm situation a lot but we 
> >> can't do much miracle. The only way would be perhaps to be able to limit 
> >> the deepness of the callchain branches.
> >> 
> >> Now may be we can find other big contention point in perf. It's possible 
> >> we also have some endless loop somewhere.
> >
> > Well, it was the 100,000+ step linear list walk that was causing 90% of 
> > the slowness here. Namhyung's patch should dramatically improve that. I 
> > guess time for someone to post a combined tree so that it can be tested 
> > all together?
> 
> I pushed combined tree to 'perf/callchain-v2' branch in my tree
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

But you did it for some old tree, as I tried running it now and since my
big perf.data file has PERF_RECORD_MMAP2 records, I can't try it with
your branch, working on cherry picking those changesets, since a plain
rebase didn't work.

- Arnaldo
 
> 
> Please note that I also pushed other versions (v[1-3]).  The v1 is my
> previous rbtree conversion patch, v2 adds Frederic's new comm
> infrastructure series on top and v3 adds my revised patch to refer
> current comm [1] on top of v2.
> 
> I did my own test again among them.  Test data is 400MB perf.data file
> created by parallel kernel build.
> 
>   $ ls -lh perf.data.big
>   -rw---. 1 namhyung namhyung 400M Sep  9 10:21 perf.data.big
> 
> For more precise result, I changed cpufreq governor to 'performance'
> 
>   # echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
> 
> and run perf report on the cpu.
> 
>   $ taskset -c 3 time -p perf --no-pager report --stdio -i perf.data.big > 
> /dev/null
> 
> I ran it multiple times for each case and the results did not vary much.
> 
> baseline  v1v2  v3
>   --
>   real380.17   12.63 10.029.03
>   user378.86   11.95  9.668.69
>   sys   0.700.65  0.330.34
> 
> 
> I also tried to cache latest result and reuse it when adding a callchain
> (in callchain_append() function) but it only hits ~5% and did not help
> the performance.
> 
> Thanks,
> Namhyung
> 
> 
> [1] https://lkml.org/lkml/2013/9/16/565
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 06/16] hwmon: tmp102: expose to thermal fw via DT nodes

[Eduardo Valentin]

On 18-09-2013 07:06, Guenter Roeck wrote:
> On Tue, Sep 17, 2013 at 06:34:05PM -0400, Eduardo Valentin wrote:
>> This patch adds to tmp102 temperature sensor the possibility
>> to expose itself as thermal zone device, registered on the
>> thermal framework.
>>
>> The thermal zone is built only if a device tree node
>> describing a thermal zone for this sensor is present
>> inside the tmp102 DT node. Otherwise, the driver behavior
>> will be the same.
>>
>> Cc: Jean Delvare 
>> Cc: Guenter Roeck 
>> Cc: lm-sens...@lm-sensors.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Eduardo Valentin 
>> ---
>>  drivers/hwmon/tmp102.c | 20 
>>  1 file changed, 20 insertions(+)
>>
>> ---
>>
>> Guenter,
>>
>> Here is a version without the warnings, as requested.
>>
>> Eduardo
>>
>> diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
>> index d7b47ab..dc96598 100644
>> --- a/drivers/hwmon/tmp102.c
>> +++ b/drivers/hwmon/tmp102.c
>> @@ -27,6 +27,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  
>>  #define DRIVER_NAME "tmp102"
>>  
>> @@ -50,6 +52,7 @@
>>  
>>  struct tmp102 {
>>  struct device *hwmon_dev;
>> +struct thermal_zone_device *tz;
>>  struct mutex lock;
>>  u16 config_orig;
>>  unsigned long last_update;
>> @@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct 
>> i2c_client *client)
>>  return tmp102;
>>  }
>>  
>> +static int tmp102_read_temp(void *dev, long *temp)
>> +{
>> +struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
>> +
>> +*temp = tmp102->temp[0];
>> +
>> +return 0;
>> +}
>> +
>>  static ssize_t tmp102_show_temp(struct device *dev,
>>  struct device_attribute *attr,
>>  char *buf)
>> @@ -204,6 +216,12 @@ static int tmp102_probe(struct i2c_client *client,
>>  goto fail_remove_sysfs;
>>  }
>>  
>> +tmp102->tz = thermal_zone_of_sensor_register(>dev, 0,
>> + >dev,
>> + tmp102_read_temp, NULL);
>> +if (IS_ERR(tmp102->tz))
>> +tmp102->tz = NULL;
>> +
>>  dev_info(>dev, "initialized\n");
>>  
>>  return 0;
>> @@ -220,6 +238,8 @@ static int tmp102_remove(struct i2c_client *client)
>>  {
>>  struct tmp102 *tmp102 = i2c_get_clientdata(client);
>>  
>> +/* thermal zone life cycle is not our responsibility */
> 
> This comment does not provide any value. Please drop it from both drivers.
> Sorry I missed that earlier.

Yeah, I even forgot to drop it myself. No problem, I am resending both
without it.

> 
>> +thermal_zone_of_sensor_unregister(>dev, tmp102->tz);
>>  hwmon_device_unregister(tmp102->hwmon_dev);
>>  sysfs_remove_group(>dev.kobj, _attr_group);
>>  
>> -- 
>> 1.8.2.1.342.gfa7285d
>>
>>
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin



signature.asc
Description: OpenPGP digital signature

Re: KSZ8051 breakage

[Marek Vasut]

Dear Alexandre Pereira da Silva,

> Hi,
> 
> The commit
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/driv
> ers/net/phy/micrel.c?id=b818d1a7f72575eef17e00dc4085512c9cc8897dbreaks
> KSZ8051MNL phy
> 
> Micrel gone wrong here. The PHY ID of KSZ8051 is the same as KSZ8031, even
> the revision code matches.
> 
> In my custom board, I cannot run these instructions or else my cpu will
> lock up:
> const u16 val = KSZPHY_OMSO_B_CAST_OFF | KSZPHY_OMSO_RMII_OVERRIDE;
> phy_write(phydev, MII_KSZPHY_OMSO, val);
> 
> This is a board property and not a phy one. Ideally, the phy should be
> correctly strapped at the hardware level for the board in question, so no
> changes in this registers should be needed.
> 
> I think we could add a OF property to set these options, what do you think?
> If that, I would also propose to convert the 50MHZ flag to OF as well.
> 
> Other option is to handle this the same way as the 50MHZ flag, that is
> being set by board code.

I wouldn't mind, but we should use something generic the other PHYs can use as 
well.

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:perf/core] perf: Fix broken union in ' struct perf_event_mmap_page'

[Vince Weaver]

On Wed, 18 Sep 2013, Peter Zijlstra wrote:

> > This patch somehow breaks the perf-ABI.
> 
> Difficult call that..

OK, let me rephrase.

This change broke existing working code.

Can you point to any code that is fixed by the commit?

If not, I think the rule is you revert the changeset.

Or you can just mark the bug "Won't fix, perf tool doesn't use it" I guess

You guys told me to start running my tests in -rc1 so I can catch bugs 
early enough to fix things.  So here I am, finding a problem in -rc1.
If no one cares I'll stop bothering and go back to just documenting the 
problems after the fact in complaining webpages.

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ti_am335x_adc: Add continuous sampling support

[Dmitry Torokhov]

On Wed, Sep 18, 2013 at 10:39:42AM +0100, Jonathan Cameron wrote:
> 
> 
> "Zubair Lutfullah :"  wrote:
> >On Tue, Sep 17, 2013 at 09:27:27PM -0700, Dmitry Torokhov wrote:
> >> Hi Zubair,
> >> 
> >> On Tue, Sep 17, 2013 at 09:44:07AM +0500, Zubair Lutfullah wrote:
> >> > +
> >> > +ret = devm_request_threaded_irq(indio_dev->dev.parent,
> >> > +irq,
> >> > +pollfunc_th, pollfunc_bh,
> >> > +flags, indio_dev->name,
> >> > +indio_dev);
> >> > +if (ret)
> >> > +goto error_kfifo_free;
> >> > +
> >> > +indio_dev->setup_ops = setup_ops;
> >> > +indio_dev->modes |= INDIO_BUFFER_HARDWARE;
> >> > +
> >> > +ret = iio_buffer_register(indio_dev,
> >> > +  indio_dev->channels,
> >> > +  indio_dev->num_channels);
> >> > +if (ret)
> >> > +goto error_free_irq;
> >> > +
> >> > +return 0;
> >> > +
> >> > +error_free_irq:
> >> > +devm_free_irq(indio_dev->dev.parent, irq, indio_dev);
> >> 
> >> What is the point of using devm_* here if you are doing explicit
> >> management of the resource anyway (you explicitly release it in all
> >code
> >> paths)?
> >> 
> >> Thanks.
> >> 
> >> -- 
> >> Dmitry
> >
> >I admit I am unaware at the moment about how it works.
> >
> >I use devm and simply ignore the error path?
> >
> >The devm function header description said something about using
> >devm_free when freeing. And this is the way I am used to seeing 
> >error handling.
> 

> The devm interfaces ensure this is all cleaned when the device is
> removed thus avoiding the need to free the stuff explicitly.  Device
> will get freed on deliberate remove and on an error from probe. Hence
> you can drop all calls to devm free. The devm free functions are only
> needed if you wish to free in order to reallocate. This might happen
> if you want to change a buffer size for instance.

However in this case such conversion us dangerous. With all but IRQ
resource managed by the traditional methods they will be released first
with IRQ handler deregistered very last. Therefore if device is not
properly quiesced IRQ raised during driver unbinding is likely to result
in kernel oops.

IOW devm_request_irq() is very often evil (it is still useful if _all_
your resources are managed by devm_*).

In case of your driver I'd recommend switching to
request_irq()/free_irq() instead.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ADP1653 board code for Nokia RX-51

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 1:50 AM, Tony Lindgren  wrote:
> * Aaro Koskinen  [130907 16:10]:
>> Hi,
>>
>> On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote:
>> > > --- /dev/null
>> > > +++ b/arch/arm/mach-omap2/board-rx51-camera.c
>> [...]
>> > Ping, can you review this patch v2?
>>
>> I don't think Tony will accept any new board stuff for RX-51/N900.
>> See for example: http://marc.info/?l=linux-kernel=137629626213187=2
>>
>> There should be initial Nokia N900 DTS file in 3.12-rc1, and we should
>> continue converting this board fully to DT.
>
> Yes let's plan on making mach-omap2 to be DT only soonish.
> AFAIK the only stopper right now for omap3 are the pending
> pinctrl changes for the wake-up events as otherwise we would
> have sever PM regressions with off-idle.
>

Hi Tony,

I don't know if OMAP2+ DT will happen soon as you said. At least I
know about a big issue we had with GPIO pins not being auto-requested
when are mapped as IRQ. You can refer to [1] for the latest approach
and how this discussion have been going.

This is something that we have been trying to solve for a couple of
kernel releases by now so it would be great if you can join the
discussion.

> Regards,
>
> Tony

Thanks a lot and best regards,
Javier

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

Re: [PATCH 0/2] vsprintf: ignore %n again

[Dan Carpenter]

Sure.  There are a lot of non-const strings though.

diff --git a/include/linux/printk.h b/include/linux/printk.h
index e6131a78..317587b 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -122,6 +122,11 @@ asmlinkage int printk_emit(int facility, int level,
 
 asmlinkage __printf(1, 2) __cold
 int printk(const char *fmt, ...);
+#define printk(fmt, ...) do {\
+   compiletime_assert(__builtin_constant_p(fmt), \
+  "Non-constant format string"); \
+   printk(fmt, ##__VA_ARGS__);   \
+} while (0)
 
 /*
  * Special printk facility for scheduler use only, _DO_NOT_USE_ !
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Fix style in s3c-hsotg.c

[Felipe Balbi]

Hi,

On Wed, Sep 18, 2013 at 11:20:27AM +0200, Pavel Machek wrote:
> On Tue 2013-09-17 20:45:39, Felipe Balbi wrote:
> > On Wed, Sep 18, 2013 at 12:04:27AM +0200, Pavel Machek wrote:
> > > On Tue 2013-09-17 10:42:30, Felipe Balbi wrote:
> > > > Hi,
> > > > 
> > > > On Mon, Sep 02, 2013 at 03:58:32PM +0200, Pavel Machek wrote:
> > > > > Hi!
> > > > > 
> > > > > checkpatch.pl has some valid complaints about style in s3c-hsotg.c :
> > > > > macro with if should be really enclosed in do {} while, and puts is
> > > > > going to be slightly faster.
> > > > > 
> > > > > Here's suggested patch. I don't have the hardware, so it is completely
> > > > > untested.
> > > > > 
> > > > > Signed-off-by: Pavel Machek, 
> > > > 
> > > > this is not how you send a patch, please read
> > > > Documentation/SubmittingPatches
> > > 
> > > Have you considered possibility that this is how you nudge maintainer
> > > into fix their coding style?
> > 
> > cute...
> > 
> > Seriously though, read that file, you're commit log has garbage in it
> > which shouldn't go to git history.
> 
> Run git log on SubmittingPatches.
> 
> Then, instead of telling me what to read, run checkpatch on your
> files. You can either fix them yourself, or use my patch as a
> basis. Note there's missing } or something, so it probably will not
> compile, see the other mail. So you actually will have to modify that
> patch. Stripping "Hi!" from it should not be that hard, neither should
> be stripping note that patch is untested when you actually test
> it. And as you are the maintainer, it is your job.

you misunderstand the work of maintainers. Our work is not to fix you
crappy patches. If we start allowing crappy patches, we'd be fixing your
nonsense forever and linux wouldn't move.

> No, I'll not polish patch for hardware I don't have and have little
> interest in.  wanted to help you, but according to your first reply,
> you do not really want help.

that's your call. Now how about you stop being such a baby and go fix
your mistakes to start with ? Just because I'm the maintainer of the
gadget framework, doesn't mean I'm the maintainer of s3c-hsotc.c file.
Maintainer != author too, btw.

Anyway, I got much better stuff to do than babysitting grown ups.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [tip:perf/core] perf: Fix broken union in ' struct perf_event_mmap_page'

[Vince Weaver]

On Wed, 18 Sep 2013, Adrian Hunter wrote:

> On 17/09/13 23:23, Vince Weaver wrote:
> > 
> > This patch somehow breaks the perf-ABI.
> > 
> > If I take a program that reads "mmap->cap_usr_rdpmc" and compile it
> > against the new header with this change (say from 3.12-rc1)
> > and then run it on an old kernel (say 3.11) then I get "0" for
> > cap_usr_rdpmc.
> > 
> > If I take the same program and recompile against the old (without this 
> > patch) header and run it on 3.11, I get the expected "1" value.
> > 
> > So something about this changed the bit pattern in an incompatible 
> > fashion.
> 
> 
> cap_usr_time and cap_usr_rdpmc were occupying the same bit position i.e. bit 0
> 
> That means that cap_usr_time and cap_usr_rdpmc were both unreliable.

well then I have to say this patch wins today's award for "least 
useful commit message".  Why wasn't this important info there?
>From what it originally sounded like this was just some shuffling of
low-level C minutia, not a hard-to-resolve break in the perf ABI.

> Possible improvements are one or both of:
> 1. Add cap_usr_fixed to identify kernels that have the capabilities bits fixed
> 2. Swap the positions of cap_usr_time and cap_usr_rdpmc so that
> cap_usr_rdpmc remains in bit 0

Or just create two new fields and mark the old ones as obsolete somehow.

The problem with just making this change silently is now tools like PAPI 
that care about cap_usr_rdpmc will behave in hard-to-debug ways.

For example, code compiled against new headers but run with old kernels 
won't detect rdpmc properly

Code compiled against old headers but run with new kernels won't detect 
rdpmc properly.

It's true existing code could have problems if you ran on a machine with 
conflicting rdpmc/usr_time, but my tests never noticed that, presumably 
because rdpmc and usr_time were added at the same time (in 3.4), x86 
always enables rdpmc, and none of my code uses usr_time so I never see 
wrong time results.

Vince

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: Support for Openembedded/Yocto -dbg packages

[Arnaldo Carvalho de Melo]

Em Wed, Sep 18, 2013 at 03:29:03PM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo  wrote:
> > Em Wed, Sep 18, 2013 at 12:18:01PM +0200, Peter Zijlstra escreveu:
> > > len += snprintf(str + len, size - len, ...);
> > > len += snprintf(str + len, size - len, ...);

> > And avoid snprintf like the plague, use scnprintf instead...  See
> > e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 for details :-)

> Hm, could we do:

>   #define snprintf scnprintf
> or:
>   #define snprintf(x...) BUILD_BUG()
> ?

Yes, I prefer the later, with a short explanation, will do.

- Arnaldo
 
> I don't think there's any valid code, except printf wrappers (which we 
> don't have in perf), where the semantics of snprintf() would be needed.
> 
> 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 1/6] hardirq: Make hardirq bits generic

[Thomas Gleixner]

On Tue, 17 Sep 2013, Thomas Gleixner wrote:

> On Tue, 17 Sep 2013, Geert Uytterhoeven wrote:
> 
> > On Tue, Sep 17, 2013 at 8:53 PM, Thomas Gleixner  wrote:
> > > --- linux-2.6.orig/arch/m68k/include/asm/hardirq.h
> > > +++ linux-2.6/arch/m68k/include/asm/hardirq.h
> > > @@ -5,17 +5,6 @@
> > >  #include 
> > >  #include 
> > >
> > > -#define HARDIRQ_BITS   8
> > 
> > > --- linux-2.6.orig/include/linux/preempt_mask.h
> > > +++ linux-2.6/include/linux/preempt_mask.h
> > > @@ -11,36 +11,22 @@
> > >   * - bits 0-7 are the preemption count (max preemption depth: 256)
> > >   * - bits 8-15 are the softirq count (max # of softirqs: 256)
> > >   *
> > > - * The hardirq count can in theory reach the same as NR_IRQS.
> > > - * In reality, the number of nested IRQS is limited to the stack
> > > - * size as well. For archs with over 1000 IRQS it is not practical
> > > - * to expect that they will all nest. We give a max of 10 bits for
> > > - * hardirq nesting. An arch may choose to give less than 10 bits.
> > > - * m68k expects it to be 8.
> > 
> > m68k needs some changes in arch/m68k/kernel/entry.S, cfr. this check
> > in arch/m68k/kernel/ints.c:
> > 
> > /* assembly irq entry code relies on this... */
> > if (HARDIRQ_MASK != 0x00ff) {
> > extern void hardirq_mask_is_broken(void);
> > hardirq_mask_is_broken();
> > }
> > 
> > Haven't looked into the details yet...
> 
> Whee. Did not notice that one. Though I can't find anything
> interesting in the low level entry code... Looks like some more
> histerical left overs.

Duh. With brain awake I can see it.

The low level entry code is fiddling with preempt_count by adding
HARDIRQ_OFFSET to it to keep track of nested interrupts. If the count
goes to 0, it invokes do_softirq(). And you have another safety guard:

ret_from_last_interrupt:
moveq   #(~ALLOWINT>>8)&0xff,%d0
andb%sp@(PT_OFF_SR),%d0
jne 2b

That's due to the irq priority level stuff, which results in nested
interrupts depending on the level of the serviced interrupt, right?
And that's why you fiddle yourself with the HARDIRQ bits in the
preempt count to prevent the core code from calling do_softirq().

Though this scheme also prevents that other parts of irq_exit() are
working correctly, because they depend on the hardirq count being
zero, e.g. the nohz code.

Needs more thoughts how to fix that w/o wasting precious bits for the
HARDIRQ count.

Thanks,

tglx










--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] modpost: Fix secondary errors seen if a single module build fails

[Guenter Roeck]

On Tue, Sep 17, 2013 at 02:34:58PM +0200, Michal Marek wrote:
> Dne 15.9.2013 06:39, Guenter Roeck napsal(a):
> > Commit ea4054a23 (modpost: handle huge numbers of modules) added
> > support for building a large number of modules.
> > 
> > Unfortunately, the commit changed the semantics of the makefile: Instead of
> > passing only existing object files to modpost, make now passes all expected
> > object files. If make was started with option -i, this results in a modpost
> > error if a single file failed to build.
> > 
> > Example with the current btrfs build falure on m68k:
> > 
> > fs/btrfs/btrfs.o: No such file or directory
> > make[1]: [__modpost] Error 1 (ignored)
> > 
> > This error is followed by lots of errors such as:
> > 
> > m68k-linux-gcc: error: arch/m68k/emu/nfcon.mod.c: No such file or directory
> > m68k-linux-gcc: fatal error: no input files
> > compilation terminated.
> > make[1]: [arch/m68k/emu/nfcon.mod.o] Error 1 (ignored)
> > 
> > This doesn't matter much for normal builds, but it is annoying for builds
> > started with "make -i" due to the large number of secondary errors.
> > Those errors unnececessarily clog any error log and make it difficult
> > to find the real errors in the build.
> > 
> > Fix the problem by only passing existing object files to modpost.
> > 
> > Cc: Rusty Russell 
> > Signed-off-by: Guenter Roeck 
> > ---
> >  scripts/Makefile.modpost |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
> > index 8dcdca2..387c806 100644
> > --- a/scripts/Makefile.modpost
> > +++ b/scripts/Makefile.modpost
> > @@ -81,7 +81,8 @@ modpost = scripts/mod/modpost\
> >  
> >  # We can go over command line length here, so be careful.
> >  quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) 
> > modules
> > -  cmd_modpost = $(MODLISTCMD) | sed 's/\.ko$$/.o/' | $(modpost) -s -T -
> > +  cmd_modpost = $(MODLISTCMD) | sed 's/\.ko$$/.o/' | \
> > +   while read a; do [ -f $$a ] && echo $$a; done | $(modpost) -s -T -
> 
> Can you do this filtering only if make -i is used ('i' is present in
> $(MAKEFLAGS)), to not hide potential buildsystem bugs? Regarding shell
> loop vs. ls, maybe the cleanest way would be to add an option to modpost
> to ignore missing files.
> 
To follow up on this - are you at the Linux Plumbers conference ?
If yes maybe we can meet briefly and discuss how to proceed.
I'd volunteer to create a patch to add the above functionality if
people think it is valuable, but I would like to keep it as
separate patch.

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

Re: [patch 0/7] improve memcg oom killer robustness v2

[azurIt]

> CC: "Johannes Weiner" , "Andrew Morton" 
> , "David Rientjes" , 
> "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro" 
> , linux...@kvack.org, 
> cgro...@vger.kernel.org, x...@kernel.org, linux-a...@vger.kernel.org, 
> linux-kernel@vger.kernel.org
>On Tue 17-09-13 13:15:35, azurIt wrote:
>[...]
>> Is something unusual on this stack?
>> 
>> 
>> [] dump_header+0x7e/0x1e0
>> [] ? find_lock_task_mm+0x2f/0x70
>> [] oom_kill_process+0x85/0x2a0
>> [] mem_cgroup_out_of_memory+0xa8/0xf0
>> [] mem_cgroup_oom_synchronize+0x2e6/0x310
>> [] ? mem_cgroup_uncharge_page+0x40/0x40
>> [] pagefault_out_of_memory+0x13/0x130
>> [] mm_fault_error+0x9e/0x150
>> [] do_page_fault+0x404/0x490
>> [] ? do_mmap_pgoff+0x3dc/0x430
>> [] page_fault+0x1f/0x30
>
>This is a regular memcg OOM killer. Which dumps messages about what is
>going to do. So no, nothing unusual, except if it was like that for ever
>which would mean that oom_kill_process is in the endless loop. But a
>single stack doesn't tell us much.
>
>Just a note. When you see something hogging a cpu and you are not sure
>whether it might be in an endless loop inside the kernel it makes sense
>to take several snaphosts of the stack trace and see if it changes. If
>not and the process is not sleeping (there is no schedule on the trace)
>then it might be looping somewhere waiting for Godot. If it is sleeping
>then it is slightly harder because you would have to identify what it is
>waiting for which requires to know a deeper context.
>-- 
>Michal Hocko
>SUSE Labs



I was finally able to get stack of problematic process :) I saved it two times 
from the same process, as Michal suggested (i wasn't able to take more). Here 
it is:

First (doesn't look very helpfull):
[] 0x


Second:
[] shrink_zone+0x481/0x650
[] do_try_to_free_pages+0xde/0x550
[] try_to_free_pages+0x9b/0x120
[] free_more_memory+0x5d/0x60
[] __getblk+0x14d/0x2c0
[] __bread+0x13/0xc0
[] ext3_get_branch+0x98/0x140
[] ext3_get_blocks_handle+0xd7/0xdc0
[] ext3_get_block+0xc4/0x120
[] do_mpage_readpage+0x38a/0x690
[] mpage_readpages+0xfb/0x160
[] ext3_readpages+0x1d/0x20
[] __do_page_cache_readahead+0x1c5/0x270
[] ra_submit+0x21/0x30
[] filemap_fault+0x380/0x4f0
[] __do_fault+0x78/0x5a0
[] handle_pte_fault+0x84/0x940
[] handle_mm_fault+0x16a/0x320
[] do_page_fault+0x13b/0x490
[] page_fault+0x1f/0x30
[] 0x


What do you think about it?

azur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: Support for Openembedded/Yocto -dbg packages

[Ricardo Ribalda Delgado]

Hello Ingo Arnaldo and Peter

I have just posted v3,

Thanks for your comments!

On Wed, Sep 18, 2013 at 3:29 PM, Ingo Molnar  wrote:
>
> * Arnaldo Carvalho de Melo  wrote:
>
>> Em Wed, Sep 18, 2013 at 12:18:01PM +0200, Peter Zijlstra escreveu:
>> > On Wed, Sep 18, 2013 at 12:02:12PM +0200, Ricardo Ribalda Delgado wrote:
>> > > Perhaps this is even more clear than v2:
>>
>> > > len = snprintf(file, size, "%s", symbol_conf.symfs);
>> > > size -= len;
>> > > file += len;
>> > > len = snprintf(file, MIN(size,(last_slash - dso->long_name) + 2),
>> > > "%s",  dso->long_name);
>> > > size -= len;
>> > > file += len;
>> > > len = snprintf(file, size, ".debug%s",  last_slash);
>>
>> > len = 0;
>>
>> > len += snprintf(str + len, size - len, ...);
>> > len += snprintf(str + len, size - len, ...);
>>
>> And avoid snprintf like the plague, use scnprintf instead...  See
>> e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 for details :-)
>
> Hm, could we do:
>
> #define snprintf scnprintf
>
> or:
>
> #define snprintf(x...) BUILD_BUG()
>
> ?
>
> I don't think there's any valid code, except printf wrappers (which we
> don't have in perf), where the semantics of snprintf() would be needed.
>
> Thanks,
>
> Ingo



-- 
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ti_am335x_adc: Add continuous sampling support

[Jonathan Cameron]

On 18/09/13 12:23, Zubair Lutfullah wrote:

Previously the driver had only one-shot reading functionality.
This patch adds continuous sampling support to the driver.

Continuous sampling starts when buffer is enabled.
HW IRQ wakes worker thread that pushes samples to userspace.
Sampling stops when buffer is disabled by userspace.

Patil Rachna (TI) laid the ground work for ADC HW register access.
Russ Dill (TI) fixed bugs in the driver relevant to FIFOs and IRQs.

I fixed channel scanning so multiple ADC channels can be read
simultaneously and pushed to userspace.
Restructured the driver to fit IIO ABI.
And added INDIO_BUFFER_HARDWARE mode.

Signed-off-by: Zubair Lutfullah 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Russ Dill 
Acked-by: Lee Jones 
Acked-by: Sebastian Andrzej Siewior 


Very very nearly there. Couple of suggestions in-line.
(about 30 seconds work + testing ;)

I'm still unsure of why we need 32bit storage in the fifo
for the data.  I've proposed the changes I'd make to put it in 16 bit
storage inline.  The fact that the device is working in 32bits
is irrelevant given we only have a 12 bit number coming out and
it is in 12 least significant bits.  I guess there might be a tiny
cost in doing the conversion, but you kfifo will be half the size
as a result and that seems more likely to a worthwhile gain!

Out of interest, are you testing this with generic_buffer.c?
If so, what changes were necessary?  Given this driver will not
have a trigger it would be nice to update that example code to handle
that case if it doesn't already.

Thanks,

Jonathan



---
  drivers/iio/adc/ti_am335x_adc.c  |  216 +-
  include/linux/mfd/ti_am335x_tscadc.h |9 ++
  2 files changed, 220 insertions(+), 5 deletions(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index a952538..b4b2ea0 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -28,12 +28,19 @@
  #include 

  #include 
+#include 
+#include 
+#include 
+#include 
+#include 

  struct tiadc_device {
struct ti_tscadc_dev *mfd_tscadc;
int channels;
u8 channel_line[8];
u8 channel_step[8];
+   int buffer_en_ch_steps;
+   u32 *data;

u16 *data;

Also it might actually save memory to simply have a fixed size array of 
the maximum size used here and avoid the extra allocations for the cost

of 16 bytes in here.

Hence,

u16 data[8];

  };

  static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
@@ -56,8 +63,14 @@ static u32 get_adc_step_mask(struct tiadc_device *adc_dev)
return step_en;
  }

-static void tiadc_step_config(struct tiadc_device *adc_dev)
+static u32 get_adc_step_bit(struct tiadc_device *adc_dev, int chan)
  {
+   return 1 << adc_dev->channel_step[chan];
+}
+
+static void tiadc_step_config(struct iio_dev *indio_dev)
+{
+   struct tiadc_device *adc_dev = iio_priv(indio_dev);
unsigned int stepconfig;
int i, steps;

@@ -72,7 +85,11 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
 */

steps = TOTAL_STEPS - adc_dev->channels;
-   stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1;
+   if (iio_buffer_enabled(indio_dev))
+   stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1
+   | STEPCONFIG_MODE_SWCNT;
+   else
+   stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1;

for (i = 0; i < adc_dev->channels; i++) {
int chan;
@@ -85,7 +102,177 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
adc_dev->channel_step[i] = steps;
steps++;
}
+}
+
+static irqreturn_t tiadc_irq_h(int irq, void *private)
+{
+   struct iio_dev *indio_dev = private;
+   struct tiadc_device *adc_dev = iio_priv(indio_dev);
+   unsigned int status, config;
+   status = tiadc_readl(adc_dev, REG_IRQSTATUS);
+
+   /*
+* ADC and touchscreen share the IRQ line.
+* FIFO0 interrupts are used by TSC. Handle FIFO1 IRQs here only
+*/
+   if (status & IRQENB_FIFO1OVRRUN) {
+   /* FIFO Overrun. Clear flag. Disable/Enable ADC to recover */
+   config = tiadc_readl(adc_dev, REG_CTRL);
+   config &= ~(CNTRLREG_TSCSSENB);
+   tiadc_writel(adc_dev, REG_CTRL, config);
+   tiadc_writel(adc_dev, REG_IRQSTATUS, IRQENB_FIFO1OVRRUN
+   | IRQENB_FIFO1UNDRFLW | IRQENB_FIFO1THRES);
+   tiadc_writel(adc_dev, REG_CTRL, (config | CNTRLREG_TSCSSENB));
+   return IRQ_HANDLED;
+   } else if (status & IRQENB_FIFO1THRES) {
+   /* Disable irq and wake worker thread */
+   tiadc_writel(adc_dev, REG_IRQCLR, IRQENB_FIFO1THRES);

I guess this is necessary given the sharing will make IRQF_ONESHOT
tricky. As disabling the source of the interrupts is nice and
easy here this will 

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek  wrote:
> Hi!
>
>> >> > So will you do that? Or it is needed to resend this one line
>> >> > hunk again in new email again?
>> >>
>> >> new patch, new email
>> >
>> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >
>> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> > another is hassling. So what you want from me? Do all those non
>> > sense working only because yesterday you had bad day? Or what?
> ...
>>
>> Hi Pali,
>>
>> There is no need to be rude.
>>
>> Felipe asked you to do the split since he believes that the notifier
>> chain call for musb xceiv and the twl->phy notifier head init should
>> be done in two separate patches.
>
> Actually, there is need to be rude, because Felipe fails to act as
> maintainer. Instead of fixing bugs in his code, he bounces bugfix
> patches, points people to random READMEs and wastes everyones time.
> Pavel
>

I don't know what are you talking about (if that happened in another
thread then I need more context). Felipe is not bouncing any bugfix
but just asked to split the patch in two since the patch was solving
two separate issues so is way better to have it in two separate
patches for the reasons I explained before.

So, as far as I can tell Felipe did exactly what I would expect from a
maintainer. He took the time to review the patches sent to him and
gave feedback. If the sender doesn't want to take his feedback into
account and prefer to send pretty insulting emails instead that is his
choice but I would say that is this not the greatest approach to get
your code merged (to say the least).

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

[PATCHv3] perf: Support for Openembedded/Yocto -dbg packages

[Ricardo Ribalda Delgado]

On OpenEmbedded the symbol files are located under a .debug folder on
the same folder as the binary file.

This patch adds support for such files.

Without this patch on perf top you can see:

no symbols found in /usr/lib/gstreamer-1.0/libtheoraenc.so.1.1.2, maybe install
a debug package?

84.56%  libtheoraenc.so.1.1.2   [.] 0xb346

With this patch symbols are shown:

19.06%  libtheoraenc.so.1.1.2   [.] oc_int_frag_satd_thresh_mmxext
9.76%   libtheoraenc.so.1.1.2   [.] oc_analyze_mb_mode_luma
5.58%   libtheoraenc.so.1.1.2   [.] oc_qii_state_advance
4.84%   libtheoraenc.so.1.1.2   [.] oc_enc_tokenize_ac
...

Signed-off-by: Ricardo Ribalda Delgado 
---

v2: Changes proposed by Ingo Molnar

-Improve changeset
-Improve multi-snprintf readability
-Code Style

v3: Changes proposed by Ingo Molnar, Arnaldo Carvalho de Melo and Peter Zijlstra

-Code Style
-Use scnprintf


 tools/perf/util/dso.c| 49 +++-
 tools/perf/util/dso.h|  1 +
 tools/perf/util/symbol.c |  1 +
 3 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index e3c1ff8..6bfc8aa 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -7,19 +7,20 @@
 char dso__symtab_origin(const struct dso *dso)
 {
static const char origin[] = {
-   [DSO_BINARY_TYPE__KALLSYMS] = 'k',
-   [DSO_BINARY_TYPE__VMLINUX]  = 'v',
-   [DSO_BINARY_TYPE__JAVA_JIT] = 'j',
-   [DSO_BINARY_TYPE__DEBUGLINK]= 'l',
-   [DSO_BINARY_TYPE__BUILD_ID_CACHE]   = 'B',
-   [DSO_BINARY_TYPE__FEDORA_DEBUGINFO] = 'f',
-   [DSO_BINARY_TYPE__UBUNTU_DEBUGINFO] = 'u',
-   [DSO_BINARY_TYPE__BUILDID_DEBUGINFO]= 'b',
-   [DSO_BINARY_TYPE__SYSTEM_PATH_DSO]  = 'd',
-   [DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE]  = 'K',
-   [DSO_BINARY_TYPE__GUEST_KALLSYMS]   = 'g',
-   [DSO_BINARY_TYPE__GUEST_KMODULE]= 'G',
-   [DSO_BINARY_TYPE__GUEST_VMLINUX]= 'V',
+   [DSO_BINARY_TYPE__KALLSYMS] = 'k',
+   [DSO_BINARY_TYPE__VMLINUX]  = 'v',
+   [DSO_BINARY_TYPE__JAVA_JIT] = 'j',
+   [DSO_BINARY_TYPE__DEBUGLINK]= 'l',
+   [DSO_BINARY_TYPE__BUILD_ID_CACHE]   = 'B',
+   [DSO_BINARY_TYPE__FEDORA_DEBUGINFO] = 'f',
+   [DSO_BINARY_TYPE__UBUNTU_DEBUGINFO] = 'u',
+   [DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO]   = 'o',
+   [DSO_BINARY_TYPE__BUILDID_DEBUGINFO]= 'b',
+   [DSO_BINARY_TYPE__SYSTEM_PATH_DSO]  = 'd',
+   [DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE]  = 'K',
+   [DSO_BINARY_TYPE__GUEST_KALLSYMS]   = 'g',
+   [DSO_BINARY_TYPE__GUEST_KMODULE]= 'G',
+   [DSO_BINARY_TYPE__GUEST_VMLINUX]= 'V',
};
 
if (dso == NULL || dso->symtab_type == DSO_BINARY_TYPE__NOT_FOUND)
@@ -64,6 +65,28 @@ int dso__binary_type_file(struct dso *dso, enum 
dso_binary_type type,
 symbol_conf.symfs, dso->long_name);
break;
 
+   case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO:
+   {
+   char *last_slash;
+   size_t len;
+   size_t dir_size;
+
+   last_slash = dso->long_name + dso->long_name_len;
+   while (last_slash != dso->long_name && *last_slash != '/')
+   last_slash--;
+
+   len = scnprintf(file, size, "%s", symbol_conf.symfs);
+   dir_size = last_slash - dso->long_name + 2;
+   if (dir_size > (size - len)) {
+   ret = -1;
+   break;
+   }
+   len += scnprintf(file + len, dir_size, "%s",  dso->long_name);
+   len += scnprintf(file + len , size - len, ".debug%s",
+   last_slash);
+   break;
+   }
+
case DSO_BINARY_TYPE__BUILDID_DEBUGINFO:
if (!dso->has_build_id) {
ret = -1;
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index b793053..dbd9241 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -23,6 +23,7 @@ enum dso_binary_type {
DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE,
DSO_BINARY_TYPE__KCORE,
DSO_BINARY_TYPE__GUEST_KCORE,
+   DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO,
DSO_BINARY_TYPE__NOT_FOUND,
 };
 
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 7eb0362..cd1dcc4 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -51,6 +51,7 @@ 

Re: [BUG] 3.7-rc regression bisected: s2disk fails to resume image: Processes could not be frozen, cannot continue resuming

[Al Viro]

On Tue, Aug 27, 2013 at 07:48:43AM +0400, Andrew Savchenko wrote:
> > Additional (but probably useless) information on this bug may be found
> > here: https://forums.gentoo.org/viewtopic-p-7371120.html

Something's very fishy there:

[quote]
Digging into suspend-utils code shows that the following ioctl fails on  
"/dev/snapshot": 

Code:   
  ioctl(dev, _IO(3, 1), 0);  
[end quote]

but that's _not_ anything freeze-related - that's HDIO_GETGEO, and with zero
as last argument it will fail, no matter what.  With EFAULT, if nothing
else...

Which ioctl() it really is?  A bit further down you write "I modified suspend
code to see errno, so freeze on /dev/snapshot fails [with EAGAIN]", so you
have isolated the call in question.  Could you quote the actual code?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver

[Sricharan R]

Hi Thomas,

On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
> On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner  wrote:
>
>> So why can't you make use of irq domains and have the whole routing
>> business implemented sanely?
>>
>> What's needed is in gic_init_bases():
>> irq
>>if (of_property_read(node, "routable_irqs", _routable_irqs) {
>>   irq_domain_add_legacy(nr_gic_irqs);
>>} else {
>>   irq_domain_add_legacy(nr_per_cpu_irqs);
>>   irq_domain_add_linear(nr_routable_irqs);
>>}
>>
>> Now that separate domain has an xlate function which grabs a free GIC
>> irq from a bitmap and returns the hardware irq number in the gic
>> space. The map/unmap callbacks take care of setting up / tearing down
>> the route in the crossbar.
> This is obviously the right approach, it's exactly what .map should do
> the only special thing here being that we have hardware to perform
> the mapping ... bah why didn't I realize this :-(
>
> Yours,
> Linus Walleij
Thanks for the suggestion.

So as i understand this, this implies using the GIC domain itself and
 add the support for dynamically routable irqs (like crossbar) with in the
GIC driver itself right ?

Regards,
 Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MIPS: ath79: Avoid using unitialized 'reg' variable

[Ralf Baechle]

On Wed, Sep 18, 2013 at 03:45:33PM +0200, Ralf Baechle wrote:

> So here's a small test case to demonstrate the issue:
> 
> /*
>  * Definition of BUG taken from asm-generic/bug.h for the CONFIG_BUG=n case
>  */
> #define BUG() do {} while(0)
> 
> int foo(int arg)
> {
>   int res;
> 
>   if (arg == 1)
>   res = 23;
>   else if (arg -= 2)

I fatfingered the testcase while editing the email.  this line of course
is "else if (arg == 2)"

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: problem booting linux with qemu-system-arm -M spitz

[Andrea Adami]

On Wed, Sep 18, 2013 at 12:27 PM, Waldemar Brodkorb  wrote:
> Hi Kernel hackers,
>
> I am trying to run Linux on Qemu/arm emulator with machine type
> spitz. In the past this worked fine.
> Now with Linux version 3.9.11 it does not boot anymore.
> (blank screen, no kernel messages)
>
> I used git bisect to find the commit, which breaks the boot:
> commit 4e8ee7de227e3ab9a72040b448ad728c5428a042
> Author: Will Deacon 
> Date:   Wed Nov 23 12:26:25 2011 +
>
> I am using Qemu 1.6.0 on a Debian/x86_64 host.
>
> Any help would be appreciated.
>
> Thanks in advance
>  Waldemar
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On real hardware I see the same breakage after 3.2.
Marko diagnosed it and there is a pending patch:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/198444.html

There is indeed some MMU-related issue.
Probably the function could be called elsewhere during machine init
but I'm not so high in the food chain to dare to touch arm boot code
;)

Regards

Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm

[Pavel Machek]

On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote:
> This patch introduced SNAPSHOT_SIG_HASH config for user to select which
> hash algorithm will be used during signature generation of snapshot.

This series is big enough already... and who is going to test it?
There's no need to make hash configurable. Just select one that works.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] MIPS: ath79: Avoid using unitialized 'reg' variable

[Ralf Baechle]

On Tue, Sep 03, 2013 at 03:03:39PM +0100, Markos Chandras wrote:

> >Was this triggered by CONFIG_BUG=n?
> >
> >   Ralf
> >
> 
> Hi Ralf,
> 
> Yes it was triggered by CONFIG_BUG=n

So here's a small test case to demonstrate the issue:

/*
 * Definition of BUG taken from asm-generic/bug.h for the CONFIG_BUG=n case
 */
#define BUG()   do {} while(0)

int foo(int arg)
{
int res;

if (arg == 1)
res = 23;
else if (arg -= 2)
res = 42;
else
BUG();

return res;
}

[ralf@h7 linux-mips]$ gcc -O2 -Wall -c bug.c 
bug.c: In function ‘foo’:
bug.c:17:2: warning: ‘res’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]
  return res;
  ^

It's fairly obvious to see what's happening here - GCC doesn't know that
the else case can not be reached, thus razorsharply concludes that res
may be used uninitialized.

I think the definition of BUG should be changed to something like

#define BUG()   unreachable()

This has the disadvantage of of expanding into a while (1) loop for older
compilers - but that's only for older compilers, relativly minor in
bloat and last I checked BUG() wasn't performance critical ;-)

  Ralf

Signed-off-by: Ralf Baechle 

 include/asm-generic/bug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96..6f78771 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -108,7 +108,7 @@ extern void warn_slowpath_null(const char *file, const int 
line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() unreachable()
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Full syscall argument decode in "perf trace"

[Ingo Molnar]

* David Ahern  wrote:

> On 9/18/13 5:35 AM, Denys Vlasenko wrote:
> >Therefore my question should be restated as:
> >
> >Would perf developers accept the "syscall pausing" feature,
> >or it won't be accepted?
> 
> I have been using perf-trace a lot lately specifically because it is 
> effectively a 'passive' observer of the task (e.g., time-sensitive tasks 
> can be traced with perf but not with strace).

Yes, this is not just an important but a primary design goal for all perf 
utilities: if the tracing buffers used are large enough then it should be 
a nearly zero-overhead observer that preserves all previous patterns of 
behavior as much as possible.

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 01/28] c6x: use boot_command_line instead of private c6x_command_line

[Mark Salter]

On Mon, 2013-09-16 at 18:08 -0500, Rob Herring wrote:
> From: Rob Herring 
> 
> Save some pointless copying of the kernel command line and just use
> boot_command_line instead.
> 
> Also remove default_command_line as it is not referenced anywhere, and
> the DT code already handles the default command line.
> 

The default_command_line is leftover cruft from the kernel before it was
upstreamed. It was a mechanism to place the commandline at a known fixed
offset in the Image. It was needed for simple (serial eeprom based)
loaders which didn't know about DT. Anyway, bits of that support are
missing, so I don't see a reason to keep it around. If anyone complains
we can add it back in as a completely functional patch. There is also
a fragment of arch/c6x/kernel/vmlinux.lds.S which should also be
removed:

diff --git a/arch/c6x/kernel/vmlinux.lds.S b/arch/c6x/kernel/vmlinux.lds.S
index 279d807..5a6e141 100644
--- a/arch/c6x/kernel/vmlinux.lds.S
+++ b/arch/c6x/kernel/vmlinux.lds.S
@@ -37,12 +37,6 @@ SECTIONS
_vectors_end = .;
}
 
-   . = ALIGN(0x1000);
-   .cmdline :
-   {
-   *(.cmdline)
-   }
-
/*
 * This section contains data which may be shared with other
 * cores. It needs to be a fixed offset from PAGE_OFFSET


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

Re: [PATCH v2] perf: Support for Openembedded/Yocto -dbg packages

[Ingo Molnar]

* Ricardo Ribalda Delgado  wrote:

> On OpenEmbedded the symbol files are located under a .debug folder on
> the same folder as the binary file.
> 
> This patch adds support for such files.
> 
> Without this patch on perf top you can see:
> 
> no symbols found in /usr/lib/gstreamer-1.0/libtheoraenc.so.1.1.2, maybe 
> install
> a debug package?
> 
> 84.56%  libtheoraenc.so.1.1.2   [.] 0xb346
> 
> With this patch symbols are shown:
> 
> 19.06%  libtheoraenc.so.1.1.2   [.] oc_int_frag_satd_thresh_mmxext
> 9.76%   libtheoraenc.so.1.1.2   [.] oc_analyze_mb_mode_luma
> 5.58%   libtheoraenc.so.1.1.2   [.] oc_qii_state_advance
> 4.84%   libtheoraenc.so.1.1.2   [.] oc_enc_tokenize_ac
> ...

Nice! Two nits are remaining:

> @@ -64,6 +65,21 @@ int dso__binary_type_file(struct dso *dso, enum 
> dso_binary_type type,
>symbol_conf.symfs, dso->long_name);
>   break;
>  
> + case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO:{

I think you missed the review feedback I gave for this line in the 
previous mail.

> + char *last_slash;
> +
> + last_slash = dso->long_name + dso->long_name_len;
> + while (last_slash != dso->long_name && *last_slash != '/')
> + last_slash--;
> +
> + size -= snprintf(file, MIN(size, strlen(symbol_conf.symfs) +
> + (last_slash - dso->long_name) + 2), "%s%s",
> + symbol_conf.symfs, dso->long_name);
> + snprintf(file + strlen(file), size, ".debug%s",
> + last_slash);
> + break;
> + }

The 'MIN' still looks superfluous (btw., we use min()) - why not simply 
set 'size' to the correct value when you set and iterate last_slash?

(and scnprintf() should be used, as Arnaldo suggested.)

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] audit: fix endless wait in audit_log_start()

[Richard Guy Briggs]

On Wed, Sep 18, 2013 at 01:48:17PM +0400, Konstantin Khlebnikov wrote:
> After commit 829199197a430dade2519d54f5545c4a094393b8 audit emiters will block
> forever if userspace daemon cannot handle backlog. After the timeout waiting
> loop turns into busy loop and runs until daemon dies or returns back to work.
> This is minimal patch for that bug.

Thanks Konstantin,

This patch is in my patchset...

> Signed-off-by: Konstantin Khlebnikov 
> Cc: Andrew Morton 
> Cc: Luiz Capitulino 
> Cc: Richard Guy Briggs 
> Cc: Eric Paris 
> Cc: Chuck Anderson 
> Cc: Dan Duval 
> Cc: Dave Kleikamp 
> ---
>  kernel/audit.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 91e53d0..7b0e23a 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1117,9 +1117,10 @@ struct audit_buffer *audit_log_start(struct 
> audit_context *ctx, gfp_t gfp_mask,
>  
>   sleep_time = timeout_start + audit_backlog_wait_time -
>   jiffies;
> - if ((long)sleep_time > 0)
> + if ((long)sleep_time > 0) {
>   wait_for_auditd(sleep_time);
> - continue;
> + continue;
> + }
>   }
>   if (audit_rate_check() && printk_ratelimit())
>   printk(KERN_WARNING
> 

- RGB

--
Richard Guy Briggs 
Senior Software Engineer
Kernel Security
AMER ENG Base Operating Systems
Remote, Ottawa, Canada
Voice: +1.647.777.2635
Internal: (81) 32635
Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> >> > So will you do that? Or it is needed to resend this one line
> >> > hunk again in new email again?
> >>
> >> new patch, new email
> >
> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >
> > Sorry but, need to copy full isolated patch/hunk from one mail to
> > another is hassling. So what you want from me? Do all those non
> > sense working only because yesterday you had bad day? Or what?
...
> 
> Hi Pali,
> 
> There is no need to be rude.
> 
> Felipe asked you to do the split since he believes that the notifier
> chain call for musb xceiv and the twl->phy notifier head init should
> be done in two separate patches.

Actually, there is need to be rude, because Felipe fails to act as
maintainer. Instead of fixing bugs in his code, he bounces bugfix
patches, points people to random READMEs and wastes everyones time.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 00/10] of/irq: Defer interrupt reference resolution

[Thierry Reding]

Hi,

This small series allows interrupt references from the device tree to be
resolved at driver probe time, rather than at device creation time. The
current implementation resolves such references while devices are added
during the call to of_platform_populate(), which happens very early in
the boot process. This causes probe ordering issues, because all devices
that are an interrupt parent for other devices need to have been probed
by that time. This is worked around for primary interrupt controllers by
initializing them using a device tree specific way (of_irq_init()), but
it doesn't work for something like a GPIO controller that is itself a
platform device and an interrupt parent for other devices at the same
time.

Currently such drivers use explicit initcall ordering to force these
chips to be probed earlier than other devices, but that only fixes a
subset of the problematic cases. It doesn't work if the interrupt user
is itself a platform device on the same bus. There are possibly other
cases where it doesn't work either.

This patch series attempts to fix this by not resolving the interrupt
references at device creation time. Instead, some functionality is added
to the driver core to resolve them for each device immediately before it
is probed. Often this is a lot later than the point at which the device
was created, which gives interrupt parents more time and therefore a
better chance of being probed. More importantly, however, it allows the
driver core to detect when an interrupt parent isn't there yet and cause
the device to be queued for deferred probing. After all, resolving probe
ordering issues is one of the primary reason for the introduction of
deferred probing.

Unfortunately the interrupt core code isn't prepared to handle this very
well, so some preparatory work is required.

Patches 1 and 2 are cleanup. Patch 1 modifies of_irq_count() to not use
the heavyweight of_irq_to_resource(), which will actually try to create
a mapping. While not usually harmful, it causes a warning during boot if
the interrupt parent hasn't registered an IRQ domain yet. Furthermore it
is much more than the stated intention of the function, which is to
return the number of interrupts that a device node uses. Various uses of
the of_irq_to_resource() function are replaced by more simpler versions
using irq_of_parse_and_map() in patch 2.

Patches 3 introduces the __irq_create_mapping() function, equivalent to
its non-__ counterpart except that it returns a negative error code on
failure and therefore allows propagation of a precise error code instead
of 0 for all errors. This is an important prerequisite for subsequent
patches. I would've preferred not to introduce an underscore-prefixed
variant but there are about 114 callers and updating them all would've
been rather messy.

Patch 4 updates irq_create_of_mapping() to return a negative error code
on failure instead of 0. The number of the mapped interrupt is returned
in an output parameter. All callers of this function are updated.

Patch 5 adds an __-prefixed variant of irq_of_parse_and_map() which
returns a negative error code on failure instead of 0. The number of
the mapped interrupt is returned in an output parameter.

Patch 6 modifies of_irq_to_resource() to return a negative error code on
failure (so that error can be propagated) and updates all callers.

Patch 7 propagates errors from of_irq_to_resource() to users of the
of_irq_to_resource_table() function.

Patch 8 adds functionality to the platform driver code to resolve
interrupt references at probe time. It uses the negative error code of
the of_irq_to_resource_table() function to trigger deferred probing.

Patch 9 implements similar functionality for I2C devices.

Patch 10 serves as an example of the kind of cleanup that can be done
after this series. Obviously this will require quite a bit of retesting
of working setups, but I think that in the long run we're better off
without the kind of explicit probe ordering employed by the gpio-tegra
driver and many others.

Note that I've only implemented this for platform and I2C devices, but
the same can be done for SPI and possibly other subsystems as well.

There is another use-case that I'm aware of for which a similar solution
could be implemented. IOMMUs on SoCs generally need to hook themselves
up to new platform devices. This causes a similar issues as interrupt
resolution and should be fixable by extending the of_platform_probe()
function introduced in patch 7 of this series.

Changes in v2:
- use more consistent naming and calling conventions
- use less wrappers, update more callers
- make of_platform_probe() idempotent

The initial version of this patch series can be found here:

https://lkml.org/lkml/2013/9/16/111

Thierry

Thierry Reding (10):
  of/irq: Rework of_irq_count()
  of/irq: Use irq_of_parse_and_map()
  irqdomain: Introduce __irq_create_mapping()
  irqdomain: Return errors from irq_create_of_mapping()
  of/irq: Introduce 

[PATCH v2 03/10] irqdomain: Introduce __irq_create_mapping()

[Thierry Reding]

This is a version of irq_create_mapping() that propagates the precise
error code instead of returning 0 for all errors. It will be used in
subsequent patches to allow further propagation of error codes.

To avoid code duplication, implement irq_create_mapping() as a wrapper
around the new __irq_create_mapping().

Signed-off-by: Thierry Reding 
---
 kernel/irq/irqdomain.c | 59 +-
 1 file changed, 39 insertions(+), 20 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 706724e..d2a3b01 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -374,30 +374,21 @@ unsigned int irq_create_direct_mapping(struct irq_domain 
*domain)
 }
 EXPORT_SYMBOL_GPL(irq_create_direct_mapping);
 
-/**
- * irq_create_mapping() - Map a hardware interrupt into linux irq space
- * @domain: domain owning this hardware interrupt or NULL for default domain
- * @hwirq: hardware irq number in that domain space
- *
- * Only one mapping per hardware interrupt is permitted. Returns a linux
- * irq number.
- * If the sense/trigger is to be specified, set_irq_type() should be called
- * on the number returned from that call.
- */
-unsigned int irq_create_mapping(struct irq_domain *domain,
-   irq_hw_number_t hwirq)
+static int __irq_create_mapping(struct irq_domain *domain,
+   irq_hw_number_t hwirq, unsigned int *virqp)
 {
-   unsigned int hint;
-   int virq;
+   unsigned int hint, virq;
+   int ret;
 
-   pr_debug("irq_create_mapping(0x%p, 0x%lx)\n", domain, hwirq);
+   pr_debug("__irq_create_mapping(0x%p, 0x%lx, %p)\n", domain, hwirq,
+virqp);
 
/* Look for default domain if nececssary */
if (domain == NULL)
domain = irq_default_domain;
if (domain == NULL) {
WARN(1, "%s(, %lx) called with NULL domain\n", __func__, hwirq);
-   return 0;
+   return -ENODEV;
}
pr_debug("-> using domain @%p\n", domain);
 
@@ -405,7 +396,11 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
virq = irq_find_mapping(domain, hwirq);
if (virq) {
pr_debug("-> existing mapping on virq %d\n", virq);
-   return virq;
+
+   if (virqp)
+   *virqp = virq;
+
+   return 0;
}
 
/* Allocate a virtual interrupt number */
@@ -417,17 +412,41 @@ unsigned int irq_create_mapping(struct irq_domain *domain,
virq = irq_alloc_desc_from(1, of_node_to_nid(domain->of_node));
if (virq <= 0) {
pr_debug("-> virq allocation failed\n");
-   return 0;
+   return virq ? : -ENOSPC;
}
 
-   if (irq_domain_associate(domain, virq, hwirq)) {
+   ret = irq_domain_associate(domain, virq, hwirq);
+   if (ret) {
irq_free_desc(virq);
-   return 0;
+   return ret;
}
 
pr_debug("irq %lu on domain %s mapped to virtual irq %u\n",
hwirq, of_node_full_name(domain->of_node), virq);
 
+   if (virqp)
+   *virqp = virq;
+
+   return 0;
+}
+/**
+ * irq_create_mapping() - Map a hardware interrupt into linux irq space
+ * @domain: domain owning this hardware interrupt or NULL for default domain
+ * @hwirq: hardware irq number in that domain space
+ *
+ * Only one mapping per hardware interrupt is permitted. Returns a linux
+ * irq number.
+ * If the sense/trigger is to be specified, set_irq_type() should be called
+ * on the number returned from that call.
+ */
+unsigned int irq_create_mapping(struct irq_domain *domain,
+   irq_hw_number_t hwirq)
+{
+   unsigned int virq;
+
+   if (__irq_create_mapping(domain, hwirq, ))
+   return 0;
+
return virq;
 }
 EXPORT_SYMBOL_GPL(irq_create_mapping);
-- 
1.8.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] perf: Support for Openembedded/Yocto -dbg packages

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Em Wed, Sep 18, 2013 at 12:18:01PM +0200, Peter Zijlstra escreveu:
> > On Wed, Sep 18, 2013 at 12:02:12PM +0200, Ricardo Ribalda Delgado wrote:
> > > Perhaps this is even more clear than v2:
> 
> > > len = snprintf(file, size, "%s", symbol_conf.symfs);
> > > size -= len;
> > > file += len;
> > > len = snprintf(file, MIN(size,(last_slash - dso->long_name) + 2),
> > > "%s",  dso->long_name);
> > > size -= len;
> > > file += len;
> > > len = snprintf(file, size, ".debug%s",  last_slash);
> 
> > len = 0;
> 
> > len += snprintf(str + len, size - len, ...);
> > len += snprintf(str + len, size - len, ...);
> 
> And avoid snprintf like the plague, use scnprintf instead...  See
> e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 for details :-)

Hm, could we do:

#define snprintf scnprintf

or:

#define snprintf(x...) BUILD_BUG()

?

I don't think there's any valid code, except printf wrappers (which we 
don't have in perf), where the semantics of snprintf() would be needed.

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 01/10] of/irq: Rework of_irq_count()

[Thierry Reding]

The of_irq_to_resource() helper that is used to implement of_irq_count()
tries to resolve interrupts and in fact creates a mapping for resolved
interrupts. That's pretty heavy lifting for something that claims to
just return the number of interrupts requested by a given device node.

Instead, use the more lightweight of_irq_map_one(), which, despite the
name, doesn't create an actual mapping. Perhaps a better name would be
of_irq_translate_one().

Signed-off-by: Thierry Reding 
---
 drivers/of/irq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 1752988..5f44388 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -368,9 +368,10 @@ EXPORT_SYMBOL_GPL(of_irq_to_resource);
  */
 int of_irq_count(struct device_node *dev)
 {
+   struct of_irq irq;
int nr = 0;
 
-   while (of_irq_to_resource(dev, nr, NULL))
+   while (of_irq_map_one(dev, nr, ) == 0)
nr++;
 
return nr;
-- 
1.8.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 05/10] of/irq: Introduce __irq_of_parse_and_map()

[Thierry Reding]

This is a version of irq_of_parse_and_map() that propagates the precise
error code instead of returning 0 for all errors. It will be used in
subsequent patches to allow further propagation of error codes.

To avoid code duplication, implement irq_of_parse_and_map() as a static
inline wrapper around the new __irq_of_parse_and_map(). Note that this
is somewhat complicated by the fact that SPARC implement its own version
of irq_of_parse_and_map(). Make SPARC implement __irq_of_parse_and_map()
so that the static inline wrapper can be used on all platforms.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- rename of_irq_get() to __irq_of_parse_and_map()

 arch/sparc/kernel/of_device_common.c | 12 
 drivers/of/irq.c | 18 --
 include/linux/of_irq.h   | 19 ++-
 3 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/arch/sparc/kernel/of_device_common.c 
b/arch/sparc/kernel/of_device_common.c
index de199bf..a69559f 100644
--- a/arch/sparc/kernel/of_device_common.c
+++ b/arch/sparc/kernel/of_device_common.c
@@ -11,16 +11,20 @@
 
 #include "of_device_common.h"
 
-unsigned int irq_of_parse_and_map(struct device_node *node, int index)
+int __irq_of_parse_and_map(struct device_node *node, unsigned int index,
+  unsigned int *virqp)
 {
struct platform_device *op = of_find_device_by_node(node);
 
if (!op || index >= op->archdata.num_irqs)
-   return 0;
+   return !op ? -ENODEV : -EINVAL;
 
-   return op->archdata.irqs[index];
+   if (virqp)
+   *virqp = op->archdata.irqs[index];
+
+   return 0;
 }
-EXPORT_SYMBOL(irq_of_parse_and_map);
+EXPORT_SYMBOL(__irq_of_parse_and_map);
 
 int of_address_to_resource(struct device_node *node, int index,
   struct resource *r)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 5f44388..6ad46fd 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -27,24 +27,30 @@
 #include 
 
 /**
- * irq_of_parse_and_map - Parse and map an interrupt into linux virq space
+ * __irq_of_parse_and_map - Parse and map an interrupt into linux virq space
  * @dev: Device node of the device whose interrupt is to be mapped
  * @index: Index of the interrupt to map
+ * @virqp: Linux interrupt number filled by this function
  *
  * This function is a wrapper that chains of_irq_map_one() and
  * irq_create_of_mapping() to make things easier to callers
+ *
+ * Returns 0 on success or a negative error code on failure.
  */
-unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
+int __irq_of_parse_and_map(struct device_node *dev, unsigned int index,
+  unsigned int *virqp)
 {
struct of_irq oirq;
+   int ret;
 
-   if (of_irq_map_one(dev, index, ))
-   return 0;
+   ret = of_irq_map_one(dev, index, );
+   if (ret)
+   return ret;
 
return irq_create_of_mapping(oirq.controller, oirq.specifier,
-oirq.size);
+oirq.size, virqp);
 }
-EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
+EXPORT_SYMBOL_GPL(__irq_of_parse_and_map);
 
 /**
  * of_irq_find_parent - Given a device node, find its interrupt parent node
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 138266d..11da949 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -11,11 +11,12 @@ struct of_irq;
 #include 
 
 /*
- * irq_of_parse_and_map() is used by all OF enabled platforms; but SPARC
+ * __irq_of_parse_and_map() is used by all OF enabled platforms; but SPARC
  * implements it differently.  However, the prototype is the same for all,
  * so declare it here regardless of the CONFIG_OF_IRQ setting.
  */
-extern unsigned int irq_of_parse_and_map(struct device_node *node, int index);
+extern int __irq_of_parse_and_map(struct device_node *node, unsigned int index,
+ unsigned int *virqp);
 
 #if defined(CONFIG_OF_IRQ)
 /**
@@ -78,10 +79,11 @@ extern void of_irq_init(const struct of_device_id *matches);
 #endif /* CONFIG_OF_IRQ */
 
 #else /* !CONFIG_OF */
-static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
-   int index)
+static inline int __irq_of_parse_and_map(struct device_node *dev,
+unsigned int index,
+unsigned int *virqp)
 {
-   return 0;
+   return -ENOSYS;
 }
 
 static inline void *of_irq_find_parent(struct device_node *child)
@@ -90,4 +92,11 @@ static inline void *of_irq_find_parent(struct device_node 
*child)
 }
 #endif /* !CONFIG_OF */
 
+static inline unsigned int irq_of_parse_and_map(struct device_node *node,
+   unsigned int index)
+{
+   unsigned int irq;
+   return (__irq_of_parse_and_map(node, index, ) < 0) ? 0 : irq;
+}
+
 

[PATCH v2 07/10] of/irq: Propagate errors in of_irq_to_resource_table()

[Thierry Reding]

Now that all helpers return precise error codes, this function can
propagate these errors to the caller properly.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- return 0 on success or a negative error code on failure
- convert callers to new calling convention

 arch/mips/lantiq/irq.c   |  2 +-
 arch/mips/lantiq/xway/gptu.c |  6 --
 drivers/of/irq.c | 14 --
 drivers/tty/serial/lantiq.c  |  2 +-
 4 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/mips/lantiq/irq.c b/arch/mips/lantiq/irq.c
index eb3e186..5bb7ee6 100644
--- a/arch/mips/lantiq/irq.c
+++ b/arch/mips/lantiq/irq.c
@@ -389,7 +389,7 @@ int __init icu_of_init(struct device_node *node, struct 
device_node *parent)
 
ret = of_irq_to_resource_table(eiu_node,
ltq_eiu_irq, exin_avail);
-   if (ret != exin_avail)
+   if (ret < 0)
panic("failed to load external irq resources\n");
 
if (request_mem_region(res.start, resource_size(),
diff --git a/arch/mips/lantiq/xway/gptu.c b/arch/mips/lantiq/xway/gptu.c
index 850821d..0c4b134 100644
--- a/arch/mips/lantiq/xway/gptu.c
+++ b/arch/mips/lantiq/xway/gptu.c
@@ -137,10 +137,12 @@ static int gptu_probe(struct platform_device *pdev)
 {
struct clk *clk;
struct resource *res;
+   int ret;
 
-   if (of_irq_to_resource_table(pdev->dev.of_node, irqres, 6) != 6) {
+   ret = of_irq_to_resource_table(pdev->dev.of_node, irqres, 6);
+   if (ret < 0) {
dev_err(>dev, "Failed to get IRQ list\n");
-   return -EINVAL;
+   return ret;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index e4f38c0..6d7f824 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -397,18 +397,20 @@ int of_irq_count(struct device_node *dev)
  * @res: array of resources to fill in
  * @nr_irqs: the number of IRQs (and upper bound for num of @res elements)
  *
- * Returns the size of the filled in table (up to @nr_irqs).
+ * Returns 0 on success or a negative error code on failure.
  */
 int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
int nr_irqs)
 {
-   int i;
+   int i, ret;
 
-   for (i = 0; i < nr_irqs; i++, res++)
-   if (!of_irq_to_resource(dev, i, res))
-   break;
+   for (i = 0; i < nr_irqs; i++, res++) {
+   ret = of_irq_to_resource(dev, i, res);
+   if (ret < 0)
+   return ret;
+   }
 
-   return i;
+   return 0;
 }
 EXPORT_SYMBOL_GPL(of_irq_to_resource_table);
 
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 88d01e0..e59efdc 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -686,7 +686,7 @@ lqasc_probe(struct platform_device *pdev)
 
mmres = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ret = of_irq_to_resource_table(node, irqres, 3);
-   if (!mmres || (ret != 3)) {
+   if (!mmres || (ret < 0)) {
dev_err(>dev,
"failed to get memory/irq for serial port\n");
return -ENODEV;
-- 
1.8.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/

Dependency bug in the uvcvideo Kconfig

[Jeff P. Zacher]

Not subscribed, please CC'me in replies:

There seems to be a dependency bug in the Kconfig for the uvcvideo kernel 
module.  If uvcvideo is built in and usb support is built as a module, the 
kernel build will fail with the obviously missing dependanies.


Error logs:

* ERROR: Failed to compile the "bzImage" target...
* 
* -- Grepping log... --
* 
*  SHIPPED scripts/genksyms/keywords.hash.c
*  SHIPPED scripts/genksyms/parse.tab.h
*  SHIPPED scripts/genksyms/parse.tab.c
*  HOSTCC  scripts/genksyms/lex.lex.o
*scripts/genksyms/lex.lex.c_shipped: In function ‘yylex1’:
*scripts/genksyms/lex.lex.c_shipped:904:1: warning: ignoring return value of 
‘fwrite’, declared with attribute warn_unused_result [-Wunused-result]
*--
*  CC  drivers/video/console/font_8x16.o
*  CC  drivers/video/console/softcursor.o
*  CC  sound/core/seq/seq_memory.o
*  CC  drivers/video/console/fbcondecor.o
*  CC  sound/core/seq/seq_queue.o
*drivers/video/console/fbcondecor.c:511:6: warning: function declaration isn’t 
a prototype [-Wstrict-prototypes]
*--
*(.text+0xf8fb1): undefined reference to `usb_submit_urb'
*drivers/built-in.o: In function `uvc_init':
*uvc_driver.c:(.init.text+0x908a): undefined reference to 
`usb_register_driver'
*drivers/built-in.o: In function `uvc_cleanup':
*uvc_driver.c:(.exit.text+0x67e): undefined reference to `usb_deregister'
*make: *** [vmlinux] Error 1
*--
* Running with options: --lvm --menuconfig all
* Using genkernel.conf from /etc/genkernel.conf
* Sourcing arch-specific config.sh from 
/usr/share/genkernel/arch/x86_64/config.sh ..
* Sourcing arch-specific modules_load from 
/usr/share/genkernel/arch/x86_64/modules_load ..
*
* ERROR: Failed to compile the "bzImage" target...
* 
* -- End log... --

Compiling uvc as a module allows the compilation to complete.

Platform x86_64

Ref: http://forums.gentoo.org/viewtopic-p-7398782.html#7398782


-- Jeff P. Zacher
ad_si...@yahoo.com

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

[PATCH v2 08/10] of/platform: Resolve interrupt references at probe time

[Thierry Reding]

Interrupt references are currently resolved very early (when a device is
created). This has the disadvantage that it will fail in cases where the
interrupt parent hasn't been probed and no IRQ domain for it has been
registered yet. To work around that various drivers use explicit
initcall ordering to force interrupt parents to be probed before devices
that need them are created. That's error prone and doesn't always work.
If a platform device uses an interrupt line connected to a different
platform device (such as a GPIO controller), both will be created in the
same batch, and the GPIO controller won't have been probed by its driver
when the depending platform device is created. Interrupt resolution will
fail in that case.

Another common workaround is for drivers to explicitly resolve interrupt
references at probe time. This is suboptimal, however, because it will
require every driver to duplicate the code.

This patch adds support for late interrupt resolution to the platform
driver core, by resolving the references right before a device driver's
.probe() function will be called. This not only delays the resolution
until a much later time (giving interrupt parents a better chance of
being probed in the meantime), but it also allows the platform driver
core to queue the device for deferred probing if the interrupt parent
hasn't registered its IRQ domain yet.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- split off IRQ parsing into separate function to make code flow simpler
- add comments to point out some aspects of the implementation
- make code idempotent (as pointed out by Grygorii Strashko

 drivers/base/platform.c |   4 ++
 drivers/of/platform.c   | 107 +---
 include/linux/of_platform.h |   7 +++
 3 files changed, 112 insertions(+), 6 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 4f8bef3..8dcf835 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -481,6 +481,10 @@ static int platform_drv_probe(struct device *_dev)
struct platform_device *dev = to_platform_device(_dev);
int ret;
 
+   ret = of_platform_probe(dev);
+   if (ret)
+   return ret;
+
if (ACPI_HANDLE(_dev))
acpi_dev_pm_attach(_dev, true);
 
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 9b439ac..df6d56e 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -142,7 +142,7 @@ struct platform_device *of_device_alloc(struct device_node 
*np,
  struct device *parent)
 {
struct platform_device *dev;
-   int rc, i, num_reg = 0, num_irq;
+   int rc, i, num_reg = 0;
struct resource *res, temp_res;
 
dev = platform_device_alloc("", -1);
@@ -153,23 +153,21 @@ struct platform_device *of_device_alloc(struct 
device_node *np,
if (of_can_translate_address(np))
while (of_address_to_resource(np, num_reg, _res) == 0)
num_reg++;
-   num_irq = of_irq_count(np);
 
/* Populate the resource table */
-   if (num_irq || num_reg) {
-   res = kzalloc(sizeof(*res) * (num_irq + num_reg), GFP_KERNEL);
+   if (num_reg) {
+   res = kzalloc(sizeof(*res) * num_reg, GFP_KERNEL);
if (!res) {
platform_device_put(dev);
return NULL;
}
 
-   dev->num_resources = num_reg + num_irq;
+   dev->num_resources = num_reg;
dev->resource = res;
for (i = 0; i < num_reg; i++, res++) {
rc = of_address_to_resource(np, i, res);
WARN_ON(rc);
}
-   WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
}
 
dev->dev.of_node = of_node_get(np);
@@ -490,4 +488,101 @@ int of_platform_populate(struct device_node *root,
return rc;
 }
 EXPORT_SYMBOL_GPL(of_platform_populate);
+
+/**
+ * of_platform_parse_irq() - parse interrupt resource from device node
+ * @pdev: pointer to platform device
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+static int of_platform_parse_irq(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   unsigned int num_res = pdev->num_resources;
+   struct resource *res = pdev->resource;
+   unsigned int num_irq, num, c;
+   int ret = 0;
+
+   num_irq = of_irq_count(pdev->dev.of_node);
+   if (!num_irq)
+   return 0;
+
+   /*
+* Deferred probing may cause this function to be called multiple
+* times, so check if all interrupts have been parsed already and
+* return early.
+*/
+   for (c = 0; c < num_irq; c++)
+   if (platform_get_irq(pdev, c) < 0)
+   break;
+
+   if (c == num_irq)
+   return 0;
+
+   num = 

[PATCH v2 06/10] of/irq: Return errors from of_irq_to_resource()

[Thierry Reding]

Update of_irq_to_resource() to return 0 on success and a negative error
code on failure. This allows the precise nature of the failure to be
determined in the caller and errors to be propagated appropriately.

While at it, make the index parameter unsigned. Accessing negative
indices is invalid, so we might as well enforce that by using the right
data type.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- convert existing callers instead of using compatible wrapper

 arch/powerpc/platforms/83xx/mpc832x_rdb.c  |  2 +-
 drivers/net/ethernet/marvell/mv643xx_eth.c |  5 +++--
 drivers/of/irq.c   | 14 +++---
 include/linux/of_irq.h |  2 +-
 4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c 
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index eff5baa..b198e73 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -89,7 +89,7 @@ static int __init of_fsl_spi_probe(char *type, char 
*compatible, u32 sysclk,
goto err;
 
ret = of_irq_to_resource(np, 0, [1]);
-   if (ret == NO_IRQ)
+   if (ret)
goto err;
 
pdev = platform_device_alloc("mpc83xx_spi", i);
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 7fb5677..bd713bd 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2489,9 +2489,10 @@ static int mv643xx_eth_shared_of_add_port(struct 
platform_device *pdev,
ppd.shared = pdev;
 
memset(, 0, sizeof(res));
-   if (!of_irq_to_resource(pnp, 0, )) {
+   ret = of_irq_to_resource(pnp, 0, );
+   if (ret) {
dev_err(>dev, "missing interrupt on %s\n", pnp->name);
-   return -EINVAL;
+   return ret;
}
 
if (of_property_read_u32(pnp, "reg", _number)) {
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 6ad46fd..e4f38c0 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -341,10 +341,18 @@ EXPORT_SYMBOL_GPL(of_irq_map_one);
  * @dev: pointer to device tree node
  * @index: zero-based index of the irq
  * @r: pointer to resource structure to return result into.
+ *
+ * Returns zero on success or a negative error code on failure.
  */
-int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
+int of_irq_to_resource(struct device_node *dev, unsigned int index,
+  struct resource *r)
 {
-   int irq = irq_of_parse_and_map(dev, index);
+   unsigned int irq;
+   int ret;
+
+   ret = __irq_of_parse_and_map(dev, index, );
+   if (ret)
+   return ret;
 
/* Only dereference the resource if both the
 * resource and the irq are valid. */
@@ -364,7 +372,7 @@ int of_irq_to_resource(struct device_node *dev, int index, 
struct resource *r)
r->name = name ? name : dev->full_name;
}
 
-   return irq;
+   return 0;
 }
 EXPORT_SYMBOL_GPL(of_irq_to_resource);
 
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 11da949..6d62b73 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -67,7 +67,7 @@ extern int of_irq_map_one(struct device_node *device, int 
index,
 extern int irq_create_of_mapping(struct device_node *controller,
 const u32 *intspec, unsigned int intsize,
 unsigned int *virqp);
-extern int of_irq_to_resource(struct device_node *dev, int index,
+extern int of_irq_to_resource(struct device_node *dev, unsigned int index,
  struct resource *r);
 extern int of_irq_count(struct device_node *dev);
 extern int of_irq_to_resource_table(struct device_node *dev,
-- 
1.8.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 10/10] gpio: tegra: Use module_platform_driver()

[Thierry Reding]

With the driver core now resolving interrupt references at probe time,
it is no longer necessary to force explicit probe ordering using
initcalls.

Signed-off-by: Thierry Reding 
---
Note that there are potentially many more drivers that can be switched
to the generic module_*_driver() interfaces now that interrupts can be
resolved later and deferred probe should be able to handle all the
ordering issues.

 drivers/gpio/gpio-tegra.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 9a62672..766e6ef 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -513,12 +513,7 @@ static struct platform_driver tegra_gpio_driver = {
},
.probe  = tegra_gpio_probe,
 };
-
-static int __init tegra_gpio_init(void)
-{
-   return platform_driver_register(_gpio_driver);
-}
-postcore_initcall(tegra_gpio_init);
+module_platform_driver(tegra_gpio_driver);
 
 #ifdef CONFIG_DEBUG_FS
 
-- 
1.8.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 09/10] of/i2c: Resolve interrupt references at probe time

[Thierry Reding]

Instead of resolving interrupt references at device creation time, delay
resolution until probe time. At device creation time, there is nothing
that can be done if an interrupt parent isn't ready yet, and the device
will end up with an invalid interrupt number (0).

If the interrupt reference is resolved at probe time, the device's probe
can be deferred, so that it's interrupt resolution can be retried after
more devices (possibly including its interrupt parent) have been probed.

However, individual drivers shouldn't be required to do that themselves,
over and over again, so this commit implements this functionality within
the I2C core.

Signed-off-by: Thierry Reding 
---
Changes in v2:
- use __irq_of_parse_and_map() instead of of_irq_get()

 drivers/i2c/i2c-core.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 29d3f04..5b4f289 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -236,6 +236,22 @@ int i2c_recover_bus(struct i2c_adapter *adap)
return adap->bus_recovery_info->recover_bus(adap);
 }
 
+static int of_i2c_probe(struct i2c_client *client)
+{
+   struct device_node *np = client->dev.of_node;
+   int ret;
+
+   /* skip if the device node specifies no interrupts */
+   if (of_get_property(np, "interrupts", NULL)) {
+   ret = __irq_of_parse_and_map(client->dev.of_node, 0,
+>irq);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
 static int i2c_device_probe(struct device *dev)
 {
struct i2c_client   *client = i2c_verify_client(dev);
@@ -254,6 +270,12 @@ static int i2c_device_probe(struct device *dev)
client->flags & I2C_CLIENT_WAKE);
dev_dbg(dev, "probe\n");
 
+   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
+   status = of_i2c_probe(client);
+   if (status)
+   return status;
+   }
+
status = driver->probe(client, i2c_match_id(driver->id_table, client));
if (status) {
client->driver = NULL;
@@ -1002,7 +1024,6 @@ static void of_i2c_register_devices(struct i2c_adapter 
*adap)
continue;
}
 
-   info.irq = irq_of_parse_and_map(node, 0);
info.of_node = of_node_get(node);
info.archdata = _ad;
 
@@ -1016,7 +1037,6 @@ static void of_i2c_register_devices(struct i2c_adapter 
*adap)
dev_err(>dev, "of_i2c: Failure registering %s\n",
node->full_name);
of_node_put(node);
-   irq_dispose_mapping(info.irq);
continue;
}
}
-- 
1.8.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 04/10] irqdomain: Return errors from irq_create_of_mapping()

[Thierry Reding]

Instead of returning 0 for all errors, allow the precise error code to
be propagated. This will be used in subsequent patches to allow further
propagation of error codes.

The interrupt number corresponding to the new mapping is returned in an
output parameter so that the return value is reserved to signal success
(== 0) or failure (< 0).

Signed-off-by: Thierry Reding 
---
Changes in v2:
- convert existing callers instead of using compatible wrapper

 arch/arm/mach-integrator/pci_v3.c  |  8 ++--
 arch/microblaze/pci/pci-common.c   |  6 --
 arch/mips/pci/fixup-lantiq.c   | 12 +++
 arch/mips/pci/pci-rt3883.c |  9 +
 arch/powerpc/kernel/pci-common.c   |  7 +--
 arch/powerpc/platforms/cell/celleb_scc_sio.c   |  8 +---
 arch/powerpc/platforms/cell/spu_manage.c   |  6 +++---
 arch/powerpc/platforms/fsl_uli1575.c   |  7 +++
 arch/powerpc/platforms/pseries/event_sources.c | 12 ++-
 arch/x86/kernel/devicetree.c   | 11 +-
 drivers/pci/host/pci-mvebu.c   |  9 +++--
 include/linux/of_irq.h |  6 +++---
 kernel/irq/irqdomain.c | 28 --
 13 files changed, 78 insertions(+), 51 deletions(-)

diff --git a/arch/arm/mach-integrator/pci_v3.c 
b/arch/arm/mach-integrator/pci_v3.c
index bef1005..aa0f867 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -847,8 +847,12 @@ static int __init pci_v3_map_irq_dt(const struct pci_dev 
*dev, u8 slot, u8 pin)
return 0;
}
 
-   return irq_create_of_mapping(oirq.controller, oirq.specifier,
-oirq.size);
+   ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
+   oirq.size, );
+   if (ret)
+   return 0;
+
+   return virq;
 }
 
 static int __init pci_v3_dtprobe(struct platform_device *pdev,
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 1b93bf0..80b6e0f 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -246,8 +246,10 @@ int pci_read_irq_line(struct pci_dev *pci_dev)
 oirq.size, oirq.specifier[0], oirq.specifier[1],
 of_node_full_name(oirq.controller));
 
-   virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
-oirq.size);
+   ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
+   oirq.size, );
+   if (ret)
+   virq = 0;
}
if (!virq) {
pr_debug(" Failed to map !\n");
diff --git a/arch/mips/pci/fixup-lantiq.c b/arch/mips/pci/fixup-lantiq.c
index 6c829df..dfe7bf1 100644
--- a/arch/mips/pci/fixup-lantiq.c
+++ b/arch/mips/pci/fixup-lantiq.c
@@ -26,15 +26,19 @@ int pcibios_plat_dev_init(struct pci_dev *dev)
 int __init pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
struct of_irq dev_irq;
-   int irq;
+   unsigned int irq;
+   int err;
 
if (of_irq_map_pci(dev, _irq)) {
dev_err(>dev, "trying to map irq for unknown slot:%d 
pin:%d\n",
slot, pin);
return 0;
}
-   irq = irq_create_of_mapping(dev_irq.controller, dev_irq.specifier,
-   dev_irq.size);
-   dev_info(>dev, "SLOT:%d PIN:%d IRQ:%d\n", slot, pin, irq);
+   err = irq_create_of_mapping(dev_irq.controller, dev_irq.specifier,
+   dev_irq.size, );
+   if (err)
+   return 0;
+
+   dev_info(>dev, "SLOT:%d PIN:%d IRQ:%u\n", slot, pin, irq);
return irq;
 }
diff --git a/arch/mips/pci/pci-rt3883.c b/arch/mips/pci/pci-rt3883.c
index 95c9d41..79b49b5 100644
--- a/arch/mips/pci/pci-rt3883.c
+++ b/arch/mips/pci/pci-rt3883.c
@@ -584,8 +584,8 @@ err_put_intc_node:
 int __init pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
struct of_irq dev_irq;
+   unsigned int irq = 0;
int err;
-   int irq;
 
err = of_irq_map_pci(dev, _irq);
if (err) {
@@ -594,11 +594,12 @@ int __init pcibios_map_irq(const struct pci_dev *dev, u8 
slot, u8 pin)
return 0;
}
 
-   irq = irq_create_of_mapping(dev_irq.controller,
+   err = irq_create_of_mapping(dev_irq.controller,
dev_irq.specifier,
-   dev_irq.size);
+   dev_irq.size,
+   );
 
-   if (irq == 0)
+   if (err)
pr_crit("pci %s: no irq found for pin %u\n",
pci_name((struct pci_dev *) dev), pin);
else
diff --git 

Re: [RFC][PATCH] rtc: rtc-pl031: Set wakeup flag prior to registering rtcdev

[John Stultz]

On Wed, Sep 18, 2013 at 6:30 AM, Linus Walleij  wrote:
>
> On Tue, Sep 17, 2013 at 8:29 PM, John Stultz  wrote:
>
> > In some recent testing, I noticed the CLOCK_REALTIME_ALARM clockid
> > wasn't functioning on my vexpress qemu environment. Looking into it
> > I noticed the pl031 rtc driver doesn't set the wakeup flag on the
> > device until after registering the device with the RTC subsystem.
> >
> > This causes the alarmtimer subsystem to not see the pl031 driver
> > as a valid backing device, and that resuls in alarm clockids
> > getting ENOTSUPP errors.
> >
> > Thus be sure to set the wakeup flag on the device prior to
> > registering the rtcdev so the pl031 rtc driver can be used as
> > the backing alarmtimer device.
> >
> > Let me know if you have any feedback or objections to this.
> > If it looks ok, I'll queue it for 3.13. I suspect there
> > may be other RTC drivers with the same problem.
> >
> > Cc: Linus Walleij 
> > Cc: Alessandro Zummo 
> > Cc: "Jon Medhurst (Tixy)" 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: John Stultz 
>
> Makes perfect sense. I have only tested the driver from regular
> userspace using ioctl()s. Is these a simple way to test
> an alarmtimer on a barebones system?

The easiest way is to try to read CLOCK_REALTIME_ALARM which will only
function if there's a backing rtc.

I've got some further timekeeping tests here that will test timers etc
on the _ALARM clockids:
https://github.com/johnstultz-work/timetests


> Acked-by: Linus Walleij 
>
> Are you sure this should not be for -rc:s and stable?

Its not a regression (never worked before), so I don't think so,
unless someone finds the functionality critical for long-term kernels.

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/10] of/irq: Use irq_of_parse_and_map()

[Thierry Reding]

Replace some instances of of_irq_map_one()/irq_create_of_mapping() and
of_irq_to_resource() by the simpler equivalent irq_of_parse_and_map().

Signed-off-by: Thierry Reding 
---
 arch/arm/mach-u300/timer.c   |  9 -
 arch/powerpc/platforms/cell/celleb_scc_pciex.c   |  8 +++-
 arch/powerpc/platforms/cell/spider-pic.c |  7 ++-
 arch/powerpc/sysdev/fsl_gtm.c|  9 -
 arch/powerpc/sysdev/mpic_msgr.c  |  6 ++
 drivers/crypto/caam/ctrl.c   |  2 +-
 drivers/crypto/caam/jr.c |  2 +-
 drivers/crypto/omap-sham.c   |  2 +-
 drivers/i2c/busses/i2c-cpm.c |  2 +-
 drivers/input/serio/xilinx_ps2.c |  7 ---
 drivers/net/ethernet/arc/emac_main.c | 10 +-
 drivers/net/ethernet/freescale/fs_enet/mac-fcc.c |  2 +-
 drivers/net/ethernet/freescale/fs_enet/mac-fec.c |  2 +-
 drivers/net/ethernet/freescale/fs_enet/mac-scc.c |  2 +-
 drivers/spi/spi-fsl-espi.c   |  6 +++---
 drivers/tty/serial/cpm_uart/cpm_uart_core.c  |  2 +-
 16 files changed, 35 insertions(+), 43 deletions(-)

diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index b5db207..9a5f9fb 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/arm/mach-u300/timer.c
@@ -358,8 +358,7 @@ static struct delay_timer u300_delay_timer;
  */
 static void __init u300_timer_init_of(struct device_node *np)
 {
-   struct resource irq_res;
-   int irq;
+   unsigned int irq;
struct clk *clk;
unsigned long rate;
 
@@ -368,11 +367,11 @@ static void __init u300_timer_init_of(struct device_node 
*np)
panic("could not ioremap system timer\n");
 
/* Get the IRQ for the GP1 timer */
-   irq = of_irq_to_resource(np, 2, _res);
-   if (irq <= 0)
+   irq = irq_of_parse_and_map(np, 2);
+   if (!irq)
panic("no IRQ for system timer\n");
 
-   pr_info("U300 GP1 timer @ base: %p, IRQ: %d\n", u300_timer_base, irq);
+   pr_info("U300 GP1 timer @ base: %p, IRQ: %u\n", u300_timer_base, irq);
 
/* Clock the interrupt controller */
clk = of_clk_get(np, 0);
diff --git a/arch/powerpc/platforms/cell/celleb_scc_pciex.c 
b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
index 14be2bd..856ad64 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
@@ -486,8 +486,7 @@ static __init int celleb_setup_pciex(struct device_node 
*node,
 struct pci_controller *phb)
 {
struct resource r;
-   struct of_irq oirq;
-   int virq;
+   unsigned int virq;
 
/* SMMIO registers; used inside this file */
if (of_address_to_resource(node, 0, )) {
@@ -507,12 +506,11 @@ static __init int celleb_setup_pciex(struct device_node 
*node,
phb->ops = _pciex_pci_ops;
 
/* internal interrupt handler */
-   if (of_irq_map_one(node, 1, )) {
+   virq = irq_of_parse_and_map(node, 1);
+   if (!virq) {
pr_err("PCIEXC:Failed to map irq\n");
goto error;
}
-   virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
-oirq.size);
if (request_irq(virq, pciex_handle_internal_irq,
0, "pciex", (void *)phb)) {
pr_err("PCIEXC:Failed to request irq\n");
diff --git a/arch/powerpc/platforms/cell/spider-pic.c 
b/arch/powerpc/platforms/cell/spider-pic.c
index 8e29944..1f72f4a 100644
--- a/arch/powerpc/platforms/cell/spider-pic.c
+++ b/arch/powerpc/platforms/cell/spider-pic.c
@@ -235,12 +235,9 @@ static unsigned int __init 
spider_find_cascade_and_node(struct spider_pic *pic)
/* First, we check whether we have a real "interrupts" in the device
 * tree in case the device-tree is ever fixed
 */
-   struct of_irq oirq;
-   if (of_irq_map_one(pic->host->of_node, 0, ) == 0) {
-   virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
-oirq.size);
+   virq = irq_of_parse_and_map(pic->host->of_node, 0);
+   if (virq)
return virq;
-   }
 
/* Now do the horrible hacks */
tmp = of_get_property(pic->host->of_node, "#interrupt-cells", NULL);
diff --git a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
index 0eb871c..dd0d5be 100644
--- a/arch/powerpc/sysdev/fsl_gtm.c
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -401,16 +401,15 @@ static int __init fsl_gtm_init(void)
gtm->clock = *clock;
 
for (i = 0; i < ARRAY_SIZE(gtm->timers); i++) {
-   int ret;
-   struct resource irq;
+   unsigned int irq;
 
-   ret = of_irq_to_resource(np, i, );
-   if (ret == NO_IRQ) {
+  

Re: trinity finds ftrace/perf bug. Film at 11.

[Dave Jones]

On Wed, Sep 18, 2013 at 01:34:11PM +0200, Peter Zijlstra wrote:
 > On Mon, Sep 16, 2013 at 12:44:21PM -0400, Dave Jones wrote:
 > > 
 > > may be some other option.. Try 
 > > http://www.codemonkey.org.uk/junk/haswell-config
 > > 
 > >  > What kind of hardware are you running this on?
 > > 
 > > model name : Intel(R) Core(TM) i5-4670T CPU @ 2.30GHz
 > 
 > Humpf,.. of course I don't have a hsw system :/
 > 
 > I'll try raising the -C count to 4*nr_cpus for the next few runs.
 > 
 > OK, seems I need to edit trinity for that, someone thought 64 was a big
 > number.

heh, at one time, the walk through the list of child processes in watchdog.c was
taking so long that it considered children that hadn't been scheduled for
a while as stuck. I'm not sure that's any better right now, so you might have
to modify that code too.

Dave

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

Re: [PATCH V4 00/17] ARM EFI stub common code

[Matt Fleming]

On Mon, 16 Sep, at 09:11:16PM, Roy Franz wrote:
> This patch is the common/x86 portion of the ARM EFI stub
> patchset broken out.  These changes support the addition
> of EFI stub support for the ARM and ARM64 architectures.
> The common code that is now shared in efi-stub-helper.c
> is based on code in the x86 stub that has been generalized
> to support other architectures.

Apart from PATCH 8/17, these all look good to me and work on my test
machines.

If you can respin PATCH 8 based on my comments I'll pull this series
into my efi tree and get it into linux-next.

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

Re: [PATCH 2/4] ARM: STi: Supply I2C configuration to STiH416 SoC

[Srinivas KANDAGATLA]

On 18/09/13 13:46, Maxime COQUELIN wrote:
> On 09/18/2013 02:03 PM, Lee Jones wrote:
>>> >> This patch supplies I2C configuration to STiH416 SoC.
>>> >>
>>> >> Cc: Srinivas Kandagatla 
>>> >> Signed-off-by: Maxime Coquelin 
>>> >> ---
>>> >>  arch/arm/boot/dts/stih416-pinctrl.dtsi |   35 
>>> >>  arch/arm/boot/dts/stih416.dtsi |   57 
>>> >> 
>>> >>  2 files changed, 92 insertions(+)
>>> >>
>>> >> diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi 
>>> >> b/arch/arm/boot/dts/stih416-pinctrl.dtsi
>> > I genuinely don't know the answer to this question, but are these
>> > nodes identical to the ones you've just put in the stih415 DTSI file?
>> > If so, I think it will be worth creating a stih41x DTSI rather than
>> > duplicating lots of stuff unnecessarily.
> There are close to be identical indeed.
> For the clocks and pinctrl, the references names are the same, but they are
> pointing on different nodes, as STiH415 and STiH416 have their own
> clocks and pinctrl dtsi files.
> 
> Srini, what is opinion about this?

There is already a stih41x.dtsi file, but I don't think it is the right
place for the pinctrl nodes there.

Am not OK with the idea of common pinctrl nodes for STiH415 and STiH416
for two reasons.

1> If we common up the pinctrl nodes, it will be very difficult to
accommodate new pinctrls layout which is not guaranteed to be in same
layout in future SOCs.

2> The retiming values in the pinctrl nodes tend to change as per SOC,
so it will be difficult to manage it if we common it up.

Am sure we can come up with a dt layout which can reduce duplication,
but we have to be careful here not to lose the flexiblity to accommodate
new picntrl layouts, new retimings values based on SOC.


thanks,
srini

>> >

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] i2c: busses: i2c-st: Add ST I2C controller

[Gabriel FERNANDEZ]

On 18/09/2013 12:01, Maxime COQUELIN wrote:
> This patch adds support to SSC (Synchronous Serial Controller)
> I2C driver. This IP also supports SPI protocol, but this is not
> the aim of this driver.
>
> This IP is embedded in all ST SoCs for Set-top box platorms, and
> supports I2C Standard and Fast modes.
>
> Cc: Srinivas Kandagatla 
> Signed-off-by: Maxime Coquelin 
> ---
>   Documentation/devicetree/bindings/i2c/i2c-st.txt |   35 ++
>   drivers/i2c/busses/Kconfig   |   10 +
>   drivers/i2c/busses/Makefile  |1 +
>   drivers/i2c/busses/i2c-st.c  |  713 
> ++
>   drivers/i2c/busses/i2c-st.h  |  216 +++
>   5 files changed, 975 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st.txt
>   create mode 100644 drivers/i2c/busses/i2c-st.c
>   create mode 100644 drivers/i2c/busses/i2c-st.h
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> new file mode 100644
> index 000..a7d6381
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
> @@ -0,0 +1,35 @@
> +I2C for ST platforms
> +
> +Required properties :
> +- compatible : Must be "st,comms-i2c"
> +- reg : Offset and length of the register set for the device
> +- interrupts : the interrupt number
> +- clocks : phandle to the I2C clock source
> +
> +Recommended (non-standard) properties :
> +- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
> +  the default 100 kHz frequency will be used. As only Normal and Fast modes
> +  are supported, possible values are 10 and 40.
> +
> +Optional (non-standard) properties:
> +- st,glitches : Enable timing glitch suppression support.
> +- st,glitch-clk : SCL line timinig glitch suppression value in ns.
> +- st,glitch-dat : SDA line timinig glitch suppression value in ns.
> +- st,hw-glitches : Enable filter glitch suppression support.
> +- st,hw-glitch-clk : SCL line filter glitch suppression value in us.
> +- st,hw-glitch-dat : SDA line filter glitch suppression value in us.
> +
> +Examples :
> +
> +i2c0: i2c@fed4{

Space before the '{'

> +   compatible  = "st,comms-i2c";
> +   reg = <0xfed4 0x110>;
> +   interrupts  =  ;
> +   clocks  = <_S_ICN_REG_0>;
> +   clock-frequency = <40>;
> +   pinctrl-names   = "default";
> +   pinctrl-0   = <_i2c0_default>;
> +   st,glitches;
> +   st,glitch-clk   = 500;
> +   st,glitch-dat   = 500;
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index cdcbd83..18ff129 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -776,6 +776,16 @@ config I2C_RCAR
>This driver can also be built as a module.  If so, the module
>will be called i2c-rcar.
>
> +config I2C_ST
> +   tristate "STMicroelectronics SSC I2C support"
> +   depends on ARCH_STI
> +   help
> + Enable this option to add support for STMicroelectronics SoCs
> + hardware SSC (Synchronous Serial Controller) as an I2C controller.
> +
> + This driver can also be built as module. If so, the module
> + will be called i2c-st.
> +
>   comment "External I2C/SMBus adapter drivers"
>
>   config I2C_DIOLAN_U2C
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index d00997f..9ea5d422 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -92,5 +92,6 @@ obj-$(CONFIG_I2C_PCA_ISA) += i2c-pca-isa.o
>   obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
>   obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
>   obj-$(CONFIG_SCx200_I2C)   += scx200_i2c.o
> +obj-$(CONFIG_I2C_ST)   += i2c-st.o
>
>   ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
> diff --git a/drivers/i2c/busses/i2c-st.c b/drivers/i2c/busses/i2c-st.c
> new file mode 100644
> index 000..fa4451f
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-st.c
> @@ -0,0 +1,713 @@
> +/*
> + * Copyright (C) 2013 STMicroelectronics
> + *
> + * I2C master mode controller driver, used in STMicroelectronics devices.
> + *
> + * Author: Maxime Coquelin 
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "i2c-st.h"
> +
> +#define DRIVER_NAME "st-i2c"
> +
> +static struct st_i2c_timings i2c_timings[] = {
> +   [I2C_MODE_STANDARD] = {
> +   .rate   = 10,
> +   .rep_start_hold = 4000,
> +   .rep_start_setup= 4700,
> +   .start_hold = 4000,
> +   .data_setup_time= 250,
> 

Re: [PATCH v2] ADP1653 board code for Nokia RX-51

[Pavel Machek]

On Sun 2013-09-08 02:02:52, Aaro Koskinen wrote:
> Hi,
> 
> On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote:
> > > --- /dev/null
> > > +++ b/arch/arm/mach-omap2/board-rx51-camera.c
> [...]
> > Ping, can you review this patch v2?
> 
> I don't think Tony will accept any new board stuff for RX-51/N900.
> See for example: http://marc.info/?l=linux-kernel=137629626213187=2
> 
> There should be initial Nokia N900 DTS file in 3.12-rc1, and we should
> continue converting this board fully to DT.

That's not reasonable. N900 is pretty far away from working with
device tree. Yes, I was able to get some bits merged, but that should
not be excuse to halt other N900 development.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] vsprintf: ignore %n again

[Tetsuo Handa]

Kees Cook wrote:
> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
> > and __vsnprintf(0, s, n, fmt, ...) otherwise.  Now,
> > int __sprintf(int safe, char *buf, const char *fmt, ...)
> > {
> > va_list args;
> > int i;
> >
> > va_start(args, fmt);
> > i = __vsnprintf(safe, buf, INT_MAX, fmt, args);
> > va_end(args);
> >
> > return i;
> > }
> 
> Unless I've misunderstood, I think we'd already get very close to this
> with the gcc options instead. This patch set is what I've been using
> to generate the format string fixes over the last few months, with 7
> sent this last round:

Can we utilize __builtin_constant_p() ?

-- source start --
#include 

#define func(fmt)   \
if (__builtin_constant_p(fmt))  \
printf("const : %s\n", fmt);\
else\
printf("not const : %s\n", fmt);\


int main(int argc, char *argv[])
{
const char *fmt1 = "const char *";
const char fmt2[] = "const char []";
const char * const fmt3 = "const char * const";
func("literal");
func(fmt1);
func(fmt2);
func(fmt3);
return 0;
}
-- source end --

-- output start --
const : literal
not const : const char *
not const : const char []
const : const char * const
-- output end --

__builtin_constant_p() seems to enforce use of either "literal" or "* const".

An example change

-- patch start --
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -120,8 +120,9 @@ asmlinkage int printk_emit(int facility, int level,
   const char *dict, size_t dictlen,
   const char *fmt, ...);
 
-asmlinkage __printf(1, 2) __cold
-int printk(const char *fmt, ...);
+//asmlinkage __printf(1, 2) __cold
+//int printk(const char *fmt, ...);
+#define printk(fmt, ...) compiletime_assert(__builtin_constant_p(fmt), "Non-c  
onstant format string")
 
 /*
  * Special printk facility for scheduler use only, _DO_NOT_USE_ !
-- patch end --

caught errors like below.

  CC [M]  drivers/scsi/esas2r/esas2r_log.o
drivers/scsi/esas2r/esas2r_log.c: In function 'esas2r_log_master':
drivers/scsi/esas2r/esas2r_log.c:174: error: call to '__compiletime_assert_174' 
declared with attribute error: Non-constant format string
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] uio: Simplify uio error path by using devres functions

[Pavel Machek]

On Thu 2013-09-12 07:39:59, Michal Simek wrote:
> Using devres functions simplify driver error path.
> - Use devm_kzalloc
> - Use devm_request_irq
> 
> Signed-off-by: Michal Simek 

Reviewed-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf: Support for Openembedded/Yocto -dbg packages

[Arnaldo Carvalho de Melo]

Em Wed, Sep 18, 2013 at 12:18:01PM +0200, Peter Zijlstra escreveu:
> On Wed, Sep 18, 2013 at 12:02:12PM +0200, Ricardo Ribalda Delgado wrote:
> > Perhaps this is even more clear than v2:

> > len = snprintf(file, size, "%s", symbol_conf.symfs);
> > size -= len;
> > file += len;
> > len = snprintf(file, MIN(size,(last_slash - dso->long_name) + 2),
> > "%s",  dso->long_name);
> > size -= len;
> > file += len;
> > len = snprintf(file, size, ".debug%s",  last_slash);

> len = 0;

> len += snprintf(str + len, size - len, ...);
> len += snprintf(str + len, size - len, ...);

And avoid snprintf like the plague, use scnprintf instead...  See
e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 for details :-)

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 REPOST] ARM: tegra: use dt-binding header for key code

[Laxman Dewangan]

In place of hardcoding the key code in DTS file and comment the
key code as side notes, use the key code macro defines in the
dt-bindings/input/input.h directly.

Signed-off-by: Laxman Dewangan 
---
Reposting this patch as it was sent earlier when merge window was closed.

 arch/arm/boot/dts/tegra114-dalmore.dts |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
b/arch/arm/boot/dts/tegra114-dalmore.dts
index 6023028..05a3aae 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -1,5 +1,6 @@
 /dts-v1/;
 
+#include 
 #include "tegra114.dtsi"
 
 / {
@@ -1081,26 +1082,26 @@
home {
label = "Home";
gpios = < TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
-   linux,code = <102>; /* KEY_HOME */
+   linux,code = ;
};
 
power {
label = "Power";
gpios = < TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
-   linux,code = <116>; /* KEY_POWER */
+   linux,code = ;
gpio-key,wakeup;
};
 
volume_down {
label = "Volume Down";
gpios = < TEGRA_GPIO(R, 1) GPIO_ACTIVE_LOW>;
-   linux,code = <114>; /* KEY_VOLUMEDOWN */
+   linux,code = ;
};
 
volume_up {
label = "Volume Up";
gpios = < TEGRA_GPIO(R, 2) GPIO_ACTIVE_LOW>;
-   linux,code = <115>; /* KEY_VOLUMEUP */
+   linux,code = ;
};
};
 
-- 
1.7.1.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: [Suspend-devel] [BUG] 3.7-rc regression bisected: s2disk fails to resume image: Processes could not be frozen, cannot continue resuming

[Pavel Machek]

On Thu 2013-09-12 12:32:17, Andrew Savchenko wrote:
> Hello,
> 
> On Thu, 05 Sep 2013 14:23:25 +0200 Rafael J. Wysocki wrote:
> > On Thursday, September 05, 2013 02:08:11 PM Pavel Machek wrote:
> > > Hi!
> > > 
> > > Rafael, Al: apparently we have a regression caused by
> > > ba4df2808a86f8b103c4db0b8807649383e9bd13 .
> > 
> > I noticed that, but I'm not sure how to deal with it.
> > 
> > Also, s2disk still works on my test machines, so that seems to be
> > specific to this particular configuration.
> 
> Is there any way to debug this issue further than just bisecting
> commit? Perhaps suspend ioctl should be traced to see why it fails,
> but I don't know what exactly inside the kernel should be debugged
> and how.

If revert of ba4df2808a86f8b103c4db0b8807649383e9bd13 fixes it, then I
guess it should be just reverted...
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 1/2] PM / Hibernate: use name_to_dev_t to parse resume

[Pavel Machek]

On Tue 2013-09-17 13:50:21, Sebastian Capella wrote:
> Quoting Sebastian Capella (2013-08-30 11:42:30)
> > Quoting Pavel Machek (2013-08-30 04:35:33)
> > > On Mon 2013-08-26 10:40:50, Sebastian Capella wrote:
> > > > Quoting Pavel Machek (2013-08-25 08:38:11)
> > > > > Is the allocation actually neccessary? At the very least this should
> > > > > test for NULL...
> > > > 
> > > > name_to_dev_t expects a non-const name, but the buffer passed in
> > > > is const.  I also am removing the '\n' if found at the end of the
> > > > string which would violate the const.
> > > 
> > > Fix name_to_dev_t, then. No need to do memory allocation just to work
> > > around const.
> > > 
> > Hi Pavel,
> > 
> > The issue is really Removing the \n from the user space input.  The
> > flow is:
> > const input buf -> copy to work buffer, remove newline -> name_to_dev_t
> > 
> >   ssize_t resume_store(..., const char *buf, size_t n)
> >   // copy buf, strip off trailing newline, pass to name_to_dev_t
> >   dev_t name_to_dev_t(char *name)
> > 
> > The const in the restore_store buffer comes from the function type of the
> > store member of the kobj_attribute.  I don't believe this should be changed.
> > 
> > Currently, name_to_dev_t will fail in some cases if a trailing \n is 
> > present.
> > Is it more appropriate to handle stripping the newline in the store
> > function rather than modifying name_to_dev_t to clean it up?
> > 
> > It seems logical for name_to_dev_t to take a const name parameter as
> > there should be no reason to modify the name buffer passed to it.
> > I'll be happy to make a patch to do this, but without hardening
> > name_to_dev_t against trailing newlines, it would not be neccesary for
> > this problem.
> > 
> > Thanks for your time and comments!
> > 
> 
> Hi Pavel,
> 
> Do you have any more feedback regarding leaving the strndup?

I think you should modify name_to_dev_t, then. Doing memory allocation
just to work around \n limitation is ugly.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i2c: mv64xxx: Fix some build warnings

[Thierry Reding]

Some functions and variables are only used if the configuration selects
HAVE_CLK. Protect them with a corresponding #ifdef CONFIG_HAVE_CLK block
to avoid compiler warnings.

Signed-off-by: Thierry Reding 
---
 drivers/i2c/busses/i2c-mv64xxx.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 5aead74..bfd870c 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -697,6 +697,7 @@ static const struct of_device_id 
mv64xxx_i2c_of_match_table[] = {
 MODULE_DEVICE_TABLE(of, mv64xxx_i2c_of_match_table);
 
 #ifdef CONFIG_OF
+#ifdef CONFIG_HAVE_CLK
 static int
 mv64xxx_calc_freq(const int tclk, const int n, const int m)
 {
@@ -726,16 +727,12 @@ mv64xxx_find_baud_factors(const u32 req_freq, const u32 
tclk, u32 *best_n,
return false;
return true;
 }
+#endif
 
 static int
 mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
  struct device *dev)
 {
-   const struct of_device_id *device;
-   struct device_node *np = dev->of_node;
-   u32 bus_freq, tclk;
-   int rc = 0;
-
/* CLK is mandatory when using DT to describe the i2c bus. We
 * need to know tclk in order to calculate bus clock
 * factors.
@@ -744,6 +741,11 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
/* Have OF but no CLK */
return -ENODEV;
 #else
+   const struct of_device_id *device;
+   struct device_node *np = dev->of_node;
+   u32 bus_freq, tclk;
+   int rc = 0;
+
if (IS_ERR(drv_data->clk)) {
rc = -ENODEV;
goto out;
-- 
1.8.4

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

Re: linux-next stats (Was: Linux 3.12-rc1)

[Jason Cooper]

Stephen,

On Tue, Sep 17, 2013 at 03:50:57PM +1000, Stephen Rothwell wrote:
> There are also 358 commits in next-20130701 that didn't make it into 
> v3.11-rc1.
> 
> Top ten first word of commit summary:
> 
>  56 arm
> 
> Top ten authors:
> 
>  13 Sebastian Hesselbarth 
> 
> Top ten commiters:
> 
>  22 Jason Cooper 

:(  That's my mistake.  I should've been tracking my pull requests to
arm-soc more closely.  We've already tweaked the process to prevent this
in the future.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c: mv64xxx: Do not use writel_relaxed()

[Thierry Reding]

The driver is used on PowerPC which don't provide writel_relaxed(). This
breaks the c2k and prpmc2800 default configurations. To fix the build,
turn the calls to writel_relaxed() into writel(). The impacts for ARM
should be minimal.

Signed-off-by: Thierry Reding 
---
 drivers/i2c/busses/i2c-mv64xxx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 7f3a474..5aead74 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -234,9 +234,9 @@ static int mv64xxx_i2c_offload_msg(struct mv64xxx_i2c_data 
*drv_data)
ctrl_reg |= MV64XXX_I2C_BRIDGE_CONTROL_WR |
(msg->len - 1) << MV64XXX_I2C_BRIDGE_CONTROL_TX_SIZE_SHIFT;
 
-   writel_relaxed(data_reg_lo,
+   writel(data_reg_lo,
drv_data->reg_base + MV64XXX_I2C_REG_TX_DATA_LO);
-   writel_relaxed(data_reg_hi,
+   writel(data_reg_hi,
drv_data->reg_base + MV64XXX_I2C_REG_TX_DATA_HI);
 
} else {
-- 
1.8.4

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

[PATCH] net: tsi108: Prevent compiler warning

[Thierry Reding]

The dump_eth_one() function is only used if DEBUG is enabled, so protect
it by a corresponding #ifdef DEBUG block.

Signed-off-by: Thierry Reding 
---
 drivers/net/ethernet/tundra/tsi108_eth.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/tundra/tsi108_eth.c 
b/drivers/net/ethernet/tundra/tsi108_eth.c
index c4dbf98..a452d93 100644
--- a/drivers/net/ethernet/tundra/tsi108_eth.c
+++ b/drivers/net/ethernet/tundra/tsi108_eth.c
@@ -168,6 +168,7 @@ static struct platform_driver tsi_eth_driver = {
 
 static void tsi108_timed_checker(unsigned long dev_ptr);
 
+#ifdef DEBUG
 static void dump_eth_one(struct net_device *dev)
 {
struct tsi108_prv_data *data = netdev_priv(dev);
@@ -192,6 +193,7 @@ static void dump_eth_one(struct net_device *dev)
   TSI_READ(TSI108_EC_RXESTAT),
   TSI_READ(TSI108_EC_RXERR), data->rxpending);
 }
+#endif
 
 /* Synchronization is needed between the thread and up/down events.
  * Note that the PHY is accessed through the same registers for both
-- 
1.8.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] radeon: Conditionally compile PM code

[Thierry Reding]

The power management code is only used on X86 and PowerMac. To prevent
the compiler from warning about unused code, only build when PM and one
of X86 or PowerMac is selected.

Signed-off-by: Thierry Reding 
---
 drivers/video/aty/radeon_pm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
index f7091ec..f4317f1 100644
--- a/drivers/video/aty/radeon_pm.c
+++ b/drivers/video/aty/radeon_pm.c
@@ -1427,6 +1427,8 @@ static void radeon_pm_full_reset_sdram(struct 
radeonfb_info *rinfo)
mdelay( 15);
 }
 
+#if defined(CONFIG_PM)
+#if defined(CONFIG_X86) || defined(CONFIG_PPC_PMAC)
 static void radeon_pm_reset_pad_ctlr_strength(struct radeonfb_info *rinfo)
 {
u32 tmp, tmp2;
@@ -1939,9 +1941,10 @@ static void radeon_reinitialize_M10(struct radeonfb_info 
*rinfo)
 */
radeon_pm_m10_enable_lvds_spread_spectrum(rinfo);
 }
+#endif
 
 #ifdef CONFIG_PPC_OF
-
+#ifdef CONFIG_PPC_PMAC
 static void radeon_pm_m9p_reconfigure_mc(struct radeonfb_info *rinfo)
 {
OUTREG(MC_CNTL, rinfo->save_regs[46]);
@@ -2202,6 +2205,8 @@ static void radeon_reinitialize_M9P(struct radeonfb_info 
*rinfo)
radeon_pm_restore_pixel_pll(rinfo);
radeon_pm_m10_enable_lvds_spread_spectrum(rinfo);
 }
+#endif
+#endif
 
 #if 0 /* Not ready yet */
 static void radeon_reinitialize_QW(struct radeonfb_info *rinfo)
-- 
1.8.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: [GIT PULL] Keyrings patches

[Mimi Zohar]

On Wed, 2013-09-18 at 12:53 +0100, David Howells wrote:
> Stephen Rothwell  wrote:
> 
> > Is there some reason that those fixups cannot be done in a merge commit?
> > i.e. are they more than simple text updates?

Hi Stephen, the issue is that the patches were created against a newer
kernel (eg. next, akpm, Linus' branch), not the earlier one.  So it
isn't a merge issue per se.  Now that -rc1 is out, James will rebase
soon.

Mimi

> That's somewhat up to James.  *He* would be the person doing the merge, not
> me.  I'm changing the lines in my patches also.
> 
> > /me thinks that most rebases people do can be better done (and
> > documented) as merges.
> 
> That depends on how you define "better".  Better for what?  I think it's
> better to absorb the changes into my patch series.  StGIT is very good for
> handling this, since my patches are currently maintained as an StGIT set.
> That way, there ends up one fewer commit in the history, assuming no other
> collisions with what James merges.
> 
> David



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

Re: [RFC] Full syscall argument decode in "perf trace"

[David Ahern]

On 9/18/13 5:35 AM, Denys Vlasenko wrote:

Therefore my question should be restated as:

Would perf developers accept the "syscall pausing" feature,
or it won't be accepted?


I have been using perf-trace a lot lately specifically because it is 
effectively a 'passive' observer of the task (e.g., time-sensitive tasks 
can be traced with perf but not with strace).


Also, your solution would not work if the raw_syscall events are written 
to a file for later analysis where as using tracepoints to collect this 
information would.


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

Re: [PATCH 2/4] ARM: STi: Supply I2C configuration to STiH416 SoC

[Maxime COQUELIN]

On 09/18/2013 02:03 PM, Lee Jones wrote:
>> This patch supplies I2C configuration to STiH416 SoC.
>>
>> Cc: Srinivas Kandagatla 
>> Signed-off-by: Maxime Coquelin 
>> ---
>>  arch/arm/boot/dts/stih416-pinctrl.dtsi |   35 
>>  arch/arm/boot/dts/stih416.dtsi |   57 
>> 
>>  2 files changed, 92 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi 
>> b/arch/arm/boot/dts/stih416-pinctrl.dtsi
> I genuinely don't know the answer to this question, but are these
> nodes identical to the ones you've just put in the stih415 DTSI file?
> If so, I think it will be worth creating a stih41x DTSI rather than
> duplicating lots of stuff unnecessarily.
There are close to be identical indeed.
For the clocks and pinctrl, the references names are the same, but they are
pointing on different nodes, as STiH415 and STiH416 have their own
clocks and pinctrl dtsi files.

Srini, what is opinion about this?
>
>> index 0f246c9..b29ff4b 100644
>> --- a/arch/arm/boot/dts/stih416-pinctrl.dtsi
>> +++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
>> @@ -97,6 +97,24 @@
>>  };
>>  };
>>  };
>> +
>> +sbc_i2c0 {
>> +pinctrl_sbc_i2c0_default: sbc_i2c0-default {
>> +st,pins {
>> +sda = < 6 ALT1 BIDIR>;
>> +scl = < 5 ALT1 BIDIR>;
>> +};
>> +};
>> +};
>> +
>> +sbc_i2c1 {
>> +pinctrl_sbc_i2c1_default: sbc_i2c1-default {
>> +st,pins {
>> +sda = < 2 ALT2 BIDIR>;
>> +scl = < 1 ALT2 BIDIR>;
>> +};
>> +};
>> +};
>>  };
>>  
>>  pin-controller-front {
>> @@ -175,6 +193,23 @@
>>  };
>>  };
>>  
>> +i2c0 {
>> +pinctrl_i2c0_default: i2c0-default {
>> +st,pins {
>> +sda = < 3 ALT1 BIDIR>;
>> +scl = < 2 ALT1 BIDIR>;
>> +};
>> +};
>> +};
>> +
>> +i2c1 {
>> +pinctrl_i2c1_default: i2c1-default {
>> +st,pins {
>> +sda = < 1 ALT1 BIDIR>;
>> +scl = < 0 ALT1 BIDIR>;
>> +};
>> +};
>> +};
>>  };
>>  
>>  pin-controller-rear {
>> diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
>> index 1a0326e..8856470 100644
>> --- a/arch/arm/boot/dts/stih416.dtsi
>> +++ b/arch/arm/boot/dts/stih416.dtsi
>> @@ -9,6 +9,7 @@
>>  #include "stih41x.dtsi"
>>  #include "stih416-clock.dtsi"
>>  #include "stih416-pinctrl.dtsi"
>> +#include 
>>  / {
>>  L2: cache-controller {
>>  compatible = "arm,pl310-cache";
>> @@ -92,5 +93,61 @@
>>  pinctrl-0   = <_sbc_serial1>;
>>  clocks  = <_SYSIN>;
>>  };
>> +
>> +i2c0: i2c@fed4{
> Same issues here. I assume most of this is copy paste.
Yes indeed. This will be fixed in next version.
>
>> +compatible  = "st,comms-i2c";
>> +status  = "disabled";
>> +reg = <0xfed4 0x110>;
>> +interrupts  =  ;
>> +clocks  = <_S_ICN_REG_0>;
>> +clock-frequency = <40>;
>> +pinctrl-names   = "default";
>> +pinctrl-0   = <_i2c0_default>;
>> +st,glitches;
>> +st,glitch-clk   = <500>;
>> +st,glitch-dat   = <500>;
>> +};
>> +
>> +i2c1: i2c@fed41000{
>> +compatible  = "st,comms-i2c";
>> +status  = "disabled";
>> +reg = <0xfed41000 0x110>;
>> +interrupts  =  ;
>> +clocks  = <_S_ICN_REG_0>;
>> +clock-frequency = <40>;
>> +pinctrl-names   = "default";
>> +pinctrl-0   = <_i2c1_default>;
>> +st,glitches;
>> +st,glitch-clk   = <500>;
>> +st,glitch-dat   = <500>;
>> 

[PATCH 1/2] ARM: tegra: enable PALMAS_PINCTRL config

[Laxman Dewangan]

PALMAS PMIC is used on Dalmore platform. Enable the pincontrol
driver for Palmas to configure pins of Palmas on desired state.

Signed-off-by: Laxman Dewangan 
---
Reposting as the patch sent earlier was miss the merge date.

 arch/arm/configs/tegra_defconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index bb16a04..3be2122 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -130,6 +130,7 @@ CONFIG_SPI=y
 CONFIG_SPI_TEGRA114=y
 CONFIG_SPI_TEGRA20_SFLASH=y
 CONFIG_SPI_TEGRA20_SLINK=y
+CONFIG_PINCTRL_PALMAS=y
 CONFIG_GPIO_PCA953X_IRQ=y
 CONFIG_GPIO_PALMAS=y
 CONFIG_GPIO_TPS6586X=y
-- 
1.7.1.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 V2 2/2] ARM: tegra: add palmas pincontrol to Dalmore device tree

[Laxman Dewangan]

Add Palmas pincontrol to Dalmore device tree and make following
configuration as default:
- Disable DVFS1 and DVFS2.
- Set GPIO6 to gpio mode.

Signed-off-by: Laxman Dewangan 
---
changes from V1:
- Renames the node name to pinmux as suggested on patch V1.
- Not sure that this will create the issue with other node having same
  name as pinmux in top of the dts file.

 arch/arm/boot/dts/tegra114-dalmore.dts |   13 +
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
b/arch/arm/boot/dts/tegra114-dalmore.dts
index 6023028..dc5cdd7 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -1011,6 +1011,19 @@
interrupt-parent = <>;
interrupts = <8 0>;
};
+
+   pinmux {
+   compatible = "ti,tps65913-pinctrl";
+   pinctrl-names = "default";
+   pinctrl-0 = <_default>;
+
+   palmas_default: pinmux {
+   pin_gpio6 {
+   pins = "gpio6";
+   function = "gpio";
+   };
+   };
+   };
};
};
 
-- 
1.7.1.1

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

Re: [PATCH 3/4] ARM: STi: Supply I2C configuration to STiH415 SoC

[Maxime COQUELIN]

On 09/18/2013 02:00 PM, Lee Jones wrote:
> On Wed, 18 Sep 2013, Maxime COQUELIN wrote:
>
>> This patch supplies I2C configuration to STiH415 SoC.
>>
>> Cc: Srinivas Kandagatla 
>> Signed-off-by: Maxime Coquelin 
>> ---
>>  arch/arm/boot/dts/stih415-pinctrl.dtsi |   36 
>>  arch/arm/boot/dts/stih415.dtsi |   57 
>> 
>>  2 files changed, 93 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stih415-pinctrl.dtsi 
>> b/arch/arm/boot/dts/stih415-pinctrl.dtsi
>> index 1d322b2..e56449d 100644
>> --- a/arch/arm/boot/dts/stih415-pinctrl.dtsi
>> +++ b/arch/arm/boot/dts/stih415-pinctrl.dtsi
>> @@ -86,6 +86,24 @@
>>  };
>>  };
>>  };
>> +
>> +sbc_i2c0 {
>> +pinctrl_sbc_i2c0_default: sbc_i2c0-default {
>> +st,pins {
>> +sda = < 6 ALT1 BIDIR>;
>> +scl = < 5 ALT1 BIDIR>;
>> +};
>> +};
>> +};
>> +
>> +sbc_i2c1 {
>> +pinctrl_sbc_i2c1_default: sbc_i2c1-default {
>> +st,pins {
>> +sda = < 2 ALT2 BIDIR>;
>> +scl = < 1 ALT2 BIDIR>;
>> +};
>> +};
>> +};
>>  };
>>  
>>  pin-controller-front {
>> @@ -143,6 +161,24 @@
>>  reg = <0x7000 0x100>;
>>  st,bank-name= "PIO12";
>>  };
>> +
>> +i2c0 {
>> +pinctrl_i2c0_default: i2c0-default {
>> +st,pins {
>> +sda = < 3 ALT1 BIDIR>;
>> +scl = < 2 ALT1 BIDIR>;
>> +};
>> +};
>> +};
>> +
>> +i2c1 {
>> +pinctrl_i2c1_default: i2c1-default {
>> +st,pins {
>> +sda = < 1 ALT1 BIDIR>;
>> +scl = < 0 ALT1 BIDIR>;
>> +};
>> +};
>> +};
>>  };
>>  
>>  pin-controller-rear {
>> diff --git a/arch/arm/boot/dts/stih415.dtsi b/arch/arm/boot/dts/stih415.dtsi
>> index 74ab8de..643ae1c 100644
>> --- a/arch/arm/boot/dts/stih415.dtsi
>> +++ b/arch/arm/boot/dts/stih415.dtsi
>> @@ -9,6 +9,7 @@
>>  #include "stih41x.dtsi"
>>  #include "stih415-clock.dtsi"
>>  #include "stih415-pinctrl.dtsi"
>> +#include 
>>  / {
>>  
>>  L2: cache-controller {
>> @@ -83,5 +84,61 @@
>>  pinctrl-names   = "default";
>>  pinctrl-0   = <_sbc_serial1>;
>>  };
>> +
>> +i2c0: i2c@fed4{
> Space before the '{'.
It will be fixed in next series
>
>> +compatible  = "st,comms-i2c";
>> +status  = "disabled";
> Consider putting the node status at the bottom.
Ok.
>
>> +reg = <0xfed4 0x110>;
>> +interrupts  =  ;
>> +clocks  = <_ICN_REG_0>;
>> +clock-frequency = <40>;
>> +pinctrl-names   = "default";
>> +pinctrl-0   = <_i2c0_default>;
>> +st,glitches;
>> +st,glitch-clk   = <500>;
>> +st,glitch-dat   = <500>;
>> +};
>> +
>> +i2c1: i2c@fed41000{
> Same here and throughout.
Ok.
>
>> +compatible  = "st,comms-i2c";
>> +status  = "disabled";
> Same here and throughout.
Ok.
>
>> +reg = <0xfed41000 0x110>;
>> +interrupts  =  ;
>> +clocks  = <_ICN_REG_0>;
>> +clock-frequency = <40>;
>> +pinctrl-names   = "default";
>> +pinctrl-0   = <_i2c1_default>;
>> +st,glitches;
>> +st,glitch-clk   = <500>;
>> +st,glitch-dat   = <500>;
>> +};
>> +
>> +sbc_i2c0: i2c@fe54{
>> +compatible  = "st,comms-i2c";
>> +status  = "disabled";
>> +reg = <0xfe54 0x110>;
>> +interrupts  =  ;
>> +clocks  = <_SYSIN>;
>> +  

Re: [PATCH 4/4] ARM: STi: Add I2C config to B2000 and B2020 boards

[Maxime COQUELIN]

Hi Lee,

On 09/18/2013 01:40 PM, Lee Jones wrote:
> On Wed, 18 Sep 2013, Maxime COQUELIN wrote:
>
>> This patch supplies I2C configuration to B2000 and B2020
>> based on either STiH415 or STiH416 SoCs.
>>
>> Cc: Srinivas Kandagatla 
>> Signed-off-by: Maxime Coquelin 
>> ---
>>  arch/arm/boot/dts/stih41x-b2000.dtsi |7 +++
>>  arch/arm/boot/dts/stih41x-b2020.dtsi |   20 
>>  2 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stih41x-b2000.dtsi 
>> b/arch/arm/boot/dts/stih41x-b2000.dtsi
>> index 8e694d2..346cc4bc 100644
>> --- a/arch/arm/boot/dts/stih41x-b2000.dtsi
>> +++ b/arch/arm/boot/dts/stih41x-b2000.dtsi
>> @@ -37,5 +37,12 @@
>>  };
>>  };
>>  
>> +/* HDMI Tx I2C */
>> +i2c1: i2c@fed41000{
> nit: Space before the '{'
Ok. It will be fixed for all nodes in next series.
>
>> +status = "okay";
> Consider enabling the node at the bottom.
>
>> +
>> +/* HDMI V1.3a supports Standard mode only */
>> +clock-frequency = <10>;
>> +};
>>  };
>>  };
>> diff --git a/arch/arm/boot/dts/stih41x-b2020.dtsi 
>> b/arch/arm/boot/dts/stih41x-b2020.dtsi
>> index 133e181..10b98da 100644
>> --- a/arch/arm/boot/dts/stih41x-b2020.dtsi
>> +++ b/arch/arm/boot/dts/stih41x-b2020.dtsi
>> @@ -38,5 +38,25 @@
>>  default-state = "off";
>>  };
>>  };
>> +
>> +i2c0: i2c@fed4{
> As above.
>
>> +status = "okay";
>> +};
>> +
>> +/* HDMI Tx I2C */
>> +i2c1: i2c@fed41000{
> As above.
>
>> +status = "okay";
> As above.
>
>> +/* HDMI V1.3a supports Standard mode only */
>> +clock-frequency = <10>;
>> +};
>> +
>> +sbc_i2c0: i2c@fe54{
> As above.
>
>> +status = "okay";
>> +};
>> +
>> +sbc_i2c1: i2c@fe541000{
> Are these nodes referenced by phandle at all?
>
> If not, consider dropping the :s
It was references in an previous internal version of this series.
This is no more the case, so I will drop the labels.
>
>> +status = "okay";
>> +};
>>  };
>>  };
> Odd tabbing here.
>
Thanks,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/3] Fix Win8 backlight issue

[Igor Gnatenko]

On Wed, 2013-09-18 at 20:31 +0800, Aaron Lu wrote:
> On 09/18/2013 02:30 PM, Igor Gnatenko wrote:
> > On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote:
> >> On 09/17/2013 09:34 PM, Igor Gnatenko wrote:
> >>>
> >>> Aaron, how about fix indicator on ThinkPads ?
> >>
> >> Can you please describe the problem in detail, is it that when you
> >> adjust brightness level through hotkey, there is no GUI indication?
> >> Thanks.
> >>
> >> -Aaron
> > 
> > Yes. On my ThinkPad X230 I pressing backlight hotkeys. Actually
> > brightnes changing, but have no indicator in GUI.
> 
> Oh, that's still the problem of _BCL not getting executed once for
> Lenovo thinkpad laptops. I borrowed a Thinkpad X1 this afternoon and can
> reproduce this, I'll take a look at this issue. The thinkpad-acpi module
> already has a call to _BCL but somehow that doesn't happen.
> 
> Since it's national holidays here, I'll check this issue when I got back
> to work on this Saturday. Thanks for the quick test :-)
Thanks. No problem ;-)
> 
> -Aaron


-- 
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.1-300.fc20.x86_64

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