[PATCHv4] serial: of-serial: fix up PM ops on no_console_suspend and port type

[Jingchang Lu]

This patch fixes commit 2dea53bf57783f243c892e99c10c6921e956aa7e,
"serial: of-serial: add PM suspend/resume support", which disables
the uart clock on suspend, but also causes a hardware hang on register
access if no_console_suspend command line option is used.

Also, not every of_serial device is an 8250 port, so the serial8250
suspend/resume functions should only be applied to a real 8250 port.

Signed-off-by: Jingchang Lu 
---
changes in v4:
 separate 8250 port suspend/resume from of_serial_suspend/resume.

changes in v3:
 fix up point reference and deference.

changes in v2:
 add switch selection on uart type.

 drivers/tty/serial/of_serial.c | 52 --
 1 file changed, 45 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 8bc2563..5281f8f 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -241,13 +241,48 @@ static int of_platform_serial_remove(struct 
platform_device *ofdev)
 }
 
 #ifdef CONFIG_PM_SLEEP
-static int of_serial_suspend(struct device *dev)
+#ifdef CONFIG_SERIAL_8250
+static void of_serial_suspend_8250(struct of_serial_info *info)
 {
-   struct of_serial_info *info = dev_get_drvdata(dev);
+   struct uart_8250_port *port8250 = serial8250_get_port(info->line);
+   struct uart_port *port = >port;
 
serial8250_suspend_port(info->line);
-   if (info->clk)
+   if (info->clk && (!uart_console(port) || console_suspend_enabled))
clk_disable_unprepare(info->clk);
+}
+
+static void of_serial_resume_8250(struct of_serial_info *info)
+{
+   struct uart_8250_port *port8250 = serial8250_get_port(info->line);
+   struct uart_port *port = >port;
+
+   if (info->clk && (!uart_console(port) || console_suspend_enabled))
+   clk_prepare_enable(info->clk);
+
+   serial8250_resume_port(info->line);
+}
+#else
+static inline void of_serial_suspend_8250(struct of_serial_info *info)
+{
+}
+
+static inline void of_serial_resume_8250(struct of_serial_info *info)
+{
+}
+#endif
+
+static int of_serial_suspend(struct device *dev)
+{
+   struct of_serial_info *info = dev_get_drvdata(dev);
+
+   switch(info->type) {
+   case PORT_8250 ... PORT_MAX_8250:
+   of_serial_suspend_8250(info);
+   break;
+   default:
+   break;
+   }
 
return 0;
 }
@@ -256,10 +291,13 @@ static int of_serial_resume(struct device *dev)
 {
struct of_serial_info *info = dev_get_drvdata(dev);
 
-   if (info->clk)
-   clk_prepare_enable(info->clk);
-
-   serial8250_resume_port(info->line);
+   switch(info->type) {
+   case PORT_8250 ... PORT_MAX_8250:
+   of_serial_resume_8250(info);
+   break;
+   default:
+   break;
+   }
 
return 0;
 }
-- 
1.8.0

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

Re: [PATCH v3 2/2] DT: iio: vadc: document dt binding

[Stanimir Varbanov]

Mark,

Thanks for the comments!

On 10/13/2014 06:00 PM, Mark Rutland wrote:
> On Wed, Sep 24, 2014 at 01:56:55PM +0100, Stanimir Varbanov wrote:
>> Document DT binding for Qualcomm SPMI PMIC voltage ADC
>> driver.
>>
>> Signed-off-by: Stanimir Varbanov 
>> Signed-off-by: Ivan T. Ivanov 
>> ---
>>  .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt |  130 
>> 
>>  1 files changed, 130 insertions(+), 0 deletions(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt 
>> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
>> new file mode 100644
>> index 000..fa30300
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
>> @@ -0,0 +1,130 @@
>> +Qualcomm's SPMI PMIC voltage ADC
>> +
>> +SPMI PMIC voltage ADC (VADC) provides interface to clients to read
>> +voltage. A 15 bit ADC is used for voltage measurements. There are multiple
>> +peripherals to the VADC and the scope of the driver is to provide interface
>> +for the USR peripheral of the VADC.
>> +
>> +VADC node:
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
> 
> Technically this is a list of strings.

true, will correct.

> 
>> +Definition: Should contain "qcom,spmi-vadc".
>> +
>> +- reg:
>> +Usage: required
>> +Value type: 
> 
> This is an address + size pair, not a u32 (following your example).
> 
>> +Definition: Base address in the SPMI PMIC register map.
> 
> And the size, too.
> 

will rephrase.

>> +
>> +- address-cells:
>> +Usage: required
>> +Value type: 
>> +Definition: Must be one.
> 
> #address-cells.
> 
> What would this cell represent within the ADC?

"reg" property is used to describe ADC channel number in ADC child nodes.

> 
>> +
>> +- size-cells:
>> +Usage: required
>> +Value type: 
>> +Definition: Must be zero.
> 
> #size-cells.
> 
>> +
>> +- interrupts:
>> +Usage: optional
>> +Value type: 
>> +Definition: End of conversion interrupt number. If this property does
>> +not exist polling will be used instead.
> 
> Just say "end of conversion interrupt". The interrupts property is
> standard, and driver behaviour is not a property of the device.

OK.

> 
>> +
>> +- interrupt-names:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain the interrupt name "eoc" (end of conversion).
> 
> If you wish to use interrupt-names, please define interrupts in terms of
> interrupt-names so as to make the relationship clear and to avoid
> redundancy.
> 
>> +
>> +Channel node properties:
>> +
>> +- reg:
>> +Usage: required
>> +Value type: 
>> +Definition: AMUX channel number.
>> +See include/dt-bindings/iio/qcom,spmi-pmic-vadc.h
> 
> That header should be part of this patch (and this patch should come
> before the driver).

Sure will rebase the series.

> 
>> +
>> +- qcom,decimation:
>> +Usage: optional
>> +Value type: 
>> +Definition: Sampling rate to use for the individual channel measurement.
>> +Quicker measurements can be made by reducing decimation ratio.
>> +Valid values are 512, 1024, 2048, 4096.
>> +If property is not found, default value of 512 will be used.
> 
> This description does not make sense. If reducing the value increases
> the sampling rate, this property should not be described as the
> "sampling rate".

I blindly copped above description from codeaurora kernel. From the
above I understand that reducing decimation ratio will decrease
conversion time.

Without go into signal processing theory, what about this:

Definition: Decimation factor per channel. Valid values are 512, 1024,
2048 and 4096.

I'm expecting the reader will be familiar enough how the decimation will
reflect on the data rate and conversion time.

> 
> This feels like something that should be runtime configurable rather
> than a fixed device property.

Currently the IIO hasn't generic way to configure such a properties.

Jonathan, could you share your opinion on that.

> 
>> +
>> +- qcom,pre-scaling:
>> +Usage: optional
>> +Value type: 
>> +Definition: Used for scaling the channel input signal before the signal 
>> is
>> +fed to VADC. The configuration for this node is to know the
>> +pre-determined ratio and use it for post scaling. Select one 
>> from
>> +the following options.
>> +<1 1>, <1 3>, <1 4>, <1 6>, <1 20>, <1 8>, <10 81>, <1 10>
>> +If property is not found default value depending of chip will 
>> be used.
>> +
>> +- qcom,ratiometric:
>> +Usage: optional
>> +Value type: 
>> +Definition: Channel calibration type. If this property is specified
>> +VADC will use the VDD reference(1.8V) and GND for channel
>> +calibration. If property is not found, channel will be
>> +calibrated 

Re: [PATCH v2 1/1] Documentation: dt-bindings: Explain order in patch series

[Mark Rutland]

On Thu, Oct 09, 2014 at 07:24:07PM +0100, Javier Martinez Canillas wrote:
> When posting a patch series that includes both code implementing a
> Device Tree binding and its associated documentation, the DT docs
> should come in the series before the implementation.
> 
> This not only avoids checkpatch.pl to complain about undocumented
> bindings but also makes the review process easier.
> 
> Document this convention since it may not be obvious.
> 
> Signed-off-by: Javier Martinez Canillas 

Following the discussion around [1], this makes sense to me, so:

Acked-by: Mark Rutland 

Mark.

[1] http://lkml.kernel.org/r/5435.4090...@collabora.co.uk

> ---
> 
> Changes since v1:
>  - Small typo error, sorry for the noise.
> 
>  Documentation/devicetree/bindings/submitting-patches.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/submitting-patches.txt 
> b/Documentation/devicetree/bindings/submitting-patches.txt
> index 042a027..b7ba01a 100644
> --- a/Documentation/devicetree/bindings/submitting-patches.txt
> +++ b/Documentation/devicetree/bindings/submitting-patches.txt
> @@ -12,6 +12,9 @@ I. For patch submitters
>  
> devicet...@vger.kernel.org
>  
> +  3) The Documentation/ portion of the patch should come in the series before
> + the code implementing the binding.
> +
>  II. For kernel maintainers
>  
>1) If you aren't comfortable reviewing a given binding, reply to it and ask
> -- 
> 2.1.0
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 3/3] i2c: show and change bus frequency via sysfs

[Octavian Purdila]

On Tue, Oct 14, 2014 at 4:53 AM, Mark Roszko  wrote:
>
> > If this limitations exists
> >they are not introduced by this patch. This patch just exposes the
> >frequency so that it can be read or changed in userspace.
>
> Ah, well right now you can have an i2c bus with driver 1 and 2. Say
> the i2c bus is configured for 60khz in kernel space which normally
> can't be changed. Driver 1 talks to a slave that cannot go above
> 100khz. Now the userspace interface is added to the i2c bus. Some
> userspace application decides to reconfigure the bus for 400khz and do
> its communication to some slave device. Now the kernel tries to do
> some background talking to the drive 1 slave and suddenly finds it can
> no longer communicate with it. Right now with the kernel space only
> configuration, the system is safe from being messed up easily. It's
> more of a sanity of configuration issue.

You need privileges to change the bus frequency, so this is a
configuration issue. Which you still have today, since can still set
the i2c frequency on some busses via a module parameter.

>
>
> >On a different not, I have noticed that a fixed set of frequencies
> >might not be the best API, since multiple drivers rather support a
> >rather large set of frequencies in a range. A better API might be to
> >expose a min-max range and let the bus driver adjust the requested
> >frequency. I will follow up with a second version that does that.
>
> I was actually thinking you could eliminate the table of supported
> frequencies and just have the bus driver handle the set frequency
> decision itself and just return an error code if it's invalid. There
> are legitiamate drivers that cannot do more than a list of frequencies
> already as well. One example is here:
> http://lxr.free-electrons.com/source/drivers/i2c/busses/i2c-bcm-kona.c#L717

Yes, I will do that for v2 and in addition I will also add min and max
attributes to make it easier to determine if a bus supports fast mode,
fast plus, high, etc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen/setup: add paranoid index check and warning

[David Vrabel]

On 14/10/14 02:19, Martin Kelly wrote:
> In a call to set_phys_range_identity, i-1 is used without checking that
> i is non-zero. Although unlikely, a bug in the code before it could
> cause the value to be 0, leading to erroneous behavior. This patch adds
> a check against 0 value and a corresponding warning.

This can only happen if the toolstack supplies a memory map with zero
entries.  I could see justification for adding a panic at the top of
this function in this case, but I can't see the usefulness of this warning.

> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -671,7 +671,10 @@ char * __init xen_memory_setup(void)
>* PFNs above MAX_P2M_PFN are considered identity mapped as
>* well.
>*/
> - set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul);
> + if (i > 0)
> + set_phys_range_identity(map[i-1].addr / PAGE_SIZE, ~0ul);
> + else
> + WARN(1, "Something went wrong clamping memory to a factor of 
> EXTRA_MEM_RATIO!");
>  
>   /*
>* In domU, the ISA region is normal, usable memory, but we
> 

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

Re: [PATCH v3 00/21] powerpc/8xx: Optimise MMU TLB handling and add support of 16k pages

[Scott Wood]

On Mon, 2014-10-13 at 18:44 +0200, leroy christophe wrote:
> Le 17/09/2014 22:34, Scott Wood a écrit :
> > On Wed, 2014-09-17 at 22:33 +0200, christophe leroy wrote:
> >> Le 17/09/2014 18:40, Scott Wood a écrit :
> >>> On Wed, 2014-09-17 at 18:36 +0200, Christophe Leroy wrote:
>  This patchset:
>  1) provides several MMU TLB handling optimisation on MPC8xx.
>  2) adds support of 16k pages on MPC8xx.
>  All changes have been successfully tested on a custom board equipped 
>  with MPC885
> 
>  Signed-off-by: Christophe Leroy 
>  Tested-by: Christophe Leroy 
> >>> I've already applied patches 1, 2, 4, 5, 6, 9, and 10 from the previous
> >>> patchset -- have they changed?
> >>>
> >>> -Scott
> >>>
> >> No, only 3, 7, 17 are changed, and 20,21 are new.
> >> I didn't notice you already applied some. How should I then proceed now
> >> for the remaining ones ? Submit a new set ?
> >>
> > No, I'll just skip the ones I've already applied.
> >
> >
> I think I took into account all Joakim's and your's comments in v4.
> Since I submitted v4, I think I didn't get any new comment.
> What's the way forward to get the remaining ones applied ?

I haven't had a chance to review v4 yet.  I'm currently at conferences
and will be on vacation next week, but I will try to look at them soon
after that.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hyperv: Implement Time Synchronization using host time sample

[Thomas Gleixner]

On Tue, 14 Oct 2014, Thomas Shao wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Tuesday, October 14, 2014 3:35 PM
> > To: Thomas Shao
> > Cc: t...@linutronix.de; linux-kernel@vger.kernel.org;
> > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> > jasow...@redhat.com; KY Srinivasan
> > Subject: Re: [PATCH] hyperv: Implement Time Synchronization using host
> > time sample
> > 
> > On Tue, Oct 14, 2014 at 01:23:46AM -0700, Thomas Shao wrote:
> > > --- a/kernel/time/timekeeping.c
> > > +++ b/kernel/time/timekeeping.c
> > > @@ -1786,6 +1786,7 @@ int do_adjtimex(struct timex *txc)
> > >
> > >   return ret;
> > >  }
> > > +EXPORT_SYMBOL(do_adjtimex);
> > 
> > EXPORT_SYMBOL_GPL()?
> 
> Oh, yes,  I should use EXPORT_SYMBOL_GPL. I'll send a new patch. Thanks Greg.

And please make that export a separate patch. 

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 6/8] perf symbols: Improve DSO long names lookup speed with rbtree

[Jiri Olsa]

On Wed, Oct 01, 2014 at 04:50:41PM -0300, Arnaldo Carvalho de Melo wrote:
> From: Waiman Long 
> 
> With workload that spawns and destroys many threads and processes, it
> was found that perf-mem could took a long time to post-process the perf
> data after the target workload had completed its operation.
> 
> The performance bottleneck was found to be the lookup and insertion of
> the new DSO structures (thousands of them in this case).

this change segfaults (below) some tests, but only if I compiled
without DEBUG when I revert this commit, I can no longer reproduce..

jirka

(gdb) set follow-fork-mode child
(gdb) r test 31
Starting program: /home/jolsa/kernel.org/linux-perf/tools/perf/perf test 31
warning: section  not found in 
/usr/lib/debug/lib/modules/3.16.3-200.fc20.x86_64/vdso/vdso64.so.debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
31: Test output sorting of hist entries:[New process 15477]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77b9d7c0 (LWP 15477)]
__strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:210
210 movlpd  (%rsi), %xmm2
(gdb) bt
#0  __strcmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:210
#1  0x00477967 in dso__findlink_by_longname (name=, 
dso=0x0, root=0x7fffdbf0)
at util/dso.c:674
#2  dso__find_by_longname (name=0x7fffcae8 "perf", root=0x7fffdbf0) at 
util/dso.c:712
#3  dsos__find (cmp_short=false, name=0x7fffcae8 "perf", 
dsos=0x7fffdbe0) at util/dso.c:935
#4  __dsos__findnew (dsos=dsos@entry=0x7fffdbe0, 
name=name@entry=0x7fffcae8 "perf") at util/dso.c:940
#5  0x004915d9 in map__new (machine=machine@entry=0x7fffdb90, 
start=4194304, len=1048576, pgoff=0, 
pid=, d_maj=d_maj@entry=0, d_min=d_min@entry=0, 
ino=ino@entry=0, ino_gen=ino_gen@entry=0, 
prot=prot@entry=0, flags=flags@entry=0, 
filename=filename@entry=0x7fffcae8 "perf", type=MAP__FUNCTION, 
thread=thread@entry=0x90d1f0) at util/map.c:180
#6  0x004900f4 in machine__process_mmap_event 
(machine=machine@entry=0x7fffdb90, 
event=event@entry=0x7fffcac0, sample=sample@entry=0x0) at 
util/machine.c:1182
#7  0x004d12bb in setup_fake_machine 
(machines=machines@entry=0x7fffdb90)
at tests/hists_common.c:116
#8  0x004d4478 in test__hists_output () at tests/hists_output.c:600
#9  0x00448fe4 in run_test (test=0x8166a0 ) at 
tests/builtin-test.c:210
#10 __cmd_test (skiplist=0x0, argv=0x7fffe2d0, argc=1) at 
tests/builtin-test.c:255
#11 cmd_test (argc=1, argv=0x7fffe2d0, prefix=) at 
tests/builtin-test.c:320
#12 0x0041c8f5 in run_builtin (p=p@entry=0x814fc0 , 
argc=argc@entry=2, 
argv=argv@entry=0x7fffe2d0) at perf.c:331
#13 0x0041c110 in handle_internal_command (argv=0x7fffe2d0, argc=2) 
at perf.c:390
#14 run_argv (argv=0x7fffe050, argcp=0x7fffe05c) at perf.c:434
#15 main (argc=2, argv=0x7fffe2d0) at perf.c:549
(gdb) 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] net: filter: move common defines into bpf_common.h

[Alexei Starovoitov]

userspace programs that use eBPF instruction macros need to include two files:
uapi/linux/filter.h and uapi/linux/bpf.h
Move common macro definitions that are shared between classic BPF and eBPF
into uapi/linux/bpf_common.h, so that user app can include only one bpf.h file

Cc: Daniel Borkmann 
Signed-off-by: Alexei Starovoitov 
---

Daniel believes that this patch has to be done for this merge window.
I think it can wait till next, but it won't hurt now either.

 include/uapi/linux/Kbuild   |1 +
 include/uapi/linux/bpf.h|1 +
 include/uapi/linux/bpf_common.h |   55 ++
 include/uapi/linux/filter.h |   56 +--
 4 files changed, 58 insertions(+), 55 deletions(-)
 create mode 100644 include/uapi/linux/bpf_common.h

diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 70e150e..1115d68 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -68,6 +68,7 @@ header-y += binfmts.h
 header-y += blkpg.h
 header-y += blktrace_api.h
 header-y += bpf.h
+header-y += bpf_common.h
 header-y += bpqether.h
 header-y += bsg.h
 header-y += btrfs.h
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 31b0ac2..d18316f 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -8,6 +8,7 @@
 #define _UAPI__LINUX_BPF_H__
 
 #include 
+#include 
 
 /* Extended instruction set based on top of classic BPF */
 
diff --git a/include/uapi/linux/bpf_common.h b/include/uapi/linux/bpf_common.h
new file mode 100644
index 000..a5c220e
--- /dev/null
+++ b/include/uapi/linux/bpf_common.h
@@ -0,0 +1,55 @@
+#ifndef _UAPI__LINUX_BPF_COMMON_H__
+#define _UAPI__LINUX_BPF_COMMON_H__
+
+/* Instruction classes */
+#define BPF_CLASS(code) ((code) & 0x07)
+#defineBPF_LD  0x00
+#defineBPF_LDX 0x01
+#defineBPF_ST  0x02
+#defineBPF_STX 0x03
+#defineBPF_ALU 0x04
+#defineBPF_JMP 0x05
+#defineBPF_RET 0x06
+#defineBPF_MISC0x07
+
+/* ld/ldx fields */
+#define BPF_SIZE(code)  ((code) & 0x18)
+#defineBPF_W   0x00
+#defineBPF_H   0x08
+#defineBPF_B   0x10
+#define BPF_MODE(code)  ((code) & 0xe0)
+#defineBPF_IMM 0x00
+#defineBPF_ABS 0x20
+#defineBPF_IND 0x40
+#defineBPF_MEM 0x60
+#defineBPF_LEN 0x80
+#defineBPF_MSH 0xa0
+
+/* alu/jmp fields */
+#define BPF_OP(code)((code) & 0xf0)
+#defineBPF_ADD 0x00
+#defineBPF_SUB 0x10
+#defineBPF_MUL 0x20
+#defineBPF_DIV 0x30
+#defineBPF_OR  0x40
+#defineBPF_AND 0x50
+#defineBPF_LSH 0x60
+#defineBPF_RSH 0x70
+#defineBPF_NEG 0x80
+#defineBPF_MOD 0x90
+#defineBPF_XOR 0xa0
+
+#defineBPF_JA  0x00
+#defineBPF_JEQ 0x10
+#defineBPF_JGT 0x20
+#defineBPF_JGE 0x30
+#defineBPF_JSET0x40
+#define BPF_SRC(code)   ((code) & 0x08)
+#defineBPF_K   0x00
+#defineBPF_X   0x08
+
+#ifndef BPF_MAXINSNS
+#define BPF_MAXINSNS 4096
+#endif
+
+#endif /* _UAPI__LINUX_BPF_COMMON_H__ */
diff --git a/include/uapi/linux/filter.h b/include/uapi/linux/filter.h
index 253b4d4..47785d5 100644
--- a/include/uapi/linux/filter.h
+++ b/include/uapi/linux/filter.h
@@ -7,7 +7,7 @@
 
 #include 
 #include 
-
+#include 
 
 /*
  * Current version of the filter code architecture.
@@ -32,56 +32,6 @@ struct sock_fprog {  /* Required for SO_ATTACH_FILTER. */
struct sock_filter __user *filter;
 };
 
-/*
- * Instruction classes
- */
-
-#define BPF_CLASS(code) ((code) & 0x07)
-#define BPF_LD  0x00
-#define BPF_LDX 0x01
-#define BPF_ST  0x02
-#define BPF_STX 0x03
-#define BPF_ALU 0x04
-#define BPF_JMP 0x05
-#define BPF_RET 0x06
-#define BPF_MISC0x07
-
-/* ld/ldx fields */
-#define BPF_SIZE(code)  ((code) & 0x18)
-#define BPF_W   0x00
-#define BPF_H   0x08
-#define BPF_B   0x10
-#define BPF_MODE(code)  ((code) & 0xe0)
-#define BPF_IMM 0x00
-#define BPF_ABS 0x20
-#define BPF_IND 0x40
-#define BPF_MEM 0x60
-#define BPF_LEN 0x80
-#define BPF_MSH 0xa0
-
-/* alu/jmp fields */
-#define BPF_OP(code)((code) & 0xf0)

Re: [PATCH 3/3] spi: qup: Remove .owner field for driver

[Kiran Padwal]

On Tuesday 14 October 2014 01:39 PM, Mark Brown wrote:
> On Tue, Oct 14, 2014 at 11:47:57AM +0530, Kiran Padwal wrote:
>> On Monday 13 October 2014 06:39 PM, Mark Brown wrote:
> 
>>> Two problems:
>>>  - I'm missing patches 1 and 2.
> 
>> These patches are same like this one,
>> [1] https://lkml.org/lkml/2014/10/9/58
>> [2] https://lkml.org/lkml/2014/10/9/52
> 
> You should at least be sending the cover letter to everyone so that they
> know what's going on.

OK, I will take care of this next time.

> 
>>>  - This only changes one driver but essentially every SPI driver
>>>initializes .owner - why is only thi sone driver being changed?
> 
>> Nothing more intention, but just remove superfluous .owner field for drivers 
>> which
>> use the module_platform_driver API, as this is overridden in
>> platform_driver_register anyway.
> 
> My point is that doing a change like this to random drivers isn't great,
> if you're going to do this sort of thing it is better to do it for
> everything rather than making things inconsistent.
> 

Sure, I will do that.

Thanks,
--Kiran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xen: avoid writing to freed memory after race in p2m handling

[Juergen Gross]

In case a race was detected during allocation of a new p2m tree
element in alloc_p2m() the new allocated mid_mfn page is freed without
updating the pointer to the found value in the tree. This will result
in overwriting the just freed page with the mfn of the p2m leaf.

Signed-off-by: Juergen Gross 
---
 arch/x86/xen/p2m.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9f5983b..4534320 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -566,6 +566,7 @@ static bool alloc_p2m(unsigned long pfn)
/* Separately check the mid mfn level */
unsigned long missing_mfn;
unsigned long mid_mfn_mfn;
+   unsigned long old_mfn;
 
mid_mfn = alloc_p2m_page();
if (!mid_mfn)
@@ -575,10 +576,13 @@ static bool alloc_p2m(unsigned long pfn)
 
missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
mid_mfn_mfn = virt_to_mfn(mid_mfn);
-   if (cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn) != missing_mfn)
+   old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
+   if (old_mfn != missing_mfn) {
free_p2m_page(mid_mfn);
-   else
+   mid_mfn = mfn_to_virt(old_mfn);
+   } else {
p2m_top_mfn_p[topidx] = mid_mfn;
+   }
}
 
if (p2m_top[topidx][mididx] == p2m_identity ||
-- 
1.8.4.5

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

[GIT PULL] LLVMLinux patches for v3.18

[Behan Webster]

These patches remove the use of VLAIS using a new SHASH_DESC_ON_STACK macro.
Some of the previously accepted VLAIS removal patches haven't used this
macro. I will
push new patches to consistently use this macro in all those older cases
for 3.19

The following changes since commit 2d65a9f48fcdf7866aab6457bc707ca233e0c791:

  Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
(2014-10-14 09:39:08 +0200)

are available in the git repository at:

  git://git.linuxfoundation.org/llvmlinux/kernel.git
tags/llvmlinux-for-v3.18

for you to fetch changes up to 4c5c30249452aaebf258751ea4222eba3dd3da4c:

  crypto: LLVMLinux: Remove VLAIS usage from crypto/testmgr.c
(2014-10-14 10:51:24 +0200)


LLVMLinux patches for v3.18


Behan Webster (6):
  crypto: LLVMLinux: Add macro to remove use of VLAIS in crypto code
  crypto: LLVMLinux: Remove VLAIS from crypto/mv_cesa.c
  crypto: LLVMLinux: Remove VLAIS from crypto/n2_core.c
  crypto: LLVMLinux: Remove VLAIS from crypto/omap_sham.c
  crypto: LLVMLinux: Remove VLAIS from crypto/.../qat_algs.c
  security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c

Jan-Simon Möller (5):
  crypto: LLVMLinux: Remove VLAIS from crypto/ccp/ccp-crypto-sha.c
  crypto, dm: LLVMLinux: Remove VLAIS usage from dm-crypt
  crypto: LLVMLinux: Remove VLAIS usage from crypto/hmac.c
  crypto: LLVMLinux: Remove VLAIS usage from libcrc32c.c
  crypto: LLVMLinux: Remove VLAIS usage from crypto/testmgr.c

Vinícius Tinti (1):
  btrfs: LLVMLinux: Remove VLAIS

 crypto/hmac.c| 25 -
 crypto/testmgr.c | 14 --
 drivers/crypto/ccp/ccp-crypto-sha.c  | 13 -
 drivers/crypto/mv_cesa.c | 41 
 drivers/crypto/n2_core.c | 11 +++-
 drivers/crypto/omap-sham.c   | 28 ---
 drivers/crypto/qat/qat_common/qat_algs.c | 31 ++---
 drivers/md/dm-crypt.c| 34 ++-
 fs/btrfs/hash.c  | 16 +--
 include/crypto/hash.h|  5 
 lib/libcrc32c.c  | 16 +--
 security/integrity/ima/ima_crypto.c  | 47
+---
 12 files changed, 122 insertions(+), 159 deletions(-)

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

[PATCH] staging, unisys: remove leftover function kmalloc_kernel()

[WANG Chao]

kmalloc_kernel() previously declared in timskmodutils.h which recently got
removed. Now also remove kmalloc_kernel(), because it's not used anywhere.

Signed-off-by: WANG Chao 
---
 drivers/staging/unisys/visorutil/visorkmodutils.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/staging/unisys/visorutil/visorkmodutils.c 
b/drivers/staging/unisys/visorutil/visorkmodutils.c
index d6815f9..64b135d 100644
--- a/drivers/staging/unisys/visorutil/visorkmodutils.c
+++ b/drivers/staging/unisys/visorutil/visorkmodutils.c
@@ -36,16 +36,6 @@
 int unisys_spar_platform;
 EXPORT_SYMBOL_GPL(unisys_spar_platform);
 
-/** Callers to interfaces that set __GFP_NORETRY flag below
- *  must check for a NULL (error) result as we are telling the
- *  kernel interface that it is okay to fail.
- */
-
-void *kmalloc_kernel(size_t siz)
-{
-   return kmalloc(siz, GFP_KERNEL | __GFP_NORETRY);
-}
-
 static __init uint32_t
 visorutil_spar_detect(void)
 {
-- 
1.9.3

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

Re: [PATCH 3.13 163/163] lzo: check for length overrun in variable length encoding.

[Luis Henriques]

On Tue, Oct 14, 2014 at 03:52:33AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 13, 2014 at 10:31:03AM -0700, Kamal Mostafa wrote:
> > On Fri, 2014-10-10 at 07:30 +0200, Willy Tarreau wrote:
> > > Hi Kamal,
> > > 
> > > [ removed Don Bailey from the CC who's certainly not interested in this ]
> > > 
> > > On Thu, Oct 09, 2014 at 02:03:08PM -0700, Kamal Mostafa wrote:
> > > > 3.13.11.9 -stable review patch.  If anyone has any objections, please 
> > > > let me know.
> > > > 
> > > > --
> > > > 
> > > > From: Willy Tarreau 
> > > > 
> > > > commit 72cf90124e87d975d0b2114d930808c58b4c05e4 upstream.
> > > 
> > > (...)
> > 
> > Hi Willy-
> > 
> > Thanks very much for reviewing this.
> > 
> > > This one (and the accompanying revert) are still not present in more
> > > recent stable kernels, so I find it surprizing that you're proposing
> > > to integrate them now.
> > 
> > I can hold out those lzo fixes until the next 3.13-stable if you prefer.
> 
> Please do so.
> 
> > But fwiw...
> > 
> > >  If someone upgrades from 3.13.11.9 to 3.14.21
> > > or 3.16.5, they'd expect to keep all fixes but will lose this one, so
> > > this is a bit confusing.
> > 
> > I think those sorts of scheduling mismatches and discrepancies between
> > stable versions are pretty common.  Examples:  The top 11 commits in
> > v3.12.30 have not yet been applied[0] to any of the newer stable
> > branches;
> 
> Those -mm patches from Mel are "special", I'm taking it slow in merging
> them, doing lots of local testing and code review, and not all of them
> even are relevant for 3.14, so don't take the acceptance /
> non-acceptance of them as any kind of "proof" of anything at all.
> 
> > Many of the commits in v3.10.57 have not yet been applied[1]
> > to linux-3.12.y but have been released in other newer stables.
> 
> That's because I am ahead of Jiri, which will almost always happen due
> to our different workflows and time available to spend on stable
> kernels.
> 
> > >  Is there any reason you're not tracking fixes
> > > from more recent versions like Jiri, Li, Ben and I are doing ?
> > 
> > We (the Canonical stable maintainers) have always tracked the "cc:
> > stable" fixes directly from mainline, not from the more-recent-version
> > branches.  Given the examples above, it seems that the kernel.org
> > maintainers are doing that too, yes?
> 
> You have included patches in your release that are not in _any_ public
> release on kernel.org yet.  Which is fine, you are allowed to do
> whatever you want, but that goes against the existing rules of stable
> patches that we have been following for well over the past year for when
> it is acceptable to add a patch to a stable release.
> 

Could you please provide us with examples of commits in one of our
extended stable trees that is not on any other public release at
kernel.org?  We really try hard to follow the process defined for the
official stable kernels, so if this has happen in the past it was
definitely a mistake from our side, and we would love to get your
feedback during the review cycles.

My understanding is that Kamal queued this specific patch because its
related with a security issue (CVE-2014-4608): the original fix is
being reverted upstream and he is queuing this revert and the
alternative fix.  Anyway, since Willy objected, its likely Kamal will
postpone including these patches in the 3.13 kernel.

Cheers,
--
Luís

> Yet another reason I _strongly_ urge you to mark your kernels with some
> type of "name" to help reduce the confusion of others that your kernels
> might be somehow associated with kernel.org releases.
> 
> greg k-h
> 
> -- 
> kernel-team mailing list
> kernel-t...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/25] virtio: defer config changed notifications

[Michael S. Tsirkin]

On Tue, Oct 14, 2014 at 11:01:12AM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin"  writes:
> > Defer config changed notifications that arrive during
> > probe/scan/freeze/restore.
> >
> > This will allow drivers to set DRIVER_OK earlier, without worrying about
> > racing with config change interrupts.
> >
> > This change will also benefit old hypervisors (before 2009)
> > that send interrupts without checking DRIVER_OK: previously,
> > the callback could race with driver-specific initialization.
> >
> > This will also help simplify drivers.
> 
> But AFAICT you never *read* dev->config_changed.
> 
> You unconditionally trigger a config_changed event in
> virtio_config_enable().  That's a bit weird, but probably OK.
> 
> How about the following change (on top of your patch).  I
> think the renaming is clearer, and note the added if() test in
> virtio_config_enable().
> 
> If you approve, I'll fold it in.
> 
> Cheers,
> Rusty.

Hi Rusty,
I'm okay with both changes.
You can fold it in if you prefer, or just make it a patch on top.

> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index 2536701b098b..df598dd8c5c8 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -122,7 +122,7 @@ static void __virtio_config_changed(struct virtio_device 
> *dev)
>   struct virtio_driver *drv = drv_to_virtio(dev->dev.driver);
>  
>   if (!dev->config_enabled)
> - dev->config_changed = true;
> + dev->config_change_pending = true;
>   else if (drv && drv->config_changed)
>   drv->config_changed(dev);
>  }
> @@ -148,8 +148,9 @@ static void virtio_config_enable(struct virtio_device 
> *dev)
>  {
>   spin_lock_irq(>config_lock);
>   dev->config_enabled = true;
> - __virtio_config_changed(dev);
> - dev->config_changed = false;
> + if (dev->config_change_pending)
> + __virtio_config_changed(dev);
> + dev->config_change_pending = false;
>   spin_unlock_irq(>config_lock);
>  }
>  
> @@ -253,7 +254,7 @@ int register_virtio_device(struct virtio_device *dev)
>  
>   spin_lock_init(>config_lock);
>   dev->config_enabled = false;
> - dev->config_changed = false;
> + dev->config_change_pending = false;
>  
>   /* We always start by resetting the device, in case a previous
>* driver messed it up.  This also tests that code path a little. */
> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> index 5636b119dc25..65261a7244fc 100644
> --- a/include/linux/virtio.h
> +++ b/include/linux/virtio.h
> @@ -80,7 +80,7 @@ bool virtqueue_is_broken(struct virtqueue *vq);
>   * @index: unique position on the virtio bus
>   * @failed: saved value for CONFIG_S_FAILED bit (for restore)
>   * @config_enabled: configuration change reporting enabled
> - * @config_changed: configuration change reported while disabled
> + * @config_change_pending: configuration change reported while disabled
>   * @config_lock: protects configuration change reporting
>   * @dev: underlying device.
>   * @id: the device type identification (used to match it with a driver).
> @@ -94,7 +94,7 @@ struct virtio_device {
>   int index;
>   bool failed;
>   bool config_enabled;
> - bool config_changed;
> + bool config_change_pending;
>   spinlock_t config_lock;
>   struct device dev;
>   struct virtio_device_id id;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] regulator: s2mps11: add support for S2MPS15 regulators

[Krzysztof Kozłowski]

On 14.10.2014 10:17, Thomas Abraham wrote:
> The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
> 27 LDO and 10 Buck regulators and allows programming these regulators via a
> I2C interface. This patch adds initial support for LDO/Buck regulators of
> S2MPS15 PMIC.
> 
> Signed-off-by: Thomas Abraham 

Just two questions/ideas:
1. No specific steps for suspend?
2. Maybe add S2MPS15 to MODULE_DESCRIPTION and Kconfig?

Anyway rest looks fine.
Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

> ---
>  drivers/regulator/s2mps11.c |  133 
> +++
>  1 files changed, 133 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
> index adab82d..e176fbb 100644
> --- a/drivers/regulator/s2mps11.c
> +++ b/drivers/regulator/s2mps11.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct s2mps11_info {
> @@ -529,6 +530,133 @@ static const struct regulator_desc s2mps14_regulators[] 
> = {
>   regulator_desc_s2mps14_buck(5, MIN_600_MV, STEP_6_25_MV),
>  };
>  
> +static struct regulator_ops s2mps15_reg_ldo_ops = {
> + .list_voltage   = regulator_list_voltage_linear_range,
> + .map_voltage= regulator_map_voltage_linear_range,
> + .is_enabled = regulator_is_enabled_regmap,
> + .enable = regulator_enable_regmap,
> + .disable= regulator_disable_regmap,
> + .get_voltage_sel= regulator_get_voltage_sel_regmap,
> + .set_voltage_sel= regulator_set_voltage_sel_regmap,
> +};
> +
> +static struct regulator_ops s2mps15_reg_buck_ops = {
> + .list_voltage   = regulator_list_voltage_linear_range,
> + .map_voltage= regulator_map_voltage_linear_range,
> + .is_enabled = regulator_is_enabled_regmap,
> + .enable = regulator_enable_regmap,
> + .disable= regulator_disable_regmap,
> + .get_voltage_sel= regulator_get_voltage_sel_regmap,
> + .set_voltage_sel= regulator_set_voltage_sel_regmap,
> + .set_voltage_time_sel   = regulator_set_voltage_time_sel,
> +};
> +
> +#define regulator_desc_s2mps15_ldo(num, range) { \
> + .name   = "LDO"#num,\
> + .id = S2MPS15_LDO##num, \
> + .ops= _reg_ldo_ops, \
> + .type   = REGULATOR_VOLTAGE,\
> + .owner  = THIS_MODULE,  \
> + .linear_ranges  = range,\
> + .n_linear_ranges = ARRAY_SIZE(range),   \
> + .n_voltages = S2MPS15_LDO_N_VOLTAGES,   \
> + .vsel_reg   = S2MPS15_REG_L1CTRL + num - 1, \
> + .vsel_mask  = S2MPS15_LDO_VSEL_MASK,\
> + .enable_reg = S2MPS15_REG_L1CTRL + num - 1, \
> + .enable_mask= S2MPS15_ENABLE_MASK   \
> +}
> +
> +#define regulator_desc_s2mps15_buck(num, range) {\
> + .name   = "BUCK"#num,   \
> + .id = S2MPS15_BUCK##num,\
> + .ops= _reg_buck_ops,\
> + .type   = REGULATOR_VOLTAGE,\
> + .owner  = THIS_MODULE,  \
> + .linear_ranges  = range,\
> + .n_linear_ranges = ARRAY_SIZE(range),   \
> + .ramp_delay = 12500,\
> + .n_voltages = S2MPS15_BUCK_N_VOLTAGES,  \
> + .vsel_reg   = S2MPS15_REG_B1CTRL2 + ((num - 1) * 2),\
> + .vsel_mask  = S2MPS15_BUCK_VSEL_MASK,   \
> + .enable_reg = S2MPS15_REG_B1CTRL1 + ((num - 1) * 2),\
> + .enable_mask= S2MPS14_ENABLE_MASK   \
> +}
> +
> +/* voltage range for s2mps15 LDO 3, 5, 15, 16, 18, 20, 23 and 27 */
> +static const struct regulator_linear_range s2mps15_ldo_voltage_ranges1[] = {
> + REGULATOR_LINEAR_RANGE(100, 0xc, 0x38, 25000),
> +};
> +
> +/* voltage range for s2mps15 LDO 2, 6, 14, 17, 19, 21, 24 and 25 */
> +static const struct regulator_linear_range s2mps15_ldo_voltage_ranges2[] = {
> + REGULATOR_LINEAR_RANGE(180, 0x0, 0x3f, 25000),
> +};
> +
> +/* voltage range for s2mps15 LDO 4, 11, 12, 13, 22 and 26 */
> +static const struct regulator_linear_range s2mps15_ldo_voltage_ranges3[] = {
> + REGULATOR_LINEAR_RANGE(70, 0x0, 0x34, 12500),
> +};
> +
> +/* voltage range for s2mps15 LDO 7, 8, 9 and 10 */
> +static const struct regulator_linear_range s2mps15_ldo_voltage_ranges4[] = {
> + REGULATOR_LINEAR_RANGE(70, 0xc, 0x18, 25000),
> +};
> +
> +/* voltage range for s2mps15 LDO 1 */
> +static const struct regulator_linear_range 

Re: [PATCH 3.14 36/37] crypto: caam - fix addressing of struct member

[Cristian Stoica]

I mean whatever is currently stable, maintained and more recent than 3.13.

Thanks,
Cristian S.


On 10/14/2014 11:38 AM, Greg Kroah-Hartman wrote:
> On Tue, Oct 14, 2014 at 11:31:56AM +0300, Cristian Stoica wrote:
>> Hi Greg,
>>
>> You can cherry-pick 307fd543f3d23f8f56850eca1b27b1be2fe71017 on stable
>> 3.13+ as well. The original 'cc stable 3.13+' line was deleted by
>> mistake during commit.
> 
> 3.13-stable is long dead and not being maintained by me anymore, sorry.
> 
> greg k-h
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rotary encoder linux driver

[Johan Hovold]

On Sun, Oct 12, 2014 at 06:29:03PM -0700, tecfacet wrote:
> Hello.
> 
> I am interested in the rotary encoder kernel driver.  I am very new to
> this linux kernel driver thing.  
> 
> How do I pass the gpio and interrupt stuff to the kernel module.. I
> think it is thru the rotary_encoder.h file.. am I correct?

That should be done through the device tree these days. The binding is
documented in

Documentation/devicetree/bindings/input/rotary-encoder.txt

in the kernel source tree.

> How does the information about encoder position etc get back to my
> user space program?  How is debounce handled?
> I am a little confused.  Is there an example of a complete working
> implementation?  I need to figure this out for school.

Have a look at the evtest program for an example:

http://cgit.freedesktop.org/~whot/evtest

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

Re: [PATCH] fs/fscache/object-list.c: use __seq_open_private()

[David Howells]

Rob Jones  wrote:

> I submitted the patch below on 17th September but have had no feedback.

It is now upstream.

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 v9 net-next 2/4] net: filter: split filter.h and expose eBPF to user space

[Alexei Starovoitov]

On Tue, Oct 14, 2014 at 12:34 AM, Daniel Borkmann  wrote:
> On 10/13/2014 11:49 PM, Alexei Starovoitov wrote:
>>
>> On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann 
>> wrote:
>>>
>>> On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
>>> ...


 Ok, given you post the remaining two RFCs later on this window as
 you indicate, I have no objections:

 Acked-by: Daniel Borkmann 
>>>
>>>
>>> Ping, Alexei, are you still sending the patch for bpf_common.h or
>>> do you want me to take care of this?
>>
>>
>> It's not forgotten.
>> I'm not sending it only because net-next is closed
>> and it seems to be -next material.
>
>
> Well, the point was since it's UAPI you're modifying, that it needs
> to be shipped before it first gets exposed to user land ...
>
> I think that should be reason enough ... there's no point in doing
> this at a later point in time.

Moving common #defines from filter.h into bpf_common.h can
be done at any point in time. For the sake of argument if
there is an app that includes both filter.h and bpf.h, it will
continue to work just fine.
Anyway, since you insist, I will send it now, though it definitely
can wait.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Krzysztof Kozłowski]

On 14.10.2014 10:14, Thomas Abraham wrote:
> Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
> is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Thomas Abraham 
> ---
>  Documentation/devicetree/bindings/mfd/s2mps11.txt |   11 ---
>  1 files changed, 8 insertions(+), 3 deletions(-)

Looks good.
Reviewed-by: Krzysztof Kozlowski 

P.S. Wrong devicetree-disc...@lists.ozlabs.org list? I receive bounces.

Best regards,
Krzysztof


> 
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> index 0e4026a..41ee3f5 100644
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> @@ -1,5 +1,5 @@
>  
> -* Samsung S2MPS11, S2MPS14 and S2MPU02 Voltage and Current Regulator
> +* Samsung S2MPS11/14/15 and S2MPU02 Voltage and Current Regulator
>  
>  The Samsung S2MPS11 is a multi-function device which includes voltage and
>  current regulators, RTC, charger controller and other sub-blocks. It is
> @@ -7,8 +7,11 @@ interfaced to the host controller using an I2C interface. 
> Each sub-block is
>  addressed by the host system using different I2C slave addresses.
>  
>  Required properties:
> -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic"
> -  or "samsung,s2mpu02-pmic".
> +- compatible: Should be one of the following
> + - "samsung,s2mps11-pmic"
> + - "samsung,s2mps14-pmic"
> + - "samsung,s2mps15-pmic"
> + - "samsung,s2mpu02-pmic"
>  - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
>  
>  Optional properties:
> @@ -82,12 +85,14 @@ as per the datasheet of s2mps11.
> - valid values for n are:
>   - S2MPS11: 1 to 38
>   - S2MPS14: 1 to 25
> + - S2MPS15: 1 to 27
>   - S2MPU02: 1 to 28
> - Example: LDO1, LDO2, LDO28
>   - BUCKn
> - valid values for n are:
>   - S2MPS11: 1 to 10
>   - S2MPS14: 1 to 5
> + - S2MPS15: 1 to 10
>   - S2MPU02: 1 to 7
> - Example: BUCK1, BUCK2, BUCK9
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: sec: Add support for S2MPS15 PMIC

[Krzysztof Kozłowski]

On 14.10.2014 10:14, Thomas Abraham wrote:
> Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
> PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
> clock outputs and battery charger. This patch adds initial support for
> LDO and buck regulators of S2MPS15 device.
> 
> Signed-off-by: Thomas Abraham 

Quite nice and small diff stat for adding new chip support. Looks good.
I assume that RTC/clock will be handled in later submissions.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

> ---
>  drivers/mfd/sec-core.c  |   26 ++
>  include/linux/mfd/samsung/core.h|1 +
>  include/linux/mfd/samsung/s2mps15.h |  161 
> +++
>  3 files changed, 188 insertions(+), 0 deletions(-)
>  create mode 100644 include/linux/mfd/samsung/s2mps15.h
> 
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index dba7e2b..6f33c2b 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -85,6 +86,12 @@ static const struct mfd_cell s2mps14_devs[] = {
>   }
>  };
>  
> +static const struct mfd_cell s2mps15_devs[] = {
> + {
> + .name = "s2mps15-pmic",
> + },
> +};
> +
>  static const struct mfd_cell s2mpa01_devs[] = {
>   {
>   .name = "s2mpa01-pmic",
> @@ -111,6 +118,9 @@ static const struct of_device_id sec_dt_match[] = {
>   .compatible = "samsung,s2mps14-pmic",
>   .data = (void *)S2MPS14X,
>   }, {
> + .compatible = "samsung,s2mps15-pmic",
> + .data = (void *)S2MPS15X,
> + }, {
>   .compatible = "samsung,s2mpa01-pmic",
>   .data = (void *)S2MPA01,
>   }, {
> @@ -203,6 +213,15 @@ static const struct regmap_config s2mps14_regmap_config 
> = {
>   .cache_type = REGCACHE_FLAT,
>  };
>  
> +static const struct regmap_config s2mps15_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +
> + .max_register = S2MPS15_REG_LDODSCH4,
> + .volatile_reg = s2mps11_volatile,
> + .cache_type = REGCACHE_FLAT,
> +};
> +
>  static const struct regmap_config s2mpu02_regmap_config = {
>   .reg_bits = 8,
>   .val_bits = 8,
> @@ -328,6 +347,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
>   case S2MPS14X:
>   regmap = _regmap_config;
>   break;
> + case S2MPS15X:
> + regmap = _regmap_config;
> + break;
>   case S5M8763X:
>   regmap = _regmap_config;
>   break;
> @@ -382,6 +404,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
>   sec_devs = s2mps14_devs;
>   num_sec_devs = ARRAY_SIZE(s2mps14_devs);
>   break;
> + case S2MPS15X:
> + sec_devs = s2mps15_devs;
> + num_sec_devs = ARRAY_SIZE(s2mps15_devs);
> + break;
>   case S2MPU02:
>   sec_devs = s2mpu02_devs;
>   num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
> diff --git a/include/linux/mfd/samsung/core.h 
> b/include/linux/mfd/samsung/core.h
> index 1825eda..49ef612 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -42,6 +42,7 @@ enum sec_device_type {
>   S2MPA01,
>   S2MPS11X,
>   S2MPS14X,
> + S2MPS15X,
>   S2MPU02,
>  };
>  
> diff --git a/include/linux/mfd/samsung/s2mps15.h 
> b/include/linux/mfd/samsung/s2mps15.h
> new file mode 100644
> index 000..e82549a
> --- /dev/null
> +++ b/include/linux/mfd/samsung/s2mps15.h
> @@ -0,0 +1,161 @@
> +/*
> + * s2mps15.h
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd
> + *  http://www.samsung.com
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef __LINUX_MFD_S2MPS15_H
> +#define __LINUX_MFD_S2MPS15_H
> +
> +/* S2MPS15 registers */
> +enum s2mps15_reg {
> + S2MPS15_REG_ID,
> + S2MPS15_REG_INT1,
> + S2MPS15_REG_INT2,
> + S2MPS15_REG_INT3,
> + S2MPS15_REG_INT1M,
> + S2MPS15_REG_INT2M,
> + S2MPS15_REG_INT3M,
> + S2MPS15_REG_ST1,
> + S2MPS15_REG_ST2,
> + S2MPS15_REG_PWRONSRC,
> + S2MPS15_REG_OFFSRC,
> + S2MPS15_REG_BU_CHG,
> + S2MPS15_REG_RTCCTRL,
> + S2MPS15_REG_CTRL1,
> + S2MPS15_REG_CTRL2,
> + S2MPS15_REG_RSVD1,
> + S2MPS15_REG_RSVD2,
> + S2MPS15_REG_RSVD3,
> + S2MPS15_REG_RSVD4,
> + 

RE: [PATCH] hyperv: Implement Time Synchronization using host time sample

[Thomas Shao]

> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, October 14, 2014 3:35 PM
> To: Thomas Shao
> Cc: t...@linutronix.de; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; KY Srinivasan
> Subject: Re: [PATCH] hyperv: Implement Time Synchronization using host
> time sample
> 
> On Tue, Oct 14, 2014 at 01:23:46AM -0700, Thomas Shao wrote:
> > --- a/kernel/time/timekeeping.c
> > +++ b/kernel/time/timekeeping.c
> > @@ -1786,6 +1786,7 @@ int do_adjtimex(struct timex *txc)
> >
> > return ret;
> >  }
> > +EXPORT_SYMBOL(do_adjtimex);
> 
> EXPORT_SYMBOL_GPL()?

Oh, yes,  I should use EXPORT_SYMBOL_GPL. I'll send a new patch. Thanks Greg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.14 36/37] crypto: caam - fix addressing of struct member

[Greg Kroah-Hartman]

On Tue, Oct 14, 2014 at 11:31:56AM +0300, Cristian Stoica wrote:
> Hi Greg,
> 
> You can cherry-pick 307fd543f3d23f8f56850eca1b27b1be2fe71017 on stable
> 3.13+ as well. The original 'cc stable 3.13+' line was deleted by
> mistake during commit.

3.13-stable is long dead and not being maintained by me anymore, sorry.

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

[git pull] IOMMU Updates for Linux v3.18

[Joerg Roedel]

Hi Linus,

The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb:

  Linux 3.17-rc7 (2014-09-28 14:29:07 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git 
tags/iommu-updates-v3.18

for you to fetch changes up to 09b5269a1b3d47525d7c25efeb16f5407ef82ea2:

  Merge branches 'arm/exynos', 'arm/omap', 'arm/smmu', 'x86/vt-d', 'x86/amd' 
and 'core' into next (2014-10-02 12:24:45 +0200)



IOMMU Updates for Linux v3.18

This pull-request includes:

* Change in the IOMMU-API to convert the former iommu_domain_capable
  function to just iommu_capable

* Various fixes in handling RMRR ranges for the VT-d driver (one fix
  requires a device driver core change which was acked
  by Greg KH)

* The AMD IOMMU driver now assigns and deassigns complete alias groups
  to fix issues with devices using the wrong PCI request-id

* MMU-401 support for the ARM SMMU driver

* Multi-master IOMMU group support for the ARM SMMU driver

* Various other small fixes all over the place


Alex Williamson (2):
  iommu: Rework iommu_group_get_for_pci_dev()
  iommu/amd: Split init_iommu_group() from iommu_init_device()

Andreea-Cristina Bernat (1):
  iommu: Replace rcu_assign_pointer() with RCU_INIT_POINTER()

Jan Kiszka (1):
  iommu/vt-d: Don't store SIRTP request

Joerg Roedel (23):
  iommu/amd: Move struct iommu_dev_data to amd_iommu.c
  iommu/amd: Keep a list of devices in an alias group
  iommu/amd: Attach and detach complete alias group
  iommu/amd: Remove device binding reference count
  Merge branch 'for-joerg/arm-smmu/updates' of 
git://git.kernel.org/.../will/linux into arm/smmu
  iommu: Convert iommu-caps from define to enum
  iommu: Introduce iommu_capable API function
  iommu/amd: Convert to iommu_capable() API function
  iommu/arm-smmu: Convert to iommu_capable() API function
  iommu/fsl: Convert to iommu_capable() API function
  iommu/vt-d: Convert to iommu_capable() API function
  iommu/msm: Convert to iommu_capable() API function
  iommu/tegra: Convert to iommu_capable() API function
  kvm: iommu: Convert to use new iommu_capable() API function
  vfio: Convert to use new iommu_capable() API function
  IB/usnic: Convert to use new iommu_capable() API function
  iommu: Remove iommu_domain_has_cap() API function
  iommu/amd: Fix devid mapping for ivrs_ioapic override
  driver core: Add BUS_NOTIFY_REMOVED_DEVICE event
  iommu/vt-d: Only remove domain when device is removed
  iommu/vt-d: Store bus information in RMRR PCI device path
  iommu/vt-d: Work around broken RMRR firmware entries
  Merge branches 'arm/exynos', 'arm/omap', 'arm/smmu', 'x86/vt-d', 
'x86/amd' and 'core' into next

Kiran Padwal (1):
  iommu: Make of_device_id array const

Laurent Pinchart (1):
  iommu/omap: Remove omap_iommu unused owner field

Mark Salter (1):
  iommu: Fix bus notifier breakage

Maurizio Lombardi (1):
  amd_iommu: do not dereference a NULL pointer address.

Mitchel Humpherys (1):
  iommu/arm-smmu: fix bug in pmd construction

Robin Murphy (2):
  iommu/arm-smmu: fix architecture version detection
  iommu/arm-smmu: support MMU-401

Sachin Kamat (1):
  iommu/exynos: Fix trivial typos

Suman Anna (2):
  iommu/omap: Check for valid archdata in attach_dev
  iommu/omap: Fix iommu archdata name for DT-based devices

Will Deacon (5):
  iommu/arm-smmu: allow translation stage to be forced on the cmdline
  iommu/arm-smmu: add support for multi-master iommu groups
  iommu/arm-smmu: put iommu_domain pointer in dev->archdata.iommu
  iommu/arm-smmu: use page shift instead of page size to avoid division
  iommu/arm-smmu: don't bother truncating the s1 output size to VA_BITS

Yijing Wang (1):
  iommu/irq_remapping: Fix the regression of hpet irq remapping

 .../devicetree/bindings/iommu/arm,smmu.txt |   1 +
 drivers/base/core.c|   3 +
 drivers/infiniband/hw/usnic/usnic_uiom.c   |   2 +-
 drivers/iommu/amd_iommu.c  | 117 ++-
 drivers/iommu/amd_iommu_init.c |  21 +-
 drivers/iommu/amd_iommu_types.h|  21 --
 drivers/iommu/arm-smmu.c   | 220 -
 drivers/iommu/dmar.c   |  25 ++-
 drivers/iommu/exynos-iommu.c   |  51 ++---
 drivers/iommu/fsl_pamu_domain.c|   5 +-
 drivers/iommu/intel-iommu.c|  16 +-
 drivers/iommu/intel_irq_remapping.c|   7 +-
 drivers/iommu/iommu.c  | 208 +++
 

[RFT PATCH] power: bq2415x_charger: Properly handle ENODEV from power_supply_get_by_phandle

[Krzysztof Kozlowski]

The power_supply_get_by_phandle() on error returns ENODEV or NULL.
The driver later expects obtained pointer to power supply to be
valid or NULL. If it is not NULL then it dereferences it in
bq2415x_notifier_call() which would lead to dereferencing ENODEV-value
pointer.

Properly handle the power_supply_get_by_phandle() error case and abort probe.

Signed-off-by: Krzysztof Kozlowski 
Fixes: faffd234cf85 ("bq2415x_charger: Add DT support")
Cc: 
---
 drivers/power/bq2415x_charger.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c
index e384844a1ae1..d9c457217b6a 100644
--- a/drivers/power/bq2415x_charger.c
+++ b/drivers/power/bq2415x_charger.c
@@ -1579,8 +1579,13 @@ static int bq2415x_probe(struct i2c_client *client,
if (np) {
bq->notify_psy = power_supply_get_by_phandle(np, 
"ti,usb-charger-detection");
 
-   if (!bq->notify_psy)
+   if (!bq->notify_psy) {
return -EPROBE_DEFER;
+   } else if (IS_ERR(bq->notify_psy)) {
+   dev_err(>dev, "no 'ti,usb-charger-detection' 
property\n");
+   ret = PTR_ERR(bq->notify_psy);
+   goto error_2;
+   }
}
else if (pdata->notify_device)
bq->notify_psy = power_supply_get_by_name(pdata->notify_device);
-- 
1.9.1

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

Re: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16

[Johan Hovold]

On Sun, Oct 12, 2014 at 10:36:30PM +0100, Nix wrote:
> On 12 Oct 2014, Johan Hovold verbalised:
> 
> > On Sat, Oct 11, 2014 at 11:24:59PM +0100, Nix wrote:
> >> On 11 Oct 2014, Paul Martin spake thusly:
> >> 
> >> > Having been privy to the firmware of the eKey, it is very simplisting,
> >> > with no implementation whatsoever of any flow control.
> >> 
> >> That's what I thought. (Why would something that just provides data at a
> >> constant rate way below that of even the slowest USB bus *need* flow
> >> control?)
> >> 
> >> One presumes therefore that the kernel suddenly trying to do flow
> >> control on shutdown would fubar the firmware's internal state, leading
> >> to the symptoms I see.
> >
> > The cdc-acm driver was dropping DTR/RTS on shutdown (close) also before
> > the commit you refer to. One thing it did change however is that this is
> > now only done if HUPCL is set. Might setting that flag be enough to
> > prevent the device firmware from crashing?
> 
> If I read the ekeyd 1.1.5 source code correctly, this is already
> happening:
> 
> ,[ host/stream.c:estream_open() ]
> | } else if (S_ISCHR(sbuf.st_mode)) {
> | /* Open the file as a character device/tty */
> | fd = open(uri, O_RDWR | O_NOCTTY);
> | if ((fd != -1) && (isatty(fd))) {
> | if (tcgetattr(fd, ) == 0 ) {
> | settings.c_cflag &= ~(CSIZE | CSTOPB | PARENB | CLOCAL |
> |   CREAD | PARODD | CRTSCTS);
> | settings.c_iflag &= ~(BRKINT | IGNPAR | PARMRK | INPCK |
> |   ISTRIP | INLCR | IGNCR | ICRNL | IXON 
> |
> |   IXOFF  | IXANY | IMAXBEL);
> | settings.c_iflag |= IGNBRK;
> | settings.c_oflag &= ~(OPOST | OCRNL | ONOCR | ONLRET);
> | settings.c_lflag &= ~(ISIG | ICANON | IEXTEN | ECHO |
> |   ECHOE | ECHOK | ECHONL | NOFLSH |
> |   TOSTOP | ECHOPRT | ECHOCTL | ECHOKE);
> | settings.c_cflag |= CS8 | HUPCL | CREAD | CLOCAL;
> | #ifdef EKEY_FULL_TERMIOS
> | settings.c_cflag &= ~(CBAUD);
> |   settings.c_iflag &= ~(IUTF8 | IUCLC);
> | settings.c_oflag &= ~(OFILL | OFDEL | NLDLY | CRDLY | 
> TABDLY |
> |   BSDLY | VTDLY | FFDLY | OLCUC );
> | settings.c_oflag |= NL0 | CR0 | TAB0 | BS0 | VT0 | FF0;
> | settings.c_lflag &= ~(XCASE);
> | #endif
> | settings.c_cflag |= B115200;
> | if (tcsetattr(fd, TCSANOW, ) < 0) {
> `
> 
> Note the HUPCL in there.
> 
> I have checked: this code is being executed against a symlink that
> points to /dev/ttyACM0, and the tcsetattr() succeeds. (At least, it's
> succeeding on the kernel I'm running now, but of course that's 3.16.5
> with this commit reverted...)

You could verify that by enabling debugging in the cdc-acm driver and
making sure that the corresponding control messages are indeed sent on
close.

But you haven't seen any fw crashes since you reverted the commit in
question?

Another thing you could try is to add back the 

acm_set_control(acm, 0);

just after the dev_info message in probe.

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

[PATCH v2] ARM: dts: rockchip: add I2S controllers for rk3066 and rk3188

[Julien CHAUVEAU]

Add the I2S/PCM controller nodes and pin controls for rk3066 and rk3188.

Signed-off-by: Julien CHAUVEAU 
---
 arch/arm/boot/dts/rk3066a.dtsi | 81 ++
 arch/arm/boot/dts/rk3188.dtsi  | 26 ++
 2 files changed, 107 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index ad9c2db..d75b01a 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -53,6 +53,51 @@
};
};
 
+   i2s0: i2s@10118000 {
+   compatible = "rockchip,rk3066-i2s";
+   reg = <0x10118000 0x2000>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus>;
+   dmas = <_s 4>, <_s 5>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_hclk", "i2s_clk";
+   clocks = < HCLK_I2S0>, < SCLK_I2S0>;
+   status = "disabled";
+   };
+
+   i2s1: i2s@1011a000 {
+   compatible = "rockchip,rk3066-i2s";
+   reg = <0x1011a000 0x2000>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus>;
+   dmas = <_s 6>, <_s 7>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_hclk", "i2s_clk";
+   clocks = < HCLK_I2S1>, < SCLK_I2S1>;
+   status = "disabled";
+   };
+
+   i2s2: i2s@1011c000 {
+   compatible = "rockchip,rk3066-i2s";
+   reg = <0x1011c000 0x2000>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus>;
+   dmas = <_s 9>, <_s 10>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_hclk", "i2s_clk";
+   clocks = < HCLK_I2S2>, < SCLK_I2S2>;
+   status = "disabled";
+   };
+
cru: clock-controller@2000 {
compatible = "rockchip,rk3066a-cru";
reg = <0x2000 0x1000>;
@@ -405,6 +450,42 @@
;
};
};
+
+   i2s0 {
+   i2s0_bus: i2s0-bus {
+   rockchip,pins = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   };
+   };
+
+   i2s1 {
+   i2s1_bus: i2s1-bus {
+   rockchip,pins = ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   };
+   };
+
+   i2s2 {
+   i2s2_bus: i2s2-bus {
+   rockchip,pins = ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   };
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index ddaada7..fa3665a 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -65,6 +65,21 @@
};
};
 
+   i2s0: i2s@1011a000 {
+   compatible = "rockchip,rk3188-i2s", "rockchip,rk3066-i2s";
+   reg = <0x1011a000 0x2000>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus>;
+   dmas = <_s 6>, <_s 7>;
+   dma-names = "tx", "rx";
+   clock-names = "i2s_hclk", "i2s_clk";
+   clocks = < HCLK_I2S0>, < SCLK_I2S0>;
+   status = "disabled";
+   };
+
cru: clock-controller@2000 {
compatible = "rockchip,rk3188-cru";
reg = <0x2000 0x1000>;
@@ -395,6 +410,17 @@
;
};
};
+
+   i2s0 {
+   i2s0_bus: i2s0-bus {
+   rockchip,pins = ,
+ 

Re: [PATCH 3/3] spi: qup: Remove .owner field for driver

[Mark Brown]

On Tue, Oct 14, 2014 at 11:47:57AM +0530, Kiran Padwal wrote:
> On Monday 13 October 2014 06:39 PM, Mark Brown wrote:

> > Two problems:
> >  - I'm missing patches 1 and 2.

> These patches are same like this one,
> [1] https://lkml.org/lkml/2014/10/9/58
> [2] https://lkml.org/lkml/2014/10/9/52

You should at least be sending the cover letter to everyone so that they
know what's going on.

> >  - This only changes one driver but essentially every SPI driver
> >initializes .owner - why is only thi sone driver being changed?

> Nothing more intention, but just remove superfluous .owner field for drivers 
> which
> use the module_platform_driver API, as this is overridden in
> platform_driver_register anyway.

My point is that doing a change like this to random drivers isn't great,
if you're going to do this sort of thing it is better to do it for
everything rather than making things inconsistent.


signature.asc
Description: Digital signature

Re: nf_reject_ipv4: module license 'unspecified' taints kernel

['Dave Young']

On 10/10/14 at 09:53am, David Laight wrote:
> From: Dave Young
> > With today's linus tree, I got below kmsg:
> > [   23.545204] nf_reject_ipv4: module license 'unspecified' taints kernel.
> > [   23.551886] Disabling lock debugging due to kernel taint
> ...
> 
> Not 100% related, but why does loading a non-GPL module disable 
> lock debugging?
> (Is 'lock debugging' actually useful?)

I believe that we can not trust the debugging any more because kernel taint.. 

Thanks
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: nf_reject_ipv4: module license 'unspecified' taints kernel

[Dave Young]

On 10/10/14 at 11:56am, Pablo Neira Ayuso wrote:
> On Fri, Oct 10, 2014 at 05:19:04PM +0800, Dave Young wrote:
> > Hi,
> > 
> > With today's linus tree, I got below kmsg:
> > [   23.545204] nf_reject_ipv4: module license 'unspecified' taints kernel.
> > 
> > It could be caused by below commit:
> > 
> > commit c8d7b98bec43faaa6583c3135030be5eb4693acb
> > Author: Pablo Neira Ayuso 
> > Date:   Fri Sep 26 14:35:15 2014 +0200
> > 
> > netfilter: move nf_send_resetX() code to nf_reject_ipvX modules
> > 
> > Move nf_send_reset() and nf_send_reset6() to nf_reject_ipv4 and
> > nf_reject_ipv6 respectively. This code is shared by x_tables and
> > nf_tables.
> > 
> > Signed-off-by: Pablo Neira Ayuso 
> 
> Patch attached, thanks for reporting.

Tested-by: Dave Young 

> 
> P.S: Please, Cc netfilter-de...@vger.kernel.org in future reports, so
> we make sure things don't get lost.

Sure. Thanks.

> From d4358bcf64ba7a64d4de4e1dc5533c4c8f88ea82 Mon Sep 17 00:00:00 2001
> From: Pablo Neira Ayuso 
> Date: Fri, 10 Oct 2014 11:25:20 +0200
> Subject: [PATCH] netfilter: missing module license in the nf_reject_ipvX
>  modules
> 
> [   23.545204] nf_reject_ipv4: module license 'unspecified' taints kernel.
> 
> Reported-by: Dave Young 
> Signed-off-by: Pablo Neira Ayuso 
> ---
>  net/ipv4/netfilter/nf_reject_ipv4.c |3 +++
>  net/ipv6/netfilter/nf_reject_ipv6.c |4 
>  2 files changed, 7 insertions(+)
> 
> diff --git a/net/ipv4/netfilter/nf_reject_ipv4.c 
> b/net/ipv4/netfilter/nf_reject_ipv4.c
> index b023b4e..92b303d 100644
> --- a/net/ipv4/netfilter/nf_reject_ipv4.c
> +++ b/net/ipv4/netfilter/nf_reject_ipv4.c
> @@ -6,6 +6,7 @@
>   * published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -125,3 +126,5 @@ void nf_send_reset(struct sk_buff *oldskb, int hook)
>   kfree_skb(nskb);
>  }
>  EXPORT_SYMBOL_GPL(nf_send_reset);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/net/ipv6/netfilter/nf_reject_ipv6.c 
> b/net/ipv6/netfilter/nf_reject_ipv6.c
> index 5f5f043..20d9def 100644
> --- a/net/ipv6/netfilter/nf_reject_ipv6.c
> +++ b/net/ipv6/netfilter/nf_reject_ipv6.c
> @@ -5,6 +5,8 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> +
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -161,3 +163,5 @@ void nf_send_reset6(struct net *net, struct sk_buff 
> *oldskb, int hook)
>   ip6_local_out(nskb);
>  }
>  EXPORT_SYMBOL_GPL(nf_send_reset6);
> +
> +MODULE_LICENSE("GPL");
> -- 
> 1.7.10.4
> 

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

[PATCH] regulator: s2mps11: add support for S2MPS15 regulators

[Thomas Abraham]

The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators and allows programming these regulators via a
I2C interface. This patch adds initial support for LDO/Buck regulators of
S2MPS15 PMIC.

Signed-off-by: Thomas Abraham 
---
 drivers/regulator/s2mps11.c |  133 +++
 1 files changed, 133 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index adab82d..e176fbb 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct s2mps11_info {
@@ -529,6 +530,133 @@ static const struct regulator_desc s2mps14_regulators[] = 
{
regulator_desc_s2mps14_buck(5, MIN_600_MV, STEP_6_25_MV),
 };
 
+static struct regulator_ops s2mps15_reg_ldo_ops = {
+   .list_voltage   = regulator_list_voltage_linear_range,
+   .map_voltage= regulator_map_voltage_linear_range,
+   .is_enabled = regulator_is_enabled_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+};
+
+static struct regulator_ops s2mps15_reg_buck_ops = {
+   .list_voltage   = regulator_list_voltage_linear_range,
+   .map_voltage= regulator_map_voltage_linear_range,
+   .is_enabled = regulator_is_enabled_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .set_voltage_time_sel   = regulator_set_voltage_time_sel,
+};
+
+#define regulator_desc_s2mps15_ldo(num, range) {   \
+   .name   = "LDO"#num,\
+   .id = S2MPS15_LDO##num, \
+   .ops= _reg_ldo_ops, \
+   .type   = REGULATOR_VOLTAGE,\
+   .owner  = THIS_MODULE,  \
+   .linear_ranges  = range,\
+   .n_linear_ranges = ARRAY_SIZE(range),   \
+   .n_voltages = S2MPS15_LDO_N_VOLTAGES,   \
+   .vsel_reg   = S2MPS15_REG_L1CTRL + num - 1, \
+   .vsel_mask  = S2MPS15_LDO_VSEL_MASK,\
+   .enable_reg = S2MPS15_REG_L1CTRL + num - 1, \
+   .enable_mask= S2MPS15_ENABLE_MASK   \
+}
+
+#define regulator_desc_s2mps15_buck(num, range) {  \
+   .name   = "BUCK"#num,   \
+   .id = S2MPS15_BUCK##num,\
+   .ops= _reg_buck_ops,\
+   .type   = REGULATOR_VOLTAGE,\
+   .owner  = THIS_MODULE,  \
+   .linear_ranges  = range,\
+   .n_linear_ranges = ARRAY_SIZE(range),   \
+   .ramp_delay = 12500,\
+   .n_voltages = S2MPS15_BUCK_N_VOLTAGES,  \
+   .vsel_reg   = S2MPS15_REG_B1CTRL2 + ((num - 1) * 2),\
+   .vsel_mask  = S2MPS15_BUCK_VSEL_MASK,   \
+   .enable_reg = S2MPS15_REG_B1CTRL1 + ((num - 1) * 2),\
+   .enable_mask= S2MPS14_ENABLE_MASK   \
+}
+
+/* voltage range for s2mps15 LDO 3, 5, 15, 16, 18, 20, 23 and 27 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges1[] = {
+   REGULATOR_LINEAR_RANGE(100, 0xc, 0x38, 25000),
+};
+
+/* voltage range for s2mps15 LDO 2, 6, 14, 17, 19, 21, 24 and 25 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges2[] = {
+   REGULATOR_LINEAR_RANGE(180, 0x0, 0x3f, 25000),
+};
+
+/* voltage range for s2mps15 LDO 4, 11, 12, 13, 22 and 26 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges3[] = {
+   REGULATOR_LINEAR_RANGE(70, 0x0, 0x34, 12500),
+};
+
+/* voltage range for s2mps15 LDO 7, 8, 9 and 10 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges4[] = {
+   REGULATOR_LINEAR_RANGE(70, 0xc, 0x18, 25000),
+};
+
+/* voltage range for s2mps15 LDO 1 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges5[] = {
+   REGULATOR_LINEAR_RANGE(50, 0x0, 0x20, 12500),
+};
+
+/* voltage range for s2mps15 BUCK 1, 2, 3, 4, 5, 6 and 7 */
+static const struct regulator_linear_range s2mps15_buck_voltage_ranges1[] = {
+   REGULATOR_LINEAR_RANGE(50, 0x10, 0xb0, 6250),
+};
+
+/* voltage range for s2mps15 BUCK 8, 9 and 10 */
+static const struct 

[PATCH v5 2/3] dt-bindings: iommu: Add documentation for rockchip iommu

[Daniel Kurtz]

Add binding documentation for Rockchip IOMMU.

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
---
 .../devicetree/bindings/iommu/rockchip,iommu.txt   | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
new file mode 100644
index 000..9a55ac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
@@ -0,0 +1,26 @@
+Rockchip IOMMU
+==
+
+A Rockchip DRM iommu translates io virtual addresses to physical addresses for
+its master device.  Each slave device is bound to a single master device, and
+shares its clocks, power domain and irq.
+
+Required properties:
+- compatible  : Should be "rockchip,iommu"
+- reg : Address space for the configuration registers
+- interrupts  : Interrupt specifier for the IOMMU instance
+- interrupt-names : Interrupt name for the IOMMU instance
+- #iommu-cells: Should be <0>.  This indicates the iommu is a
+"single-master" device, and needs no additional information
+to associate with its master device.  See:
+Documentation/devicetree/bindings/iommu/iommu.txt
+
+Example:
+
+   vopl_mmu: iommu@ff940300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff940300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopl_mmu";
+   #iommu-cells = <0>;
+   };
-- 
2.1.0.rc2.206.gedb03e5

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

[PATCH 0/2] mfd: sec: add S2MPS15 PMIC support

[Thomas Abraham]

Samsung's S2MPS15 PMIC is targetted to be used with Samsung's Exynos7 SoC.
The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators, RTC, three 32.768 KHz clock outputs and allows
programming these blocks via a I2C interface. This patch series adds initial
support for LDO/Buck regulators of S2MPS15 PMIC.

Thomas Abraham (2):
  dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
  mfd: sec: Add support for S2MPS15 PMIC

 Documentation/devicetree/bindings/mfd/s2mps11.txt |   11 +-
 drivers/mfd/sec-core.c|   26 
 include/linux/mfd/samsung/core.h  |1 +
 include/linux/mfd/samsung/s2mps15.h   |  161 +
 4 files changed, 196 insertions(+), 3 deletions(-)
 create mode 100644 include/linux/mfd/samsung/s2mps15.h

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

[PATCH 1/2] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Thomas Abraham]

Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.

Cc: devicet...@vger.kernel.org
Signed-off-by: Thomas Abraham 
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 0e4026a..41ee3f5 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -1,5 +1,5 @@
 
-* Samsung S2MPS11, S2MPS14 and S2MPU02 Voltage and Current Regulator
+* Samsung S2MPS11/14/15 and S2MPU02 Voltage and Current Regulator
 
 The Samsung S2MPS11 is a multi-function device which includes voltage and
 current regulators, RTC, charger controller and other sub-blocks. It is
@@ -7,8 +7,11 @@ interfaced to the host controller using an I2C interface. Each 
sub-block is
 addressed by the host system using different I2C slave addresses.
 
 Required properties:
-- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic"
-  or "samsung,s2mpu02-pmic".
+- compatible: Should be one of the following
+   - "samsung,s2mps11-pmic"
+   - "samsung,s2mps14-pmic"
+   - "samsung,s2mps15-pmic"
+   - "samsung,s2mpu02-pmic"
 - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
 
 Optional properties:
@@ -82,12 +85,14 @@ as per the datasheet of s2mps11.
  - valid values for n are:
- S2MPS11: 1 to 38
- S2MPS14: 1 to 25
+   - S2MPS15: 1 to 27
- S2MPU02: 1 to 28
  - Example: LDO1, LDO2, LDO28
- BUCKn
  - valid values for n are:
- S2MPS11: 1 to 10
- S2MPS14: 1 to 5
+   - S2MPS15: 1 to 10
- S2MPU02: 1 to 7
  - Example: BUCK1, BUCK2, BUCK9
 
-- 
1.6.6.rc2

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

[PATCH 2/2] mfd: sec: Add support for S2MPS15 PMIC

[Thomas Abraham]

Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.

Signed-off-by: Thomas Abraham 
---
 drivers/mfd/sec-core.c  |   26 ++
 include/linux/mfd/samsung/core.h|1 +
 include/linux/mfd/samsung/s2mps15.h |  161 +++
 3 files changed, 188 insertions(+), 0 deletions(-)
 create mode 100644 include/linux/mfd/samsung/s2mps15.h

diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index dba7e2b..6f33c2b 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -85,6 +86,12 @@ static const struct mfd_cell s2mps14_devs[] = {
}
 };
 
+static const struct mfd_cell s2mps15_devs[] = {
+   {
+   .name = "s2mps15-pmic",
+   },
+};
+
 static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -111,6 +118,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+   .compatible = "samsung,s2mps15-pmic",
+   .data = (void *)S2MPS15X,
+   }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -203,6 +213,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
 };
 
+static const struct regmap_config s2mps15_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = S2MPS15_REG_LDODSCH4,
+   .volatile_reg = s2mps11_volatile,
+   .cache_type = REGCACHE_FLAT,
+};
+
 static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -328,6 +347,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = _regmap_config;
break;
+   case S2MPS15X:
+   regmap = _regmap_config;
+   break;
case S5M8763X:
regmap = _regmap_config;
break;
@@ -382,6 +404,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+   case S2MPS15X:
+   sec_devs = s2mps15_devs;
+   num_sec_devs = ARRAY_SIZE(s2mps15_devs);
+   break;
case S2MPU02:
sec_devs = s2mpu02_devs;
num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index 1825eda..49ef612 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -42,6 +42,7 @@ enum sec_device_type {
S2MPA01,
S2MPS11X,
S2MPS14X,
+   S2MPS15X,
S2MPU02,
 };
 
diff --git a/include/linux/mfd/samsung/s2mps15.h 
b/include/linux/mfd/samsung/s2mps15.h
new file mode 100644
index 000..e82549a
--- /dev/null
+++ b/include/linux/mfd/samsung/s2mps15.h
@@ -0,0 +1,161 @@
+/*
+ * s2mps15.h
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *  http://www.samsung.com
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __LINUX_MFD_S2MPS15_H
+#define __LINUX_MFD_S2MPS15_H
+
+/* S2MPS15 registers */
+enum s2mps15_reg {
+   S2MPS15_REG_ID,
+   S2MPS15_REG_INT1,
+   S2MPS15_REG_INT2,
+   S2MPS15_REG_INT3,
+   S2MPS15_REG_INT1M,
+   S2MPS15_REG_INT2M,
+   S2MPS15_REG_INT3M,
+   S2MPS15_REG_ST1,
+   S2MPS15_REG_ST2,
+   S2MPS15_REG_PWRONSRC,
+   S2MPS15_REG_OFFSRC,
+   S2MPS15_REG_BU_CHG,
+   S2MPS15_REG_RTCCTRL,
+   S2MPS15_REG_CTRL1,
+   S2MPS15_REG_CTRL2,
+   S2MPS15_REG_RSVD1,
+   S2MPS15_REG_RSVD2,
+   S2MPS15_REG_RSVD3,
+   S2MPS15_REG_RSVD4,
+   S2MPS15_REG_RSVD5,
+   S2MPS15_REG_RSVD6,
+   S2MPS15_REG_CTRL3,
+   S2MPS15_REG_RSVD7,
+   S2MPS15_REG_RSVD8,
+   S2MPS15_REG_WRSTBI,
+   S2MPS15_REG_B1CTRL1,
+   S2MPS15_REG_B1CTRL2,
+   S2MPS15_REG_B2CTRL1,
+   S2MPS15_REG_B2CTRL2,
+   S2MPS15_REG_B3CTRL1,
+   S2MPS15_REG_B3CTRL2,
+   S2MPS15_REG_B4CTRL1,
+   S2MPS15_REG_B4CTRL2,
+   

[PATCH v5 1/3] iommu/rockchip: rk3288 iommu driver

[Daniel Kurtz]

The rk3288 has several iommus.  Each iommu belongs to a single master
device.  There is one device (ISP) that has two slave iommus, but that
case is not yet supported by this driver.

At subsys init, the iommu driver registers itself as the iommu driver for
the platform bus.  The master devices find their slave iommus using the
"iommus" field in their devicetree description.  Since each slave iommu
belongs to exactly one master, their is no additional data needed at probe
to associate a slave with its master.

An iommu device's power domain, clock and irq are all shared with its
master device, and the master device must be careful to attach from the
iommu only after powering and clocking it (and leave it powered and
clocked before detaching).  Because their is no guarantee what the status
of the iommu is at probe, and since the driver does not even know if the
device is powered, we delay requesting its irq until the master device
attaches, at which point we have a guarantee that the device is powered
and clocked and we can reset it and disable its interrupt mask.

An iommu_domain describes a virtual iova address space.  Each iommu_domain
has a corresponding page table that lists the mappings from iova to
physical address.

For the rk3288 iommu, the page table has two levels:
 The Level 1 "directory_table" has 1024 4-byte dte entries.
 Each dte points to a level 2 "page_table".
 Each level 2 page_table has 1024 4-byte pte entries.
 Each pte points to a 4 KiB page of memory.

An iommu_domain is created when a dma_iommu_mapping is created via
arm_iommu_create_mapping.  Master devices can then attach themselves to
this mapping (or attach the mapping to themselves?) by calling
arm_iommu_attach_device().  This in turn instructs the iommu driver to
write the page table's physical address into the slave iommu's "Directory
Table Entry" (DTE) register.

In fact multiple master devices, each with their own slave iommu device,
can all attach to the same mapping.  The iommus for these devices will
share the same iommu_domain and therefore point to the same page table.
Thus, the iommu domain maintains a list of iommu devices which are
attached.  This driver relies on the iommu core to ensure that all devices
have detached before destroying a domain.

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
Reviewed-by: Grant Grundler 
Reviewed-by: Stéphane Marchesin 
---
 drivers/iommu/Kconfig  |  12 +
 drivers/iommu/Makefile |   1 +
 drivers/iommu/rockchip-iommu.c | 924 +
 3 files changed, 937 insertions(+)
 create mode 100644 drivers/iommu/rockchip-iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd51122..d0a1261 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -152,6 +152,18 @@ config OMAP_IOMMU_DEBUG
 
  Say N unless you know you need this.
 
+config ROCKCHIP_IOMMU
+   bool "Rockchip IOMMU Support"
+   depends on ARCH_ROCKCHIP
+   select IOMMU_API
+   select ARM_DMA_USE_IOMMU
+   help
+ Support for IOMMUs found on Rockchip rk32xx SOCs.
+ These IOMMUs allow virtualization of the address space used by most
+ cores within the multimedia subsystem.
+ Say Y here if you are using a Rockchip SoC that includes an IOMMU
+ device.
+
 config TEGRA_IOMMU_GART
bool "Tegra GART IOMMU Support"
depends on ARCH_TEGRA_2x_SOC
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 16edef7..3e47ef3 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o 
irq_remapping.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
 obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
 obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
 obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
 obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
new file mode 100644
index 000..08e50fc
--- /dev/null
+++ b/drivers/iommu/rockchip-iommu.c
@@ -0,0 +1,924 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** MMU register offsets */
+#define RK_MMU_DTE_ADDR0x00/* Directory table address */
+#define RK_MMU_STATUS  0x04
+#define RK_MMU_COMMAND 0x08
+#define RK_MMU_PAGE_FAULT_ADDR 0x0C/* IOVA of last page fault */
+#define RK_MMU_ZAP_ONE_LINE0x10/* Shootdown one IOTLB entry */
+#define RK_MMU_INT_RAWSTAT 0x14/* IRQ status ignoring mask */
+#define 

[PATCH v5 3/3] ARM: dts: rk3288: add VOP iommu nodes

[Daniel Kurtz]

Add device nodes for the VOP iommus.
Device nodes for other iommus will be added in later patches.

The iommu nodes use the #iommu-cells property as described in:
  Documentation/devicetree/bindings/iommu/iommu.txt

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
---
 arch/arm/boot/dts/rk3288.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..df1170c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -271,6 +271,24 @@
status = "disabled";
};
 
+   vopb_mmu: iommu@ff930300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff930300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopb_mmu";
+   #iommu-cells = <0>;
+   status = "disabled";
+   };
+
+   vopl_mmu: iommu@ff940300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff940300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopl_mmu";
+   #iommu-cells = <0>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
-- 
2.1.0.rc2.206.gedb03e5

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

stuck at mutex_lock_killable in interate_dir

[Dave Young]

Hi,

[sent an same email on the calprit machine, but I did not receive it,
thus resend it, sorry for duplicate if you got the original one]

I got a 'D' state mutt process, it's killable though.
I think kernel stuck at below code:

linux/fs/readdir.c:
iterate_dir() -> mutex_lock_killable(>i_mutex);

Any idea about this? known issue?

BTW, I can keep the laptop on for testing about 1 day. I'm not sure I can
reproduce it after rebooting.

[20522.102611] [ cut here ]
[20522.102636] WARNING: CPU: 3 PID: 4201 at kernel/watchdog.c:267 
watchdog_overflow_callback+0xf1/0x109()
[20522.102641] Watchdog detected hard LOCKUP on cpu 3
[20522.102645] Modules linked in: macvtap macvlan kvm_intel ext3 jbd pl2303 
usbserial iwldvm i915 snd_hda_codec_hdmi mac80211 e1000e snd_hda_codec_conexant 
snd_hda_codec_generic iwlwifi btusb bluetooth sdhci_pci snd_hda_intel sdhci 
mmc_core cfg80211 i2c_algo_bit snd_hda_controller ptp snd_hda_codec snd_hwdep 
snd_pcm drm_kms_helper drm efivars snd_timer lpc_ich pps_core wmi thinkpad_acpi 
rfkill video loop
[20522.102744] CPU: 3 PID: 4201 Comm: mutt Not tainted 3.17.0-rc6+ #24
[20522.102750] Hardware name: LENOVO 4236NUC/4236NUC, BIOS 83ET76WW (1.46 ) 
07/05/2013
[20522.102755]   88021e2c6c28 8149af7b 
88021e2c6c70
[20522.102767]  88021e2c6c60 810638c9 810d8719 
0003
[20522.102777]   88021e2c6d98 88021e2c6ef8 
88021e2c6cc0
[20522.102788] Call Trace:
[20522.102793][] dump_stack+0x4e/0x7a
[20522.102817]  [] warn_slowpath_common+0x75/0x8e
[20522.102826]  [] ? watchdog_overflow_callback+0xf1/0x109
[20522.102836]  [] warn_slowpath_fmt+0x47/0x49
[20522.102847]  [] ? perf_event_task_disable+0x7f/0x7f
[20522.102856]  [] watchdog_overflow_callback+0xf1/0x109
[20522.102865]  [] __perf_event_overflow+0x131/0x22a
[20522.102873]  [] ? perf_event_task_disable+0x7f/0x7f
[20522.102885]  [] ? x86_perf_event_set_period+0x101/0x111
[20522.102894]  [] perf_event_overflow+0x14/0x16
[20522.102903]  [] intel_pmu_handle_irq+0x33f/0x3c8
[20522.102914]  [] perf_event_nmi_handler+0x25/0x3e
[20522.102925]  [] nmi_handle.isra.2+0x7a/0xdb
[20522.102933]  [] ? local_touch_nmi+0x1f/0x1f
[20522.102946]  [] ? validate_chain.isra.27+0x4/0x9ae
[20522.102954]  [] do_nmi+0xd8/0x34c
[20522.102964]  [] end_repeat_nmi+0x1e/0x2e
[20522.102975]  [] ? __this_cpu_preempt_check+0x13/0x16
[20522.102985]  [] ? validate_chain.isra.27+0x4/0x9ae
[20522.102995]  [] ? validate_chain.isra.27+0x4/0x9ae
[20522.103004]  [] ? validate_chain.isra.27+0x4/0x9ae
[20522.103008]  <>[] __lock_acquire+0x6ed/0xb24
[20522.103031]  [] ? sha_transform+0x246/0x1068
[20522.103041]  [] lock_acquire+0xa4/0xc4
[20522.103051]  [] ? lock_hrtimer_base.isra.26+0x20/0x43
[20522.103062]  [] _raw_spin_lock_irqsave+0x4b/0x5c
[20522.103070]  [] ? lock_hrtimer_base.isra.26+0x20/0x43
[20522.103079]  [] lock_hrtimer_base.isra.26+0x20/0x43
[20522.103087]  [] hrtimer_try_to_cancel+0x1d/0x8d
[20522.103095]  [] hrtimer_cancel+0x10/0x1b
[20522.103106]  [] tick_nohz_restart+0x12/0x7d
[20522.103116]  [] __tick_nohz_full_check+0xa1/0xa6
[20522.103126]  [] nohz_full_kick_work_func+0x9/0xb
[20522.103135]  [] irq_work_run_list+0x4a/0x68
[20522.103145]  [] ? tick_sched_handle+0x47/0x47
[20522.103153]  [] irq_work_run+0x2a/0x4a
[20522.103162]  [] update_process_times+0x4c/0x60
[20522.103171]  [] tick_sched_handle+0x42/0x47
[20522.103180]  [] tick_sched_timer+0x35/0x53
[20522.103188]  [] __run_hrtimer.isra.28+0x57/0xb0
[20522.103197]  [] hrtimer_interrupt+0xeb/0x1d2
[20522.103211]  [] ? ext4_follow_link+0x1c/0x1c
[20522.103220]  [] local_apic_timer_interrupt+0x4e/0x51
[20522.103228]  [] smp_apic_timer_interrupt+0x3a/0x4b
[20522.103236]  [] apic_timer_interrupt+0x72/0x80
[20522.103240][] ? str2hashbuf_signed+0x2f/0x80
[20522.103257]  [] ext4fs_dirhash+0x122/0x218
[20522.103266]  [] ? __kmalloc+0x82/0xfe
[20522.103276]  [] htree_dirblock_to_tree+0xd2/0x135
[20522.103285]  [] ext4_htree_fill_tree+0x173/0x21d
[20522.103294]  [] ? debug_smp_processor_id+0x17/0x19
[20522.103306]  [] ext4_readdir+0x27e/0x73f
[20522.103316]  [] ? mutex_lock_killable_nested+0x33d/0x59a
[20522.103325]  [] ? iterate_dir+0x38/0xff
[20522.103332]  [] ? iterate_dir+0x38/0xff
[20522.103341]  [] iterate_dir+0x70/0xff
[20522.103349]  [] SyS_getdents+0x7a/0xda
[20522.103356]  [] ? fillonedir+0xcf/0xcf
[20522.103364]  [] tracesys+0xe1/0xe6
[20522.103371] ---[ end trace 949cb4fa0993f833 ]---
[20553.806845] INFO: rcu_preempt detected stalls on CPUs/tasks: { 3} (detected 
by 0, t=18002 jiffies, g=181109, c=181108, q=0)
[20553.806872] Task dump for CPU 3:
[20553.806879] muttR  running task12768  4201   1825 0x00080008
[20553.806897]  8802133ae000 0006 0007 
ea000849f540
[20553.806909]  0046 8802133ae000 81498748 
8802150019c0
[20553.806921]  880206707ba8 8123dab1 880206707bc8 
81091ce9
[20553.806933] 

[PATCH] spi-nor:fsl-quadspi:Add LS1021 support for fsl_quadspi

[Chao Fu]

From: Chao Fu 

FSL Quadspi module register bitwise is big-endian, but on ohter paltform
is little endian.
Add functions for Quadspi register read/write for bitwise:
qspi_readl
qpsi_writel
Add devtype for LS1021:
struct fsl_qspi_devtype_data ls1_data

Signed-off-by: Chao Fu 
---
The patch is depend on pending patches:
http://patchwork.ozlabs.org/patch/353244/

 drivers/mtd/spi-nor/fsl-quadspi.c | 177 +++---
 1 file changed, 108 insertions(+), 69 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
b/drivers/mtd/spi-nor/fsl-quadspi.c
index edef8f1..2dd29c3 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -192,9 +192,11 @@
 #define SEQID_EN4B 10
 #define SEQID_BRWR 11
 
+
 enum fsl_qspi_devtype {
FSL_QUADSPI_VYBRID,
FSL_QUADSPI_IMX6SX,
+   FSL_QUADSPI_LS1,
 };
 
 struct fsl_qspi_devtype_data {
@@ -215,6 +217,12 @@ static struct fsl_qspi_devtype_data imx6sx_data = {
.txfifo = 512
 };
 
+static struct fsl_qspi_devtype_data ls1_data = {
+   .devtype = FSL_QUADSPI_LS1,
+   .rxfifo = 128,
+   .txfifo = 64
+};
+
 #define FSL_QSPI_MAX_CHIP  4
 struct fsl_qspi {
struct mtd_info mtd[FSL_QSPI_MAX_CHIP];
@@ -242,6 +250,23 @@ static inline int is_imx6sx_qspi(struct fsl_qspi *q)
return q->devtype_data->devtype == FSL_QUADSPI_IMX6SX;
 }
 
+static inline int is_ls1_qspi(struct fsl_qspi *q)
+{
+   return q->devtype_data->devtype == FSL_QUADSPI_LS1;
+}
+
+static inline void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem *addr)
+{
+   is_ls1_qspi(q) ? __raw_writel(cpu_to_be32(val), addr) :
+   __raw_writel(cpu_to_le32(val), addr);
+}
+
+static inline u32 qspi_readl(struct fsl_qspi *q, void __iomem *addr)
+{
+   return is_ls1_qspi(q) ? cpu_to_be32((__force u32) __raw_readl(addr)) :
+   cpu_to_le32((__force u32) __raw_readl(addr));
+}
+
 /*
  * An IC bug makes us to re-arrange the 32-bit data.
  * The following chips, such as IMX6SLX, have fixed this bug.
@@ -253,14 +278,14 @@ static inline u32 fsl_qspi_endian_xchg(struct fsl_qspi 
*q, u32 a)
 
 static inline void fsl_qspi_unlock_lut(struct fsl_qspi *q)
 {
-   writel(QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
-   writel(QUADSPI_LCKER_UNLOCK, q->iobase + QUADSPI_LCKCR);
+   qspi_writel(q, QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
+   qspi_writel(q, QUADSPI_LCKER_UNLOCK, q->iobase + QUADSPI_LCKCR);
 }
 
 static inline void fsl_qspi_lock_lut(struct fsl_qspi *q)
 {
-   writel(QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
-   writel(QUADSPI_LCKER_LOCK, q->iobase + QUADSPI_LCKCR);
+   qspi_writel(q, QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
+   qspi_writel(q, QUADSPI_LCKER_LOCK, q->iobase + QUADSPI_LCKCR);
 }
 
 static irqreturn_t fsl_qspi_irq_handler(int irq, void *dev_id)
@@ -269,8 +294,8 @@ static irqreturn_t fsl_qspi_irq_handler(int irq, void 
*dev_id)
u32 reg;
 
/* clear interrupt */
-   reg = readl(q->iobase + QUADSPI_FR);
-   writel(reg, q->iobase + QUADSPI_FR);
+   reg = qspi_readl(q, q->iobase + QUADSPI_FR);
+   qspi_writel(q, reg, q->iobase + QUADSPI_FR);
 
if (reg & QUADSPI_FR_TFF_MASK)
complete(>c);
@@ -281,7 +306,7 @@ static irqreturn_t fsl_qspi_irq_handler(int irq, void 
*dev_id)
 
 static void fsl_qspi_init_lut(struct fsl_qspi *q)
 {
-   void *__iomem base = q->iobase;
+   void __iomem *base = q->iobase;
int rxfifo = q->devtype_data->rxfifo;
struct spi_nor *nor = >nor[0];
u8 addrlen = (nor->addr_width == 3) ? ADDR24BIT : ADDR32BIT;
@@ -293,7 +318,7 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
 
/* Clear all the LUT table */
for (i = 0; i < QUADSPI_LUT_NUM; i++)
-   writel(0, base + QUADSPI_LUT_BASE + i * 4);
+   qspi_writel(q, 0, base + QUADSPI_LUT_BASE + i * 4);
 
/* Quad Read and DDR Quad Read*/
lut_base = SEQID_QUAD_READ * 4;
@@ -302,10 +327,13 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
if (nor->flash_read == SPI_NOR_QUAD) {
if (op == SPINOR_OP_READ_1_1_4 || op == SPINOR_OP_READ4_1_1_4) {
/* read mode : 1-1-4 */
-   writel(LUT0(CMD, PAD1, op) | LUT1(ADDR, PAD1, addrlen),
+   qspi_writel(q,
+   LUT0(CMD, PAD1, op) | LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
 
-   writel(LUT0(DUMMY, PAD1, dm) | LUT1(READ, PAD4, rxfifo),
+   qspi_writel(q,
+   LUT0(DUMMY, PAD1, dm)
+   | LUT1(READ, PAD4, rxfifo),
base + QUADSPI_LUT(lut_base + 1));
} else {
dev_err(nor->dev, "Unsupported opcode : 0x%.2x\n", 

Re: [RESUBMIT PATCH v4 7/8] regulator: sky81452: Add compatible string for device binding

[Mark Brown]

On Tue, Oct 14, 2014 at 10:11:12AM +0900, Gyungoh Yoo wrote:
> On Mon, Oct 13, 2014 at 12:35:12PM +0200, Mark Brown wrote:

> > If you're doing anything here you should convert the code to use the
> > simplified interface for parsing regulator data based on putting the
> > subnode name and regualtor name in the regulator descriptor.

> Thank you for the review.

> The driver has of_device_id.

> static const struct of_device_id sky81452_reg_of_match[] = {
> { .compatible = "skyworks,sky81452-regulator", },
> { }
> };

> And the MFD adds the driver with of_compatible="skyworks,sky81452-regulator".
> MFD core maps the device node and the regulator driver does
> not need to parse the subnode name.

No, that's for the device (and as I say I don't think this is a good
idea).  I'm talking about the parsing of the constraints from the DT.


signature.asc
Description: Digital signature

Re: [PATCH RFC 1/5] sched,numa: build table of node hop distance

[Rik van Riel]

On 10/14/2014 02:47 AM, Peter Zijlstra wrote:

On Sun, Oct 12, 2014 at 09:28:04AM -0400, Rik van Riel wrote:

On 10/12/2014 09:17 AM, Peter Zijlstra wrote:

On Wed, Oct 08, 2014 at 03:37:26PM -0400, r...@redhat.com wrote:

+   sched_domains_numa_hops = kzalloc(sizeof(int) * nr_node_ids * 
nr_node_ids, GFP_KERNEL);
+   if (!sched_domains_numa_hops)
+   return;


That's potentially a _BIG_ table (1M for a 512 node system).
The node_distance has magic allocations and is of u8 size, is there any
way we can re-use node_distance and avoid a second O(n^2) allocation?


You are right, this should be a u8 at the least.

Beyond that, I am not convinced that merging things into
the same array is worthwhile, since (IIRC) nr_node_ids
should be set to the actual number of nodes on the system
by then.


The thing is, it looks like all you do is compare hop distance, and the
order of the hop distances is the exact same order as the regular numa
distance. I could not find a place where you use the actual hop value.


I use the actual hop distances when doing the scoring
for glueless mesh topologies, in patch 4/5.


So if all you're interested in is the relative ordering, that should be
the same for both.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 2/3] dt-bindings: iommu: Add documentation for rockchip iommu

[Daniel Kurtz]

Add binding documentation for Rockchip IOMMU.

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
---
 .../devicetree/bindings/iommu/rockchip,iommu.txt   | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
new file mode 100644
index 000..810e058a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
@@ -0,0 +1,26 @@
+Rockchip IOMMU
+==
+
+A Rockchip DRM iommu translates io virtual addresses to physical addresses for
+its master device.  Each slave device is bound to a single master device, and
+shares its clocks, power domain and irq.
+
+Required properties:
+- compatible  : Should be "rockchip,iommu"
+- reg : Address space for the configuration registers
+- interrupts  : Interrupt specifier for the IOMMU instance
+- interrupt-names : Interrupt name for the IOMMU instance
+- #iommu-cells: Should be <0>.  This indicates the iommu is a
+"single-master" device, and needs no additional information
+to associate with its master device.  See:
+Documentation/devicetree/bindings/iommu/iommu.txt
+
+Example:
+
+   vopl_mmu: iommu@0xff940300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff940300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopl_mmu";
+   #iommu-cells = <0>;
+   };
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 1/3] iommu/rockchip: rk3288 iommu driver

[Daniel Kurtz]

The rk3288 has several iommus.  Each iommu belongs to a single master
device.  There is one device (ISP) that has two slave iommus, but that
case is not yet supported by this driver.

At subsys init, the iommu driver registers itself as the iommu driver for
the platform bus.  The master devices find their slave iommus using the
"iommus" field in their devicetree description.  Since each slave iommu
belongs to exactly one master, their is no additional data needed at probe
to associate a slave with its master.

An iommu device's power domain, clock and irq are all shared with its
master device, and the master device must be careful to attach from the
iommu only after powering and clocking it (and leave it powered and
clocked before detaching).  Because their is no guarantee what the status
of the iommu is at probe, and since the driver does not even know if the
device is powered, we delay requesting its irq until the master device
attaches, at which point we have a guarantee that the device is powered
and clocked and we can reset it and disable its interrupt mask.

An iommu_domain describes a virtual iova address space.  Each iommu_domain
has a corresponding page table that lists the mappings from iova to
physical address.

For the rk3288 iommu, the page table has two levels:
 The Level 1 "directory_table" has 1024 4-byte dte entries.
 Each dte points to a level 2 "page_table".
 Each level 2 page_table has 1024 4-byte pte entries.
 Each pte points to a 4 KiB page of memory.

An iommu_domain is created when a dma_iommu_mapping is created via
arm_iommu_create_mapping.  Master devices can then attach themselves to
this mapping (or attach the mapping to themselves?) by calling
arm_iommu_attach_device().  This in turn instructs the iommu driver to
write the page table's physical address into the slave iommu's "Directory
Table Entry" (DTE) register.

In fact multiple master devices, each with their own slave iommu device,
can all attach to the same mapping.  The iommus for these devices will
share the same iommu_domain and therefore point to the same page table.
Thus, the iommu domain maintains a list of iommu devices which are
attached.  This driver relies on the iommu core to ensure that all devices
have detached before destroying a domain.

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
Reviewed-by: Grant Grundler 
Reviewed-by: Stéphane Marchesin 
---
 drivers/iommu/Kconfig  |  12 +
 drivers/iommu/Makefile |   1 +
 drivers/iommu/rockchip-iommu.c | 924 +
 3 files changed, 937 insertions(+)
 create mode 100644 drivers/iommu/rockchip-iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd51122..d0a1261 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -152,6 +152,18 @@ config OMAP_IOMMU_DEBUG
 
  Say N unless you know you need this.
 
+config ROCKCHIP_IOMMU
+   bool "Rockchip IOMMU Support"
+   depends on ARCH_ROCKCHIP
+   select IOMMU_API
+   select ARM_DMA_USE_IOMMU
+   help
+ Support for IOMMUs found on Rockchip rk32xx SOCs.
+ These IOMMUs allow virtualization of the address space used by most
+ cores within the multimedia subsystem.
+ Say Y here if you are using a Rockchip SoC that includes an IOMMU
+ device.
+
 config TEGRA_IOMMU_GART
bool "Tegra GART IOMMU Support"
depends on ARCH_TEGRA_2x_SOC
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 16edef7..3e47ef3 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o 
irq_remapping.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
 obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
 obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
 obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
 obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
new file mode 100644
index 000..08e50fc
--- /dev/null
+++ b/drivers/iommu/rockchip-iommu.c
@@ -0,0 +1,924 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** MMU register offsets */
+#define RK_MMU_DTE_ADDR0x00/* Directory table address */
+#define RK_MMU_STATUS  0x04
+#define RK_MMU_COMMAND 0x08
+#define RK_MMU_PAGE_FAULT_ADDR 0x0C/* IOVA of last page fault */
+#define RK_MMU_ZAP_ONE_LINE0x10/* Shootdown one IOTLB entry */
+#define RK_MMU_INT_RAWSTAT 0x14/* IRQ status ignoring mask */
+#define 

[PATCH v4 3/3] ARM: dts: rk3288: add VOP iommu nodes

[Daniel Kurtz]

Add device nodes for the VOP iommus.
Device nodes for other iommus will be added in later patches.

The iommu nodes use the #iommu-cells property as described in:
  Documentation/devicetree/bindings/iommu/iommu.txt

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
---
 arch/arm/boot/dts/rk3288.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..df1170c 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -271,6 +271,24 @@
status = "disabled";
};
 
+   vopb_mmu: iommu@ff930300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff930300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopb_mmu";
+   #iommu-cells = <0>;
+   status = "disabled";
+   };
+
+   vopl_mmu: iommu@ff940300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff940300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopl_mmu";
+   #iommu-cells = <0>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gadget_configfs.txt: fix spelling of 'function'

[Frans Klaver]

On Tue, Oct 14, 2014 at 09:35:24AM +0200, Jiri Kosina wrote:
> your patch hasn't been lost, it's in my 'to-process' queue. It's merge 
> window now, plus this is a super-low priority patch. Please be patient, it 
> will eventually be processed.

Alright. I think I've been getting quite spoiled with feedback then ;)

Thanks for the update,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hyperv: Implement Time Synchronization using host time sample

[Greg KH]

On Tue, Oct 14, 2014 at 01:23:46AM -0700, Thomas Shao wrote:
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1786,6 +1786,7 @@ int do_adjtimex(struct timex *txc)
>  
>   return ret;
>  }
> +EXPORT_SYMBOL(do_adjtimex);

EXPORT_SYMBOL_GPL()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gadget_configfs.txt: fix spelling of 'function'

[Jiri Kosina]

On Tue, 14 Oct 2014, Frans Klaver wrote:

> > Signed-off-by: Frans Klaver 
> > ---
> >  Documentation/usb/gadget_configfs.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/usb/gadget_configfs.txt 
> > b/Documentation/usb/gadget_configfs.txt
> > index 4cf53e4..635e574 100644
> > --- a/Documentation/usb/gadget_configfs.txt
> > +++ b/Documentation/usb/gadget_configfs.txt
> > @@ -376,7 +376,7 @@ functions and binds them. This way the whole gadget is 
> > bound.
> >  configured, so config_groups for particular functions are defined
> >  in the functions implementation files drivers/usb/gadget/f_*.c.
> >  
> > -5. Funciton's code is written in such a way that it uses
> > +5. Function's code is written in such a way that it uses
> >  
> >  usb_get_function_instance(), which, in turn, calls request_module.
> >  So, provided that modprobe works, modules for particular functions
> > -- 
> > 2.1.0
> > 
> 
> Ping

Frans,

your patch hasn't been lost, it's in my 'to-process' queue. It's merge 
window now, plus this is a super-low priority patch. Please be patient, it 
will eventually be processed.

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

Re: [PATCH v9 net-next 2/4] net: filter: split filter.h and expose eBPF to user space

[Daniel Borkmann]

On 10/13/2014 11:49 PM, Alexei Starovoitov wrote:

On Mon, Oct 13, 2014 at 10:21 AM, Daniel Borkmann  wrote:

On 09/03/2014 05:46 PM, Daniel Borkmann wrote:
...


Ok, given you post the remaining two RFCs later on this window as
you indicate, I have no objections:

Acked-by: Daniel Borkmann 


Ping, Alexei, are you still sending the patch for bpf_common.h or
do you want me to take care of this?


It's not forgotten.
I'm not sending it only because net-next is closed
and it seems to be -next material.


Well, the point was since it's UAPI you're modifying, that it needs
to be shipped before it first gets exposed to user land ...

I think that should be reason enough ... there's no point in doing
this at a later point in time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

btrfs soft lockups: locks gone crazy

[Davidlohr Bueso]

Hello,

I'm getting massive amounts of cpu soft lockups in Linus's tree for
today. This occurs almost immediately and is very reproducible in aim7
disk workloads using btrfs:

 kernel:[  559.800017] NMI watchdog: BUG: soft lockup - CPU#114 stuck for 22s! 
[reaim:44435]
...
[  999.800070] Modules linked in: iptable_filter(E) ip_tables(E) x_tables(E) 
rpcsec_gss_krb5(E) auth_rpcgss(E) nfsv4(E) dns_resolver(E) nfs(E) lockd(E) 
grace(E) sunrpc(E) fscache(E) iscsi_ibft(E) iscsi_boot_sysfs(E) af_packet(E) 
x86_pkg_temp_thermal(E) intel_powerclamp(E) ext4(E) crc16(E) mbcache(E) 
coretemp(E) jbd2(E) kvm_intel(E) kvm(E) crct10dif_pclmul(E) crc32_pclmul(E) 
iTCO_wdt(E) sb_edac(E) iTCO_vendor_support(E) joydev(E) ghash_clmulni_intel(E) 
aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) 
cryptd(E) pcspkr(E) edac_core(E) i2c_i801(E) lpc_ich(E) mfd_core(E) ipmi_si(E) 
ipmi_msghandler(E) wmi(E) processor(E) shpchp(E) acpi_pad(E) button(E) 
dm_mod(E) btrfs(E) xor(E) raid6_pq(E) sd_mod(E) hid_generic(E) usbhid(E) 
sr_mod(E) cdrom(E) mgag200(E) syscopyarea(E) sysfillrect(E) ehci_pci(E) 
sysimgblt(E) i2c_algo_bit(E) drm_kms_helper(E) ixgbe(E) ahci(E) ehci_hcd(E) 
ttm(E) mdio(E) libahci(E) ptp(E) crc32c_intel(E) mpt2sas(E) pps_core(E) 
usbcore(E) drm(E) libata(E) raid_class(E) usb_common(E) dca(E) 
scsi_transport_sas(E) sg(E) scsi_mod(E) autofs4(E)
[  999.800070] CPU: 53 PID: 1027 Comm: kworker/u292:3 Tainted: GEL 
3.17.0-3-default+ #2
[  999.800070] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS 
BIVTSDP1.86B.0044.R01.1310221705 10/22/2013
[  999.800070] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[  999.800070] task: 882054e76190 ti: 882054e78000 task.ti: 
882054e78000
[  999.800070] RIP: 0010:[]  [] 
queue_read_lock_slowpath+0x86/0x90
[  999.800070] RSP: 0018:882054e7ba00  EFLAGS: 0216
[  999.800070] RAX: 8a64 RBX: 882054e7b9b0 RCX: 8a70
[  999.800070] RDX: 8a70 RSI: 00c0 RDI: 881833b49ea0
[  999.800070] RBP: 882054e7ba00 R08: 881833b49e64 R09: 0001
[  999.800070] R10:  R11:  R12: 881047377f00
[  999.800070] R13: 0007 R14: 88203bf6d520 R15: 8810
[  999.800070] FS:  () GS:88207f50() 
knlGS:
[  999.800070] CS:  0010 DS:  ES:  CR0: 80050033
[  999.800070] CR2: 006a7f80 CR3: 01a14000 CR4: 001407e0
[  999.800070] Stack:
[  999.800070]  882054e7ba10 81573cfc 882054e7ba70 
a033349b
[  999.800070]  882038e9ac80 88203b58fd00 882038cd4ed8 

[  999.800070]  882054e7ba68 881833b49e30 882057fb4800 
0001
[  999.800070] Call Trace:
[  999.800070]  [] _raw_read_lock+0x1c/0x30
[  999.800070]  [] btrfs_tree_read_lock+0x5b/0x120 [btrfs]
[  999.800070]  [] btrfs_read_lock_root_node+0x3b/0x50 [btrfs]
[  999.800070]  [] btrfs_search_slot+0x53a/0xab0 [btrfs]
[  999.800070]  [] ? cpumask_next_and+0x37/0x50
[  999.800070]  [] btrfs_lookup_file_extent+0x37/0x40 [btrfs]
[  999.800070]  [] __btrfs_drop_extents+0x16a/0xdb0 [btrfs]
[  999.800070]  [] ? __set_extent_bit+0x22c/0x550 [btrfs]
[  999.800070]  [] ? btrfs_alloc_path+0x1a/0x20 [btrfs]
[  999.800070]  [] 
insert_reserved_file_extent.constprop.58+0x9e/0x2f0 [btrfs]
[  999.800070]  [] btrfs_finish_ordered_io+0x2e5/0x600 [btrfs]
...

[ 1011.800059] CPU: 2 PID: 1 Comm: systemd Tainted: GEL 
3.17.0-3-default+ #2
[ 1011.800059] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS 
BIVTSDP1.86B.0044.R01.1310221705 10/22/2013
[ 1011.800059] task: 880857eb8010 ti: 880857ebc000 task.ti: 
880857ebc000
[ 1011.800059] RIP: 0010:[]  [] 
queue_read_lock_slowpath+0x86/0x90
[ 1011.800059] RSP: 0018:880857ebfce0  EFLAGS: 0202
[ 1011.800059] RAX: 8a64 RBX: 8808549cd910 RCX: 8a74
[ 1011.800059] RDX: 8a74 RSI: 00c4 RDI: 881833b49ea0
[ 1011.800059] RBP: 880857ebfce0 R08: 881833b49e64 R09: 
[ 1011.800059] R10: e8e7ffc4ed60 R11:  R12: 8808549cd900
[ 1011.800059] R13:  R14:  R15: 880855e931e0
[ 1011.800059] FS:  7f12cb6ec880() GS:88087f84() 
knlGS:
[ 1011.800059] CS:  0010 DS:  ES:  CR0: 80050033
[ 1011.800059] CR2: 7f12cb707000 CR3: 002054f16000 CR4: 001407e0
[ 1011.800059] Stack:
[ 1011.800059]  880857ebfcf0 81573cfc 880857ebfd50 
a033349b
[ 1011.800059]  880857ebfda8 811cf72e 880857ebfd20 
811cbef8
[ 1011.800059]  880857ebfda8 881833b49e30 882057fb4800 

[ 1011.800059] Call Trace:
[ 1011.800059]  [] _raw_read_lock+0x1c/0x30
[ 1011.800059]  [] btrfs_tree_read_lock+0x5b/0x120 [btrfs]
[ 1011.800059]  [] ? 

[PATCH] hyperv: Implement Time Synchronization using host time sample

[Thomas Shao]

In current hyper-v time sync service,it only gets the initial clock time
from the host. It didn't process the following time samples. This change
introduced a module parameter called host_time_sync. If it is set to true,
the guest will periodically sychronize it's time with the host clock using
host time sample. By default it is disabled, because we still recommend
user to configure NTP for time synchronization.

Signed-off-by: Thomas Shao 
Reviewed-by: K. Y. Srinivasan 
---
 drivers/hv/hv_util.c  |  114 +---
 kernel/time/timekeeping.c |1 +
 2 files changed, 107 insertions(+), 8 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 3b9c9ef..1d8390c 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -51,11 +51,30 @@
 #define HB_WS2008_MAJOR1
 #define HB_WS2008_VERSION  (HB_WS2008_MAJOR << 16 | HB_MINOR)
 
+#define  TIMESAMPLE_INTERVAL 50L  /* 5s in nanosecond */
+
+/*host sends time sample for every 5s.So the max polling interval
+ *is 128*5 = 640s.
+*/
+#define  TIME_ADJ_MAX_INTERVAL 128 /*Max polling interval */
+
 static int sd_srv_version;
 static int ts_srv_version;
 static int hb_srv_version;
 static int util_fw_version;
 
+/*host sends time sample for every 5s.So the initial polling interval
+ *is 5s.
+*/
+static s32 adj_interval = 1;
+
+/*The host_time_sync module parameter is used to control the time
+  sync between host and guest.
+*/
+static bool host_time_sync;
+module_param(host_time_sync, bool, (S_IRUGO | S_IWUSR));
+MODULE_PARM_DESC(host_time_sync, "If the guest sync time with host");
+
 static void shutdown_onchannelcallback(void *context);
 static struct hv_util_service util_shutdown = {
.util_cb = shutdown_onchannelcallback,
@@ -163,15 +182,61 @@ static void shutdown_onchannelcallback(void *context)
 /*
  * Set guest time to host UTC time.
  */
-static inline void do_adj_guesttime(u64 hosttime)
+static inline void do_adj_guesttime(u64 hosttime, bool forceSync)
 {
-   s64 host_tns;
-   struct timespec host_ts;
+   s64 host_tns, guest_tns, diff;
+   struct timespec host_ts, guest_ts;
+   struct timex txc;
+   s64 tickchg;
+   int diff_sign;
 
host_tns = (hosttime - WLTIMEDELTA) * 100;
host_ts = ns_to_timespec(host_tns);
 
-   do_settimeofday(_ts);
+   if (forceSync) {
+   do_settimeofday(_ts);
+   } else {
+   guest_ts = CURRENT_TIME;
+   guest_tns = timespec_to_ns(_ts);
+   diff = host_tns - guest_tns;
+   if (diff >= 0) {
+   diff_sign = 1;
+   } else {
+   diff_sign = -1;
+   diff = -diff;
+   }
+
+   /*1s in nanosecond */
+   if (diff > 10 || diff < -10) {
+   do_settimeofday(_ts);
+   return;
+   }
+
+   /*1ms in nanosecond */
+   if (diff > 100 || diff < -100) {
+   /* get the current tick value */
+   txc.modes = 0;
+   do_adjtimex();
+
+   tickchg = diff * TICK_USEC /
+   (TIMESAMPLE_INTERVAL * adj_interval);
+
+   if (tickchg > TICK_USEC/10)
+   tickchg = TICK_USEC/10;
+
+   if (txc.tick == TICK_USEC + diff_sign * tickchg)
+   return;
+
+   txc.modes = ADJ_TICK;
+   txc.tick = TICK_USEC + diff_sign * tickchg;
+
+   do_adjtimex();
+   } else {
+   /* double the polling interval*/
+   if (adj_interval < TIME_ADJ_MAX_INTERVAL)
+   adj_interval = adj_interval * 2;
+   }
+   }
 }
 
 /*
@@ -179,8 +244,9 @@ static inline void do_adj_guesttime(u64 hosttime)
  */
 
 struct adj_time_work {
-   struct work_struct work;
+   struct  work_struct work;
u64 host_time;
+   boolforceSync;
 };
 
 static void hv_set_host_time(struct work_struct *work)
@@ -188,7 +254,7 @@ static void hv_set_host_time(struct work_struct *work)
struct adj_time_work*wrk;
 
wrk = container_of(work, struct adj_time_work, work);
-   do_adj_guesttime(wrk->host_time);
+   do_adj_guesttime(wrk->host_time, wrk->forceSync);
kfree(wrk);
 }
 
@@ -202,11 +268,14 @@ static void hv_set_host_time(struct work_struct *work)
  * thing is, systime is automatically set to emulated hardware clock which may
  * not be UTC time or in the same time zone. So, to override these effects, we
  * use the first 50 time samples for initial system time setting.
+ * If the host_time_sync module parameter is set, we will use the host time
+ * samples to adjust guest time after the first 50 samples.
  */

Re: [PATCH v3 3/3] ARM: dts: rk3288: add VOP iommu nodes

[Daniel Kurtz]

On Tue, Oct 14, 2014 at 6:33 AM, Heiko Stübner  wrote:
> Hi Daniel,
>
> Am Samstag, 11. Oktober 2014, 02:30:48 schrieb Daniel Kurtz:
>> Add device nodes for the VOP iommus.
>> Device nodes for other iommus will be added in later patches.
>>
>> The iommu nodes use the #iommu-cells property as described in:
>>   Documentation/devicetree/bindings/iommu/iommu.txt
>>
>> Signed-off-by: Daniel Kurtz 
>> Signed-off-by: Simon Xue 
>> ---
>>  arch/arm/boot/dts/rk3288.dtsi | 18 ++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
>> index 5950b0a..cbc92fa 100644
>> --- a/arch/arm/boot/dts/rk3288.dtsi
>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>> @@ -271,6 +271,24 @@
>>   status = "disabled";
>>   };
>>
>> + vopb_mmu: iommu@0xff930300 {
>
> please use the address without the 0x here ... iommu@ff930300

I've been doing it wrong for a while and no one else noticed :-).  Thanks!
I will resend.

> Thanks
> Heiko
>
>> + compatible = "rockchip,iommu";
>> + reg = <0xff930300 0x100>;
>> + interrupts = ;
>> + interrupt-names = "vopb_mmu";
>> + #iommu-cells = <0>;
>> + status = "disabled";
>> + };
>> +
>> + vopl_mmu: iommu@0xff940300 {
>> + compatible = "rockchip,iommu";
>> + reg = <0xff940300 0x100>;
>> + interrupts = ;
>> + interrupt-names = "vopl_mmu";
>> + #iommu-cells = <0>;
>> + status = "disabled";
>> + };
>> +
>>   gic: interrupt-controller@ffc01000 {
>>   compatible = "arm,gic-400";
>>   interrupt-controller;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/6] cpufreq: Loongson1: Add cpufreq driver for Loongson1B

[Viresh Kumar]

On 14 October 2014 12:29, Kelvin Cheung  wrote:
>
> 2014-10-10 12:40 GMT+08:00 Viresh Kumar :

>> > +#include 
>> > +#include 
>>
>> Okay, it looks like I have forgotten some of the C basics :)
>> But wouldn't the above two lines search for this file in , unless
>> you have compiled it with something like -I include/linux ??
>> And even then I don't think loongson1.h is present there ..
>>
>> What am I missing ?
>
>
> The two header files are located in arch/mips/include/asm/mach-loongson1

Okay, but I didn't knew it works this way as well. I thought preprocessor will
search in include/ and arch/mips/include/ directories only and so you need to
do this:

#include 

Do you know why it works directly in your case? Probably for readability above
might be better ?

>> > +static int ls1x_cpufreq_notifier(struct notifier_block *nb,
>> > +unsigned long val, void *data)
>> > +{
>> > +   if (val == CPUFREQ_POSTCHANGE)
>> > +   current_cpu_data.udelay_val = loops_per_jiffy;
>> > +
>> > +   return NOTIFY_OK;
>> > +}
>>
>> Why don't you do this at a single place in mips core instead of every
>> mips cpufreq driver ?
>
>
> Most of MIPS CPUs use performance counter as the system timer, which is 
> built-in to the CPU core. They can't do cpufreq due to lack of external 
> timer. Therefore, the above section is not a common code.

Not sure if I understood your reply Or you understood mine :)
Let me try again to clarify the question. On freq change you need
to update 'current_cpu_data.udelay_val', this is done in both
loongson drivers.

What I was asking you is to register the notifier in some core code,
so that this isn't required to be done in all cpufreq drivers.

NOTE: The notifier routine will only be called if cpufreq is enabled
for the platform..

>> > +static int ls1x_cpufreq_probe(struct platform_device *pdev)
>> > +{
>> > +   struct plat_ls1x_cpufreq *pdata = pdev->dev.platform_data;
>> > +   struct clk *clk;
>> > +   int ret;
>> > +
>>
>> Try this code here:
>>
>> pdata = NULL;
>>
>> > +   if (!pdata && !pdata->clk_name && !pdata->osc_clk_name) {
>>
>> And tell me what happens here then. :)
>
>
> I will add an error message here.

Did you try what I asked you to? I wasn't talking about the message..
Though you better add it as well..

What I have asked you will result in kernel crash ..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Locking issues with cpufreq and sysfs

[Viresh Kumar]

On 13 October 2014 18:41, Prarit Bhargava  wrote:
> There are several issues with the current locking design of cpufreq.  Most

Sadly yes :(

> [Question: was the original reported deadlock "real"?  Did it really happen or
> did lockdep only report it (I may have asked this question previously and
> forgot the answer)?  The reason I ask is that this situation is very similar 
> to
> USB's device removal in which the sysfs attributes are removed for a device 
> but
> not the device it was called for.  I actually think that's part of the problem
> here.]

I am still not sure about those lockdep warnings :(

> The above, obviously, is a complete hack of the code but in a sense does
> mimic a proper locking fix.  However, even with this fix we are still left
> with a race in accessing the sysfs files.  Consider the following example,
>
> CPU 1: accesses scaling_setspeed to set cpu speed
>
> simultaneously,
>
> CPU 2: accesses scaling_governor to set governor to ondemand
>
> CPU 1 & 2 race ... and this can result in different critical situations.
> The first is that CPU 1 holds the scalling_setspeed open while CPU attempts
> to change the governor.  This results in a syfs warning about creating a
> file with an existing file name which in some cases can lead to additional
> corruption and a panic.  The second case is that CPU 1's setting of the speed
> is now done on the new governor -- which may or may not be correct.  In any
> case an argument could be made that the userspace program doing this type
> of action should be "smart" enough to confirm simultaneous changes... but
> in any case the kernel should not panic or corrupt data.
>
> The locking is insufficient here, Viresh.  I no longer believe that fixes
> to this locking scheme are the right way to move forward here.  I'm wondering
> if we can look at other alternatives such as maintaining a refcount or
> perhaps using a queuing mechanism for governor and policy related changes.

Probably this is similar to what I have been trying, i.e. to give access to only
a single thread to call __cpufreq_governor().

Can you please try the cpufreq/governor-fixes-v4 branch once ?

On 13 October 2014 18:41, Prarit Bhargava  wrote:
> There are several issues with the current locking design of cpufreq.  Most
> notably is the panic reported here:
>
> http://marc.info/?l=linux-kernel=140622451625236=2
>
> which was introduced by commit 955ef4833574636819cd269cfbae12f79cbde63a,
> cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT, which introduces
> a race in the changing of the cpufreq policy.  This change was introduced
> because of a lockdep deadlock warning that can be reproduced (on x86 with
> the acpi_cpufreq driver) via the following debug patch:
>
> iff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index b0c18ed..366cfb7 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -885,6 +885,7 @@ static struct freq_attr *acpi_cpufreq_attr[] = {
>
>  static struct cpufreq_driver acpi_cpufreq_driver = {
> .verify = cpufreq_generic_frequency_table_verify,
> +   .flags  = CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
> .target_index   = acpi_cpufreq_target,
> .bios_limit = acpi_processor_get_bios_limit,
> .init   = acpi_cpufreq_cpu_init,
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 61190f6..4cb488a 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2195,9 +2195,7 @@ static int cpufreq_set_policy(struct cpufreq_policy 
> *polic
> /* end old governor */
> if (old_gov) {
> __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
> -   up_write(>rwsem);
> __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT);
> -   down_write(>rwsem);
> }
>
> /* start new governor */
> @@ -2206,9 +2204,7 @@ static int cpufreq_set_policy(struct cpufreq_policy 
> *polic
> if (!__cpufreq_governor(policy, CPUFREQ_GOV_START))
> goto out;
>
> -   up_write(>rwsem);
> __cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT);
> -   down_write(>rwsem);
> }
>
> /* new governor failed, so re-start old one */
>
> (which causes the acpi-cpufreq driver to emulate the behaviour of the arm
> cpufreq driver), and by doing
>
> echo ondemand > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor
> cat /sys/devices/system/cpu/cpu5/cpufreq/ondemand/*
> echo conservative > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor
> exit 0
>
> [Question: was the original reported deadlock "real"?  Did it really happen or
> did lockdep only report it (I may have asked this question previously and
> forgot the answer)?  The reason I ask is that this situation is very similar 
> to
> USB's device removal in which the sysfs attributes are removed for a device 
> but
> not the device 

Re: [PATCH 1/2] mod_devicetable: fix incorrect plural

[Frans Klaver]

On Thu, Sep 4, 2014 at 12:58 AM, Frans Klaver  wrote:
> Signed-off-by: Frans Klaver 
> ---
>  include/linux/mod_devicetable.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 44eeef0..745def8 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -69,7 +69,7 @@ struct ieee1394_device_id {
>   * @bDeviceClass: Class of device; numbers are assigned
>   * by the USB forum.  Products may choose to implement classes,
>   * or be vendor-specific.  Device classes specify behavior of all
> - * the interfaces on a devices.
> + * the interfaces on a device.
>   * @bDeviceSubClass: Subclass of device; associated with bDeviceClass.
>   * @bDeviceProtocol: Protocol of device; associated with bDeviceClass.
>   * @bInterfaceClass: Class of interface; numbers are assigned
> --
> 2.1.0
>

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gadget_configfs.txt: fix spelling of 'function'

[Frans Klaver]

On Wed, Oct 01, 2014 at 03:30:31PM +0200, Frans Klaver wrote:
> Signed-off-by: Frans Klaver 
> ---
>  Documentation/usb/gadget_configfs.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/usb/gadget_configfs.txt 
> b/Documentation/usb/gadget_configfs.txt
> index 4cf53e4..635e574 100644
> --- a/Documentation/usb/gadget_configfs.txt
> +++ b/Documentation/usb/gadget_configfs.txt
> @@ -376,7 +376,7 @@ functions and binds them. This way the whole gadget is 
> bound.
>  configured, so config_groups for particular functions are defined
>  in the functions implementation files drivers/usb/gadget/f_*.c.
>  
> -5. Funciton's code is written in such a way that it uses
> +5. Function's code is written in such a way that it uses
>  
>  usb_get_function_instance(), which, in turn, calls request_module.
>  So, provided that modprobe works, modules for particular functions
> -- 
> 2.1.0
> 

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Fix the issue that lowmemkiller fell into a cycle that try to kill a task

[朱辉]

2014 09 24 23:36, Rik van Riel:
> On 09/22/2014 10:57 PM, Hui Zhu wrote:
>> The cause of this issue is when free memroy size is low and a lot of task is
>> trying to shrink the memory, the task that is killed by lowmemkiller cannot 
>> get
>> CPU to exit itself.
>>
>> Fix this issue with change the scheduling policy to SCHED_FIFO if a task's 
>> flag
>> is TIF_MEMDIE in lowmemkiller.
>
> Is it actually true that the task that was killed by lowmemkiller
> cannot get CPU time?

I am so sorry that answer this mail late because I tried to do more test 
around it.
But this issue is really hard to reproduce the issue.  I got a special 
app that can reproduce this issue easyly. But I still need retry a lot 
of times to repdroduce this issue.

And I found that most of time, the task cannot be killed because it is 
blocked by binder_lock.
It looks like there are something wrong with a task that get binder_lock 
and it is blocked by another thing.

So I make a patch that change a binder_lock to binder_lock_killable to 
handle this issue.(I will post it later)
It work sometime but I am not sure it is right.
And I just met one time, the kernel with the binder patch and without 
the lowmemkiller SCHED_FIFO patch, a task that didn't blocked by a lock. 
  And different tasks call lowmemkiller tried to kill this task.
I think the root cause of this issue is killed task cannot get cpu.
But I just got this issue one time.

>
> It is also possible that the task is busy in the kernel, for example
> in the reclaim code, and is not breaking out of some loop fast enough,
> despite the TIF_MEMDIE flag being set.
>
> I suspect SCHED_FIFO simply papers over that kind of issue, by not
> letting anything else run until the task is gone, instead of fixing
> the root cause of the problem.
>
>

According to I introduction, I think lowmemkiller SCHED_FIFO patch maybe 
can handle some issue.

Thanks,
Hui

Re: [PATCH v4 04/25] virtio: defer config changed notifications

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> Defer config changed notifications that arrive during
> probe/scan/freeze/restore.
>
> This will allow drivers to set DRIVER_OK earlier, without worrying about
> racing with config change interrupts.
>
> This change will also benefit old hypervisors (before 2009)
> that send interrupts without checking DRIVER_OK: previously,
> the callback could race with driver-specific initialization.
>
> This will also help simplify drivers.

But AFAICT you never *read* dev->config_changed.

You unconditionally trigger a config_changed event in
virtio_config_enable().  That's a bit weird, but probably OK.

How about the following change (on top of your patch).  I
think the renaming is clearer, and note the added if() test in
virtio_config_enable().

If you approve, I'll fold it in.

Cheers,
Rusty.

diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 2536701b098b..df598dd8c5c8 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -122,7 +122,7 @@ static void __virtio_config_changed(struct virtio_device 
*dev)
struct virtio_driver *drv = drv_to_virtio(dev->dev.driver);
 
if (!dev->config_enabled)
-   dev->config_changed = true;
+   dev->config_change_pending = true;
else if (drv && drv->config_changed)
drv->config_changed(dev);
 }
@@ -148,8 +148,9 @@ static void virtio_config_enable(struct virtio_device *dev)
 {
spin_lock_irq(>config_lock);
dev->config_enabled = true;
-   __virtio_config_changed(dev);
-   dev->config_changed = false;
+   if (dev->config_change_pending)
+   __virtio_config_changed(dev);
+   dev->config_change_pending = false;
spin_unlock_irq(>config_lock);
 }
 
@@ -253,7 +254,7 @@ int register_virtio_device(struct virtio_device *dev)
 
spin_lock_init(>config_lock);
dev->config_enabled = false;
-   dev->config_changed = false;
+   dev->config_change_pending = false;
 
/* We always start by resetting the device, in case a previous
 * driver messed it up.  This also tests that code path a little. */
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index 5636b119dc25..65261a7244fc 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -80,7 +80,7 @@ bool virtqueue_is_broken(struct virtqueue *vq);
  * @index: unique position on the virtio bus
  * @failed: saved value for CONFIG_S_FAILED bit (for restore)
  * @config_enabled: configuration change reporting enabled
- * @config_changed: configuration change reported while disabled
+ * @config_change_pending: configuration change reported while disabled
  * @config_lock: protects configuration change reporting
  * @dev: underlying device.
  * @id: the device type identification (used to match it with a driver).
@@ -94,7 +94,7 @@ struct virtio_device {
int index;
bool failed;
bool config_enabled;
-   bool config_changed;
+   bool config_change_pending;
spinlock_t config_lock;
struct device dev;
struct virtio_device_id id;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] blk-merge: fix blk_recount_segments

[Rusty Russell]

Ming Lei  writes:
> Hi Rusty,

Hi Ming! 

Sorry, I was on vacation.  I'm back and slowly working through
all my mail...

> 1, FIO script
> [global]
> direct=1
> size=128G
> bsrange=${BS}-${BS}
> timeout=60
> numjobs=4
> ioengine=libaio
> iodepth=64
> filename=/dev/vdb #backed by /dev/nullb0, 4 virtqueues per virtio-blk
> group_reporting=1
>
> [f]
> rw=randread

> 5, result
> 5.1 without Rusty's virtio-vring patch
> - BS=4K, throughput: 179K
> - BS=256K, throughput: 27540

(ie. always using indirect)

> 5.2 with Rusty's virtio-vring patch
> - BS=4K, throughput: 173K
> - BS=256K, throughput: 25350

(ie. usually using indirect).

> Looks throughput decreases if BS is 256K in case of your patch.

Interesting.  Looks like we're ending up with fewer descs in flight,
though I'm surprised: with 256K blocks I'd expect us to hit the
steady state of "all indirect" almost immediately.

Hmm... I think the heuristic in my patch is flawed.  Let me try again,
and get back to you.

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

Re: [PATCH v5] init: Disable defaults if init= fails

[Rusty Russell]

Andy Lutomirski  writes:
> If a user puts init=/whatever on the command line and /whatever
> can't be run, then the kernel will try a few default options before
> giving up.  If init=/whatever came from a bootloader prompt, then
> this is unexpected but probably harmless.  On the other hand, if it
> comes from a script (e.g. a tool like virtme or perhaps a future
> kselftest script), then the fallbacks are likely to exist, but
> they'll do the wrong thing.  For example, they might unexpectedly
> invoke systemd.
>
> This makes a failure to run the specified init= process be fatal.
>
> As a temporary measure, users can set CONFIG_INIT_FALLBACK=y to
> preserve the old behavior.  If no one speaks up, we can remove that
> option entirely after a release or two.
>
> Signed-off-by: Andy Lutomirski 

Acked-by: Rusty Russell 

Andrew, please apply.

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fs: Add a missing permission check to do_umount

[Linus Torvalds]

On Tue, Oct 14, 2014 at 7:33 AM, Andy Lutomirski  wrote:
>
> Linus, can you pull this?

Pulled. You didn't mark the commit for stable. Oversight?

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

Re: [PATCH RFC 1/5] sched,numa: build table of node hop distance

[Peter Zijlstra]

On Sun, Oct 12, 2014 at 09:28:04AM -0400, Rik van Riel wrote:
> On 10/12/2014 09:17 AM, Peter Zijlstra wrote:
> >On Wed, Oct 08, 2014 at 03:37:26PM -0400, r...@redhat.com wrote:
> >>+   sched_domains_numa_hops = kzalloc(sizeof(int) * nr_node_ids * 
> >>nr_node_ids, GFP_KERNEL);
> >>+   if (!sched_domains_numa_hops)
> >>+   return;
> >
> >That's potentially a _BIG_ table (1M for a 512 node system).
> >The node_distance has magic allocations and is of u8 size, is there any
> >way we can re-use node_distance and avoid a second O(n^2) allocation?
> 
> You are right, this should be a u8 at the least.
> 
> Beyond that, I am not convinced that merging things into
> the same array is worthwhile, since (IIRC) nr_node_ids
> should be set to the actual number of nodes on the system
> by then.

The thing is, it looks like all you do is compare hop distance, and the
order of the hop distances is the exact same order as the regular numa
distance. I could not find a place where you use the actual hop value.

So if all you're interested in is the relative ordering, that should be
the same for both.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: btrfs: kernel BUG at fs/btrfs/extent_io.c:676!

[Chris Mason]

On Sun, Oct 12, 2014 at 10:15 PM, Sasha Levin  
wrote:

Ping?

This BUG_ON()ing due to GFP_ATOMIC allocation failure is really silly 
:(


Agreed, I have a patch for this in testing.  It didn't make my first 
pull but I'll get it fixed up.


-chris


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

[RFC PATCH v3 4/5] dt-bindings: Document the standard property "poweroff-source"

[Romain Perier]

Signed-off-by: Romain Perier 
---
 Documentation/devicetree/bindings/power/poweroff.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/poweroff.txt

diff --git a/Documentation/devicetree/bindings/power/poweroff.txt 
b/Documentation/devicetree/bindings/power/poweroff.txt
new file mode 100644
index 000..845868b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/poweroff.txt
@@ -0,0 +1,18 @@
+* Generic Poweroff capability
+
+Power-management integrated circuits or miscellaneous harware components are
+sometimes able to control the system power. The device driver associated to 
these
+components might needs to define poweroff capability, which tells to the kernel
+how to switch off the system. The corresponding driver must have the standard
+property "poweroff-source" in its device node. This property marks the device 
as
+able to shutdown the system. In order to test if this property is found
+programmatically, use the helper function "of_system_has_poweroff_source" from
+of.h .
+
+Example:
+
+act8846: act8846@5 {
+compatible = "active-semi,act8846";
+status = "okay";
+poweroff-source;
+}
-- 
1.9.1

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

[RFC PATCH v3 3/5] ARM: dts: rockchip: Enable power off in pmic for Radxa Rock

[Romain Perier]

Add "poweroff-source" property to act8846 node.
shutdown/poweroff commands are now handled for this board.

Signed-off-by: Romain Perier 
---
 arch/arm/boot/dts/rk3188-radxarock.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts 
b/arch/arm/boot/dts/rk3188-radxarock.dts
index 15910c9..2a0 100644
--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts
@@ -141,6 +141,8 @@
pinctrl-names = "default";
pinctrl-0 = <_dvs0_ctl>;
 
+   poweroff-source;
+
regulators {
vcc_ddr: REG1 {
regulator-name = "VCC_DDR";
-- 
1.9.1

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

[RFC v3 PATCH 1/5] of: Add standard property for poweroff capability

[Romain Perier]

Several drivers create their own devicetree property when they register
poweroff capabilities. This is for example the case for mfd, regulator
or power drivers which define "vendor,system-power-controller" property.
This patch adds support for a standard property "poweroff-source"
which marks the device as able to shutdown the system.

Signed-off-by: Romain Perier 
---
 include/linux/of.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/of.h b/include/linux/of.h
index 6545e7a..27b3ba1 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -866,4 +866,15 @@ static inline int of_changeset_update_property(struct 
of_changeset *ocs,
 /* CONFIG_OF_RESOLVE api */
 extern int of_resolve_phandles(struct device_node *tree);
 
+/**
+ * of_system_has_poweroff_source - Tells if poweroff-source is found for 
device_node
+ * @np: Pointer to the given device_node
+ *
+ * return true if present false otherwise
+ */
+static inline bool of_system_has_poweroff_source(const struct device_node *np)
+{
+   return of_property_read_bool(np, "poweroff-source");
+}
+
 #endif /* _LINUX_OF_H */
-- 
1.9.1

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

[RFC PATCH v3 2/5] regulator: act8865: Add support to turn off all outputs

[Romain Perier]

When the property "poweroff-source" is found in the
devicetree, the function pm_power_off is defined. This function sends the
rights bit fields to the global off control register. shutdown/poweroff
commands are now supported for hardware components which use these PMU.

Signed-off-by: Romain Perier 
---
 drivers/regulator/act8865-regulator.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/regulator/act8865-regulator.c 
b/drivers/regulator/act8865-regulator.c
index afd06f9..76301ed 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -61,6 +61,8 @@
 #defineACT8846_REG12_VSET  0xa0
 #defineACT8846_REG12_CTRL  0xa1
 #defineACT8846_REG13_CTRL  0xb1
+#defineACT8846_GLB_OFF_CTRL0xc3
+#defineACT8846_OFF_SYSMASK 0x18
 
 /*
  * ACT8865 Global Register Map.
@@ -84,6 +86,7 @@
 #defineACT8865_LDO3_CTRL   0x61
 #defineACT8865_LDO4_VSET   0x64
 #defineACT8865_LDO4_CTRL   0x65
+#defineACT8865_MSTROFF 0x20
 
 /*
  * Field Definitions.
@@ -98,6 +101,8 @@
 
 struct act8865 {
struct regmap *regmap;
+   int off_reg;
+   int off_mask;
 };
 
 static const struct regmap_config act8865_regmap_config = {
@@ -275,6 +280,16 @@ static struct regulator_init_data
return NULL;
 }
 
+static struct i2c_client *act8865_i2c_client;
+static void act8865_power_off(void)
+{
+   struct act8865 *act8865;
+
+   act8865 = i2c_get_clientdata(act8865_i2c_client);
+   regmap_write(act8865->regmap, act8865->off_reg, act8865->off_mask);
+   while (1);
+}
+
 static int act8865_pmic_probe(struct i2c_client *client,
  const struct i2c_device_id *i2c_id)
 {
@@ -285,6 +300,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
int i, ret, num_regulators;
struct act8865 *act8865;
unsigned long type;
+   int off_reg, off_mask;
 
pdata = dev_get_platdata(dev);
 
@@ -304,10 +320,14 @@ static int act8865_pmic_probe(struct i2c_client *client,
case ACT8846:
regulators = act8846_regulators;
num_regulators = ARRAY_SIZE(act8846_regulators);
+   off_reg = ACT8846_GLB_OFF_CTRL;
+   off_mask = ACT8846_OFF_SYSMASK;
break;
case ACT8865:
regulators = act8865_regulators;
num_regulators = ARRAY_SIZE(act8865_regulators);
+   off_reg = ACT8865_SYS_CTRL;
+   off_mask = ACT8865_MSTROFF;
break;
default:
dev_err(dev, "invalid device id %lu\n", type);
@@ -345,6 +365,17 @@ static int act8865_pmic_probe(struct i2c_client *client,
return ret;
}
 
+   if (of_system_has_poweroff_source(dev->of_node)) {
+   if (!pm_power_off) {
+   act8865_i2c_client = client;
+   act8865->off_reg = off_reg;
+   act8865->off_mask = off_mask;
+   pm_power_off = act8865_power_off;
+   } else {
+   dev_err(dev, "Failed to set poweroff capability, 
already defined\n");
+   }
+   }
+
/* Finally register devices */
for (i = 0; i < num_regulators; i++) {
const struct regulator_desc *desc = [i];
-- 
1.9.1

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

[RFC PATCH v3 5/5] dt-bindings: Document the property poweroff-source for act8865 regulator

[Romain Perier]

Signed-off-by: Romain Perier 
---
 Documentation/devicetree/bindings/regulator/act8865-regulator.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt 
b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
index 865614b..01a5b07 100644
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
@@ -5,6 +5,10 @@ Required properties:
 - compatible: "active-semi,act8846" or "active-semi,act8865"
 - reg: I2C slave address
 
+Optional properties:
+- poweroff-source: Telling whether or not this pmic is controlling
+  the system power. See Documentation/devicetree/bindings/power/poweroff.txt .
+
 Any standard regulator properties can be used to configure the single 
regulator.
 
 The valid names for regulators are:
-- 
1.9.1

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

Re: [PATCH 3/3] spi: qup: Remove .owner field for driver

[Kiran Padwal]

On Monday 13 October 2014 06:39 PM, Mark Brown wrote:
> On Thu, Oct 09, 2014 at 01:12:08PM +0530, Kiran Padwal wrote:
>> There is no need to init .owner field.
>>
>> Based on the patch from Peter Griffin 
>> "mmc: remove .owner field for drivers using module_platform_driver"
>>
>> This patch removes the superfluous .owner field for drivers which
>> use the module_platform_driver API, as this is overridden in
>> platform_driver_register anyway."
> 
> Two problems:
>  - I'm missing patches 1 and 2.

These patches are same like this one,
[1] https://lkml.org/lkml/2014/10/9/58
[2] https://lkml.org/lkml/2014/10/9/52

>  - This only changes one driver but essentially every SPI driver
>initializes .owner - why is only thi sone driver being changed?
> 

Nothing more intention, but just remove superfluous .owner field for drivers 
which
use the module_platform_driver API, as this is overridden in
platform_driver_register anyway.

Thanks,
--Kiran
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6] i2c: rk3x: adjust the LOW divison based on characteristics of SCL

[Addy Ke]

As show in I2C specification:
- Standard-mode: the minimum HIGH period of the scl clock is 4.0us
 the minimum LOW period of the scl clock is 4.7us
- Fast-mode: the minimum HIGH period of the scl clock is 0.6us
 the minimum LOW period of the scl clock is 1.3us

I have measured i2c SCL waveforms in fast-mode by oscilloscope
on rk3288-pinky board. the LOW period of the scl clock is 1.3us.
It is so critical that we must adjust LOW division to increase
the LOW period of the scl clock.

Thanks Doug for the suggestion about division formulas.

Tested-by: Heiko Stuebner 
Reviewed-by: Doug Anderson 
Tested-by: Doug Anderson 
Signed-off-by: Addy Ke 
---
Changes in v2:
- remove Fast-mode plus and HS-mode
- use new formulas suggested by Doug
Changes in V3:
- use new formulas (sep 30) suggested by Doug
Changes in V4:
- fix some wrong style
- WARN_ONCE if min_low_div > max_low_div
Changes in V5:
- round up for i2c_rate and round down for scl_rate, suggested by Max
- place a WARN_ON if scl_rate < 1000, suggested by Max
- add div_high and div_low overflow protection, suggested by Max
Changes in V6:
- goto to jump to clk_disable if set_scl_rate return error

 drivers/i2c/busses/i2c-rk3x.c | 162 +++---
 1 file changed, 153 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index b41d979..47e85dc 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 /* Register Map */
@@ -428,18 +429,158 @@ out:
return IRQ_HANDLED;
 }
 
-static void rk3x_i2c_set_scl_rate(struct rk3x_i2c *i2c, unsigned long scl_rate)
+static int rk3x_i2c_calc_divs(unsigned long i2c_rate, unsigned long scl_rate,
+  unsigned long *div_low, unsigned long *div_high)
 {
-   unsigned long i2c_rate = clk_get_rate(i2c->clk);
-   unsigned int div;
+   unsigned long min_low_ns, min_high_ns;
+   unsigned long max_data_hold_ns;
+   unsigned long data_hold_buffer_ns;
+   unsigned long max_low_ns, min_total_ns;
+
+   unsigned long i2c_rate_khz, scl_rate_khz;
+
+   unsigned long min_low_div, min_high_div;
+   unsigned long max_low_div;
+
+   unsigned long min_div_for_hold, min_total_div;
+   unsigned long extra_div, extra_low_div, ideal_low_div;
+
+   /* Only support standard-mode and fast-mode */
+   if (WARN_ON(scl_rate > 40))
+   scl_rate = 40;
+
+   /* prevent scl_rate_khz from becoming 0 */
+   if (WARN_ON(scl_rate < 1000))
+   scl_rate = 1000;
+
+   /*
+* min_low_ns:  The minimum number of ns we need to hold low
+*  to meet i2c spec
+* min_high_ns: The minimum number of ns we need to hold high
+*  to meet i2c spec
+* max_low_ns:  The maximum number of ns we can hold low
+*  to meet i2c spec
+*
+* Note: max_low_ns should be (max data hold time * 2 - buffer)
+*   This is because the i2c host on Rockchip holds the data line
+*   for half the low time.
+*/
+   if (scl_rate <= 10) {
+   min_low_ns = 4700;
+   min_high_ns = 4000;
+   max_data_hold_ns = 3450;
+   data_hold_buffer_ns = 50;
+   } else {
+   min_low_ns = 1300;
+   min_high_ns = 600;
+   max_data_hold_ns = 900;
+   data_hold_buffer_ns = 50;
+   }
+   max_low_ns = max_data_hold_ns * 2 - data_hold_buffer_ns;
+   min_total_ns = min_low_ns + min_high_ns;
+
+   /* Adjust to avoid overflow */
+   i2c_rate_khz = DIV_ROUND_UP(i2c_rate, 1000);
+   scl_rate_khz = scl_rate / 1000;
 
-   /* set DIV = DIVH = DIVL
-* SCL rate = (clk rate) / (8 * (DIVH + 1 + DIVL + 1))
-*  = (clk rate) / (16 * (DIV + 1))
+   /*
+* We need the total div to be >= this number
+* so we don't clock too fast.
+*/
+   min_total_div = DIV_ROUND_UP(i2c_rate_khz, scl_rate_khz * 8);
+
+   /* These are the min dividers needed for min hold times. */
+   min_low_div = DIV_ROUND_UP(i2c_rate_khz * min_low_ns, 8 * 100);
+   min_high_div = DIV_ROUND_UP(i2c_rate_khz * min_high_ns, 8 * 100);
+   min_div_for_hold = (min_low_div + min_high_div);
+
+   /*
+* This is the maximum divider so we don't go over the max.
+* We don't round up here (we round down) since this is a max.
 */
-   div = DIV_ROUND_UP(i2c_rate, scl_rate * 16) - 1;
+   max_low_div = i2c_rate_khz * max_low_ns / (8 * 100);
+
+   if (min_low_div > max_low_div) {
+   WARN_ONCE(true,
+ "Conflicting, min_low_div %lu, max_low_div %lu\n",
+ min_low_div, max_low_div);
+   max_low_div = min_low_div;
+   }
 
- 

Re: [PATCH 1/3] input: alps: Reset mouse before identifying it

[Dmitry Torokhov]

On Fri, Oct 03, 2014 at 11:47:59AM +0200, Hans de Goede wrote:
> Hi,
> 
> Thanks for working on this!
> 
> On 10/03/2014 11:43 AM, Pali Rohár wrote:
> > On some systems after starting computer function alps_identify() does not 
> > detect
> > dual ALPS touchpad+trackstick device correctly and detect only touchpad.
> > 
> > Resetting ALPS device before identifiying it fixing this problem and both 
> > parts
> > touchpad and trackstick are detected.
> > 
> > Signed-off-by: Pali Rohár 
> > Tested-by: Pali Rohár 
> 
> Looks good and seems sensible:
> 
> Acked-by: Hans de Goede 

*sigh* I am not really happy about this, as we making boot longer and longer
for people without ALPS touchpads. It would be better if we only reset the
mouse when we knew we are dealing with ALPS, and even better if we only reset
it when we suspected that we missed trackstick. Any chance of doing this?

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 RESEND] gpio: lib-sysfs: Add 'wakeup' attribute

[Alexandre Courbot]

On Tue, Oct 14, 2014 at 8:47 AM, Sören Brinkmann
 wrote:
> Hi Alexandre,
>
> On Sat, 2014-10-11 at 01:54PM +0900, Alexandre Courbot wrote:
>> On Fri, Sep 5, 2014 at 2:58 AM, Soren Brinkmann
>>  wrote:
>> > Add an attribute 'wakeup' to the GPIO sysfs interface which allows
>> > marking/unmarking a GPIO as wake IRQ.
>> > The file 'wakeup' is created in each exported GPIOs directory, if an IRQ
>> > is associated with that GPIO and the irqchip implements set_wake().
>> > Writing 'enabled' to that file will enable wake for that GPIO, while
>> > writing 'disabled' will disable wake.
>> > Reading that file will return either 'disabled' or 'enabled' depening on
>> > the currently set flag for the GPIO's IRQ.
>> >
>> > Signed-off-by: Soren Brinkmann 
>> > ---
>> > Hi all,
>> >
>> > I originally submitted this patch with a few fixes for Zynq's GPIO driver
>> > (https://lkml.org/lkml/2014/8/29/391). Since this change is not just
>> > Zynq-related and has broader impact, Linus asked me to post this again, 
>> > separate
>> > from the Zynq series.
>> >
>> > Let me just quote myself from the original submission:
>> > "I'm still not fully convinced that the gpio_keys are the best
>> > replacement for the sysfs interface when it comes to inputs. For that
>> > reason and to have a way to do some quick wake testing, I'd like to
>> > propose adding the ability to control wake through the sysfs interface
>> > (patch 3)."
>>
>> I'm really sorry that I did not provide feedback sooner.  This is the
>> kind of area (IRQ) where I am not too confident and typically like to
>> hear what Linus has to say first. But I also have a few questions that
>> you could maybe answer for my own education. :)
>>
>> >
>> > Thanks,
>> > Sören
>> >
>> >  drivers/gpio/gpiolib-sysfs.c | 75 
>> > 
>> >  1 file changed, 69 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/gpio/gpiolib-sysfs.c b/drivers/gpio/gpiolib-sysfs.c
>> > index 5f2150b619a7..aaf021eaaff5 100644
>> > --- a/drivers/gpio/gpiolib-sysfs.c
>> > +++ b/drivers/gpio/gpiolib-sysfs.c
>> > @@ -286,6 +286,56 @@ found:
>> >
>> >  static DEVICE_ATTR(edge, 0644, gpio_edge_show, gpio_edge_store);
>> >
>> > +static ssize_t gpio_wakeup_show(struct device *dev,
>> > +   struct device_attribute *attr, char *buf)
>> > +{
>> > +   ssize_t status;
>> > +   const struct gpio_desc  *desc = dev_get_drvdata(dev);
>> > +   int irq = gpiod_to_irq(desc);
>> > +   struct irq_desc *irq_desc = irq_to_desc(irq);
>> > +
>> > +   mutex_lock(_lock);
>> > +
>> > +   if (irqd_is_wakeup_set(_desc->irq_data))
>> > +   status = sprintf(buf, "enabled\n");
>> > +   else
>> > +   status = sprintf(buf, "disabled\n");
>> > +
>> > +   mutex_unlock(_lock);
>> > +
>> > +   return status;
>> > +}
>> > +
>> > +static ssize_t gpio_wakeup_store(struct device *dev,
>> > +   struct device_attribute *attr, const char *buf, size_t 
>> > size)
>> > +{
>> > +   int ret;
>> > +   unsigned inton;
>> > +   struct gpio_desc*desc = dev_get_drvdata(dev);
>> > +   int irq = gpiod_to_irq(desc);
>> > +
>> > +   mutex_lock(_lock);
>> > +
>> > +   if (sysfs_streq("enabled", buf))
>> > +   on = true;
>> > +   else if (sysfs_streq("disabled", buf))
>> > +   on = false;
>> > +   else
>> > +   return -EINVAL;
>>
>> You forgot to release sysfs_lock before returning here.
>
> Right, I will fix this and send a v2. Good catch.
>
>>
>> > +
>> > +   ret = irq_set_irq_wake(irq, on);
>>
>> Just wondering: is it always safe to set the wake property of an IRQ
>> even if the direction of its associated GPIO is output? Does it make
>> sense at all to have the "wakeup" attribute file visible if the GPIO
>> is an output one?
>>
>> > +
>> > +   mutex_unlock(_lock);
>> > +
>> > +   if (ret)
>> > +   pr_warn("%s: failed to %s wake\n", __func__,
>> > +   on ? "enable" : "disable");
>> > +
>> > +   return size;
>> > +}
>> > +
>> > +static DEVICE_ATTR(wakeup, 0644, gpio_wakeup_show, gpio_wakeup_store);
>> > +
>> >  static int sysfs_set_active_low(struct gpio_desc *desc, struct device 
>> > *dev,
>> > int value)
>> >  {
>> > @@ -526,7 +576,7 @@ static struct class gpio_class = {
>> >  int gpiod_export(struct gpio_desc *desc, bool direction_may_change)
>> >  {
>> > unsigned long   flags;
>> > -   int status;
>> > +   int status, irq;
>> > const char  *ioname = NULL;
>> > struct device   *dev;
>> > int offset;
>> > @@ -582,11 +632,24 @@ int gpiod_export(struct gpio_desc *desc, bool 
>> > direction_may_change)
>> > goto 

[PATCH 17/24] perf evlist: Default to syswide target when no thread/cpu maps set

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

If all a tool wants is to do system wide event monitoring, there is no
more the need to setup thread_map and cpu_map objects, just call
perf_evlist__open() and it will do create one fd per CPU monitoring all
threads.

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-poovolkigu72brx4783uq...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/evlist.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 5fc7bd42c803..b4b54d84e9b0 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1175,11 +1175,51 @@ void perf_evlist__close(struct perf_evlist *evlist)
}
 }
 
+static int perf_evlist__create_syswide_maps(struct perf_evlist *evlist)
+{
+   int err = -ENOMEM;
+
+   /*
+* Try reading /sys/devices/system/cpu/online to get
+* an all cpus map.
+*
+* FIXME: -ENOMEM is the best we can do here, the cpu_map
+* code needs an overhaul to properly forward the
+* error, and we may not want to do that fallback to a
+* default cpu identity map :-\
+*/
+   evlist-cpus = cpu_map__new(NULL);
+   if (evlist-cpus == NULL)
+   goto out;
+
+   evlist-threads = thread_map__new_dummy();
+   if (evlist-threads == NULL)
+   goto out_free_cpus;
+
+   err = 0;
+out:
+   return err;
+out_free_cpus:
+   cpu_map__delete(evlist-cpus);
+   evlist-cpus = NULL;
+   goto out;
+}
+
 int perf_evlist__open(struct perf_evlist *evlist)
 {
struct perf_evsel *evsel;
int err;
 
+   /*
+* Default: one fd per CPU, all threads, aka systemwide
+* as sys_perf_event_open(cpu = -1, thread = -1) is EINVAL
+*/
+   if (evlist-threads == NULL  evlist-cpus == NULL) {
+   err = perf_evlist__create_syswide_maps(evlist);
+   if (err  0)
+   goto out_err;
+   }
+
perf_evlist__update_id_pos(evlist);
 
evlist__for_each(evlist, evsel) {
-- 
1.9.3

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

[PATCH 15/24] perf thread_map: Create dummy constructor out of open coded equivalent

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

Create a dummy thread_map, one that has just one entry and it is -1,
meaning 'all threads', as this ends up going down to perf_event_open().

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-8av26cz8uxmbnihl5mmry...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/thread_map.c | 21 +
 tools/perf/util/thread_map.h |  1 +
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/tools/perf/util/thread_map.c b/tools/perf/util/thread_map.c
index 5d3215912105..f93b9734735b 100644
--- a/tools/perf/util/thread_map.c
+++ b/tools/perf/util/thread_map.c
@@ -214,6 +214,17 @@ out_free_threads:
goto out;
 }
 
+struct thread_map *thread_map__new_dummy(void)
+{
+   struct thread_map *threads = malloc(sizeof(*threads) + sizeof(pid_t));
+
+   if (threads != NULL) {
+   threads-map[0] = -1;
+   threads-nr = 1;
+   }
+   return threads;
+}
+
 static struct thread_map *thread_map__new_by_tid_str(const char *tid_str)
 {
struct thread_map *threads = NULL, *nt;
@@ -224,14 +235,8 @@ static struct thread_map *thread_map__new_by_tid_str(const 
char *tid_str)
struct strlist *slist;
 
/* perf-stat expects threads to be generated even if tid not given */
-   if (!tid_str) {
-   threads = malloc(sizeof(*threads) + sizeof(pid_t));
-   if (threads != NULL) {
-   threads-map[0] = -1;
-   threads-nr = 1;
-   }
-   return threads;
-   }
+   if (!tid_str)
+   return thread_map__new_dummy();
 
slist = strlist__new(false, tid_str);
if (!slist)
diff --git a/tools/perf/util/thread_map.h b/tools/perf/util/thread_map.h
index 0cd8b3108084..95313f43cc0f 100644
--- a/tools/perf/util/thread_map.h
+++ b/tools/perf/util/thread_map.h
@@ -9,6 +9,7 @@ struct thread_map {
pid_t map[];
 };
 
+struct thread_map *thread_map__new_dummy(void);
 struct thread_map *thread_map__new_by_pid(pid_t pid);
 struct thread_map *thread_map__new_by_tid(pid_t tid);
 struct thread_map *thread_map__new_by_uid(uid_t uid);
-- 
1.9.3

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

[PATCH 13/24] perf callchain: Move the callchain_param extern to callchain.h

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

It was lost in hist.h, move it to where it belongs, callchain.h, as
there are places that gets hist.h by means of evsel.h, and since evsel.h
is being untangled from hist.h...

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-0rg7ji1jnbm6q6gj35j37...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/builtin-record.c| 1 +
 tools/perf/util/callchain.h| 2 ++
 tools/perf/util/evsel.c| 1 +
 tools/perf/util/hist.h | 2 --
 tools/perf/util/scripting-engines/trace-event-python.c | 1 +
 5 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 44c6f3d55ce7..a6b2132c666f 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -14,6 +14,7 @@
 #include util/parse-options.h
 #include util/parse-events.h
 
+#include util/callchain.h
 #include util/header.h
 #include util/event.h
 #include util/evlist.h
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 2a1f5a46543a..94cfefddf4db 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -65,6 +65,8 @@ struct callchain_param {
enum chain_key  key;
 };
 
+extern struct callchain_param callchain_param;
+
 struct callchain_list {
u64 ip;
struct map_symbol   ms;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 0580b13df2e6..a08376427448 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -15,6 +15,7 @@
 #include linux/perf_event.h
 #include sys/resource.h
 #include asm/bug.h
+#include callchain.h
 #include evsel.h
 #include evlist.h
 #include util.h
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index a039cd22b23c..ebfc25886cac 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -8,8 +8,6 @@
 #include color.h
 #include ui/progress.h
 
-extern struct callchain_param callchain_param;
-
 struct hist_entry;
 struct addr_location;
 struct symbol;
diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index 56ba07cce549..496f21cadd97 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -28,6 +28,7 @@
 
 #include ../../perf.h
 #include ../debug.h
+#include ../callchain.h
 #include ../evsel.h
 #include ../util.h
 #include ../event.h
-- 
1.9.3

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

[PATCH 22/24] perf tools: Fixup off-by-one comparision in maps__find

[Arnaldo Carvalho de Melo]

From: Namhyung Kim namhy...@kernel.org

map-end is the first addr _outside_ the a map, following the convention
of vm_area_struct-vm_end.

Signed-off-by: Namhyung Kim namhy...@kernel.org
Acked-by: Stephane Eranian eran...@google.com
Cc: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/r/8761fwh1nc@sejong.aot.lge.com
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/map.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 186418ba18db..2137c4596ec7 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -752,7 +752,7 @@ struct map *maps__find(struct rb_root *maps, u64 ip)
m = rb_entry(parent, struct map, rb_node);
if (ip  m-start)
p = (*p)-rb_left;
-   else if (ip  m-end)
+   else if (ip = m-end)
p = (*p)-rb_right;
else
return m;
-- 
1.9.3

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

[PATCH 20/24] perf machine: Add missing dsos-root rbtree root initialization

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

A segfault happens on 'perf test hists_link' because we end up using a
struct machines on the stack, and then machines__init() was not
initializing the newly introduced rb_root, just the existing list_head.

When we introduced struct dsos, to group the two ways to store dsos,
i.e. the linked list and the rbtree, we didn't turned the initialization
done in:

machines__init(machines-host) -
machine__init() -
INIT_LIST_HEAD

into a dsos__init() to keep on initializing the list_head but _as well_
initializing the rb_root, oops.

All worked because outside perf-test we probably zalloc the whole thing
which ends up initializing it in to NULL.

So the problem looks contained to 'perf test' that uses it on stack,
etc.

Reported-by: Jiri Olsa jo...@redhat.com
Acked-by: Waiman Long waiman.l...@hp.com,
Cc: Adrian Hunter adrian.hun...@intel.com,
Cc: Don Zickus dzic...@redhat.com
Cc: Douglas Hatch doug.ha...@hp.com
Cc: Ingo Molnar mi...@redhat.com
Cc: Jiri Olsa jo...@kernel.org
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Scott J Norton scott.nor...@hp.com
Cc: Waiman Long waiman.l...@hp.com,
Link: http://lkml.kernel.org/r/20141014180353.gf3...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/machine.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index b7d477fbda02..34fc7c8672e4 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -13,12 +13,18 @@
 #include symbol/kallsyms.h
 #include unwind.h
 
+static void dsos__init(struct dsos *dsos)
+{
+   INIT_LIST_HEAD(dsos-head);
+   dsos-root = RB_ROOT;
+}
+
 int machine__init(struct machine *machine, const char *root_dir, pid_t pid)
 {
map_groups__init(machine-kmaps);
RB_CLEAR_NODE(machine-rb_node);
-   INIT_LIST_HEAD(machine-user_dsos.head);
-   INIT_LIST_HEAD(machine-kernel_dsos.head);
+   dsos__init(machine-user_dsos);
+   dsos__init(machine-kernel_dsos);
 
machine-threads = RB_ROOT;
INIT_LIST_HEAD(machine-dead_threads);
-- 
1.9.3

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

[PATCH 23/24] perf symbols: Fix map-end fixup

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

When synthesizing maps from files that have incomplete symbol
information, like kallsyms, we need to fixup the end of maps by seting
its end from the -start of the next map, fix it to set prev_map-end to
curr_map-start, since -end is the first byte outside prev_map address
range.

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-ivbrj08sjakxdwkrcndbk...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/symbol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index be84f7a9838b..c787a43d529a 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -207,7 +207,7 @@ void __map_groups__fixup_end(struct map_groups *mg, enum 
map_type type)
for (nd = rb_next(prevnd); nd; nd = rb_next(nd)) {
prev = curr;
curr = rb_entry(nd, struct map, rb_node);
-   prev-end = curr-start - 1;
+   prev-end = curr-start;
}
 
/*
-- 
1.9.3

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

[PATCH 24/24] perf symbols: Make sym-end be the first address after the symbol range

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

To follow vm_area_struct-vm_end convention.

By adhering to the convention that -end is the first address outside
the symbol's range we can do things like:

sym-end = start + len;
len = sym-end - sym-start;

This is also now the convention used for struct map-end, fixing some
off-by-one bugs.

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Chuck Ebbert cebbert.l...@gmail.com
Cc: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-agomujr7tuqaq6lu7kr6z...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/annotate.c | 8 
 tools/perf/util/symbol.c   | 6 +++---
 tools/perf/util/symbol.h   | 2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 36437527dbb3..7dabde14ea54 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -478,7 +478,7 @@ static int __symbol__inc_addr_samples(struct symbol *sym, 
struct map *map,
 
pr_debug3(%s: addr=%# PRIx64 \n, __func__, map-unmap_ip(map, 
addr));
 
-   if (addr  sym-start || addr  sym-end)
+   if (addr  sym-start || addr = sym-end)
return -ERANGE;
 
offset = addr - sym-start;
@@ -836,7 +836,7 @@ static int symbol__parse_objdump_line(struct symbol *sym, 
struct map *map,
end = map__rip_2objdump(map, sym-end);
 
offset = line_ip - start;
-   if ((u64)line_ip  start || (u64)line_ip  end)
+   if ((u64)line_ip  start || (u64)line_ip = end)
offset = -1;
else
parsed_line = tmp2 + 1;
@@ -966,7 +966,7 @@ fallback:
kce.kcore_filename = symfs_filename;
kce.addr = map__rip_2objdump(map, sym-start);
kce.offs = sym-start;
-   kce.len = sym-end + 1 - sym-start;
+   kce.len = sym-end - sym-start;
if (!kcore_extract__create(kce)) {
delete_extract = true;
strlcpy(symfs_filename, kce.extract_filename,
@@ -987,7 +987,7 @@ fallback:
 disassembler_style ? -M  : ,
 disassembler_style ? disassembler_style : ,
 map__rip_2objdump(map, sym-start),
-map__rip_2objdump(map, sym-end+1),
+map__rip_2objdump(map, sym-end),
 symbol_conf.annotate_asm_raw ?  : --no-show-raw,
 symbol_conf.annotate_src ? -S : ,
 symfs_filename, filename);
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index c787a43d529a..078331140d8c 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -186,7 +186,7 @@ void symbols__fixup_end(struct rb_root *symbols)
curr = rb_entry(nd, struct symbol, rb_node);
 
if (prev-end == prev-start  prev-end != curr-start)
-   prev-end = curr-start - 1;
+   prev-end = curr-start;
}
 
/* Last entry */
@@ -229,7 +229,7 @@ struct symbol *symbol__new(u64 start, u64 len, u8 binding, 
const char *name)
sym = ((void *)sym) + symbol_conf.priv_size;
 
sym-start   = start;
-   sym-end = len ? start + len - 1 : start;
+   sym-end = len ? start + len : start;
sym-binding = binding;
sym-namelen = namelen - 1;
 
@@ -325,7 +325,7 @@ static struct symbol *symbols__find(struct rb_root 
*symbols, u64 ip)
 
if (ip  s-start)
n = n-rb_left;
-   else if (ip  s-end)
+   else if (ip = s-end)
n = n-rb_right;
else
return s;
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index bec4b7bd09de..eb2c19bf8d90 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -95,7 +95,7 @@ void symbols__delete(struct rb_root *symbols);
 
 static inline size_t symbol__size(const struct symbol *sym)
 {
-   return sym-end - sym-start + 1;
+   return sym-end - sym-start;
 }
 
 struct strlist;
-- 
1.9.3

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

[PATCH 19/24] perf evsel: Make some exit routines static

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

Since they are automatically called by other methods used by tools.

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-ne3g4any7q6ty5d6yv8t1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/evsel.c | 6 +++---
 tools/perf/util/evsel.h | 3 ---
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 7a3c4c47ceda..d1ecde0fd56c 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -725,7 +725,7 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts)
}
 }
 
-int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int nthreads)
+static int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int 
nthreads)
 {
int cpu, thread;
 
@@ -813,13 +813,13 @@ int perf_evsel__alloc_counts(struct perf_evsel *evsel, 
int ncpus)
return evsel-counts != NULL ? 0 : -ENOMEM;
 }
 
-void perf_evsel__free_fd(struct perf_evsel *evsel)
+static void perf_evsel__free_fd(struct perf_evsel *evsel)
 {
xyarray__delete(evsel-fd);
evsel-fd = NULL;
 }
 
-void perf_evsel__free_id(struct perf_evsel *evsel)
+static void perf_evsel__free_id(struct perf_evsel *evsel)
 {
xyarray__delete(evsel-sample_id);
evsel-sample_id = NULL;
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 5c80cf037e50..1d5c754aebc4 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -154,12 +154,9 @@ const char *perf_evsel__name(struct perf_evsel *evsel);
 const char *perf_evsel__group_name(struct perf_evsel *evsel);
 int perf_evsel__group_desc(struct perf_evsel *evsel, char *buf, size_t size);
 
-int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int nthreads);
 int perf_evsel__alloc_id(struct perf_evsel *evsel, int ncpus, int nthreads);
 int perf_evsel__alloc_counts(struct perf_evsel *evsel, int ncpus);
 void perf_evsel__reset_counts(struct perf_evsel *evsel, int ncpus);
-void perf_evsel__free_fd(struct perf_evsel *evsel);
-void perf_evsel__free_id(struct perf_evsel *evsel);
 void perf_evsel__free_counts(struct perf_evsel *evsel);
 void perf_evsel__close_fd(struct perf_evsel *evsel, int ncpus, int nthreads);
 
-- 
1.9.3

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

[PATCH 21/24] perf tools: fix off-by-one error in maps

[Arnaldo Carvalho de Melo]

From: Stephane Eranian eran...@google.com

This patch fixes off-by-one errors in the management of maps.

A map is defined by start address and length as implemented by
map__new():

  map__init(map, type, start, start + len, pgoff, dso);

  map-start = addr;
  map-end = end;

Consequently, the actual address range is [start; end[ map-end is the
first byte outside the range.

This patch fixes two bugs where upper bound checking was off-by-one.

In V2, we fix map_groups__fixup_overlappings() some more where
map-start was off-by-one as reported by Jiri.

Signed-off-by: Stephane Eranian eran...@google.com
Acked-by: Namhyung Kim namhy...@kernel.org
Cc: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Link: http://lkml.kernel.org/r/20141006083532.GA4850@quad
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/map.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b7090596ac50..186418ba18db 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -556,7 +556,7 @@ struct symbol *map_groups__find_symbol_by_name(struct 
map_groups *mg,
 
 int map_groups__find_ams(struct addr_map_symbol *ams, symbol_filter_t filter)
 {
-   if (ams-addr  ams-map-start || ams-addr  ams-map-end) {
+   if (ams-addr  ams-map-start || ams-addr = ams-map-end) {
if (ams-map-groups == NULL)
return -1;
ams-map = map_groups__find(ams-map-groups, ams-map-type,
@@ -664,7 +664,7 @@ int map_groups__fixup_overlappings(struct map_groups *mg, 
struct map *map,
goto move_map;
}
 
-   before-end = map-start - 1;
+   before-end = map-start;
map_groups__insert(mg, before);
if (verbose = 2)
map__fprintf(before, fp);
@@ -678,7 +678,7 @@ int map_groups__fixup_overlappings(struct map_groups *mg, 
struct map *map,
goto move_map;
}
 
-   after-start = map-end + 1;
+   after-start = map-end;
map_groups__insert(mg, after);
if (verbose = 2)
map__fprintf(after, fp);
-- 
1.9.3

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

[PATCH 18/24] perf evsel: Add missing 'target' struct forward declaration

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

We use it in evsel.h but were getting it indirectly, fix it.

Noticed while working on having evsel.h usable by rasd.c.

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-94t3jvw4tmzrq3dnovvpl...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/evsel.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index fee927404720..5c80cf037e50 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -99,6 +99,7 @@ union u64_swap {
 };
 
 struct cpu_map;
+struct target;
 struct thread_map;
 struct perf_evlist;
 struct record_opts;
-- 
1.9.3

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

Re: [PATCHSET 0/5] perf tools: Speed up dwarf callchain post-unwinding for libunwind (v4)

[Arnaldo Carvalho de Melo]

Em Mon, Oct 13, 2014 at 08:11:58PM +0200, Jiri Olsa escreveu:
 On Mon, Oct 06, 2014 at 09:45:58AM +0900, Namhyung Kim wrote:
  Namhyung Kim (5):
perf report: Set callchain_param.record_mode for future use
perf callchain: Create an address space per thread
perf callchain: Use global caching provided by libunwind
perf kvm: Use thread_{,_set}_priv helpers
perf trace: Use thread_{,_set}_priv helpers
 
 Acked-by: Jiri Olsa jo...@kernel.org

Ok, will merge/test/put it in my next patchkit,

- 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 07/24] perf evsel: Add hists helper

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

Not all tools need a hists instance per perf_evsel, so lets pave the way
to remove evsel-hists while leaving a way to access the hists from a
specially allocated evsel, one that comes with space at the end where
lives the evsel.

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-qlktkhe31w4mgtbd84035...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/builtin-annotate.c |  8 +++---
 tools/perf/builtin-diff.c | 21 ---
 tools/perf/builtin-report.c   | 18 +++--
 tools/perf/builtin-top.c  | 55 +--
 tools/perf/tests/hists_cumulate.c |  8 +++---
 tools/perf/tests/hists_filter.c   | 23 
 tools/perf/tests/hists_link.c | 23 ++--
 tools/perf/tests/hists_output.c   | 20 +++---
 tools/perf/ui/browsers/hists.c| 20 --
 tools/perf/ui/gtk/hists.c |  2 +-
 tools/perf/util/evsel.h   |  5 
 tools/perf/util/hist.c| 22 +---
 tools/perf/util/session.c |  4 +--
 tools/perf/util/sort.c|  4 +--
 14 files changed, 132 insertions(+), 101 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index be5939418425..c9a119e2113d 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -51,6 +51,7 @@ static int perf_evsel__add_sample(struct perf_evsel *evsel,
  struct addr_location *al,
  struct perf_annotate *ann)
 {
+   struct hists *hists = evsel__hists(evsel);
struct hist_entry *he;
int ret;
 
@@ -66,13 +67,12 @@ static int perf_evsel__add_sample(struct perf_evsel *evsel,
return 0;
}
 
-   he = __hists__add_entry(evsel-hists, al, NULL, NULL, NULL, 1, 1, 0,
-   true);
+   he = __hists__add_entry(hists, al, NULL, NULL, NULL, 1, 1, 0, true);
if (he == NULL)
return -ENOMEM;
 
ret = hist_entry__inc_addr_samples(he, evsel-idx, al-addr);
-   hists__inc_nr_samples(evsel-hists, true);
+   hists__inc_nr_samples(hists, true);
return ret;
 }
 
@@ -225,7 +225,7 @@ static int __cmd_annotate(struct perf_annotate *ann)
 
total_nr_samples = 0;
evlist__for_each(session-evlist, pos) {
-   struct hists *hists = pos-hists;
+   struct hists *hists = evsel__hists(pos);
u32 nr_samples = hists-stats.nr_events[PERF_RECORD_SAMPLE];
 
if (nr_samples  0) {
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index a3ce19f7aebd..8c5c11ca8c53 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -327,6 +327,7 @@ static int diff__process_sample_event(struct perf_tool 
*tool __maybe_unused,
  struct machine *machine)
 {
struct addr_location al;
+   struct hists *hists = evsel__hists(evsel);
 
if (perf_event__preprocess_sample(event, machine, al, sample)  0) {
pr_warning(problem processing %d event, skipping it.\n,
@@ -334,7 +335,7 @@ static int diff__process_sample_event(struct perf_tool 
*tool __maybe_unused,
return -1;
}
 
-   if (hists__add_entry(evsel-hists, al, sample-period,
+   if (hists__add_entry(hists, al, sample-period,
 sample-weight, sample-transaction)) {
pr_warning(problem incrementing symbol period, skipping 
event\n);
return -1;
@@ -346,9 +347,9 @@ static int diff__process_sample_event(struct perf_tool 
*tool __maybe_unused,
 * hists__output_resort() and precompute needs the total
 * period in order to sort entries by percentage delta.
 */
-   evsel-hists.stats.total_period += sample-period;
+   hists-stats.total_period += sample-period;
if (!al.filtered)
-   evsel-hists.stats.total_non_filtered_period += sample-period;
+   hists-stats.total_non_filtered_period += sample-period;
 
return 0;
 }
@@ -382,7 +383,7 @@ static void perf_evlist__collapse_resort(struct perf_evlist 
*evlist)
struct perf_evsel *evsel;
 
evlist__for_each(evlist, evsel) {
-   struct hists *hists = evsel-hists;
+   struct hists *hists = evsel__hists(evsel);
 
hists__collapse_resort(hists, NULL);
}
@@ -631,24 +632,26 @@ static void 

[PATCH 11/24] perf session: Remove last reference to hists struct

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

Now perf_session doesn't require that the evsels in its evlist are hists
containing ones.

Tools that are hists based and want to do per evsel events_stats
updates, if at some point this turns into a necessity, should do it in
the tool specific code, keeping the session class hists agnostic.

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-cli1bgwpo82mdikuhy3dj...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/builtin-annotate.c |  1 +
 tools/perf/builtin-report.c   |  1 +
 tools/perf/util/hist.c| 16 
 tools/perf/util/hist.h|  1 +
 tools/perf/util/session.c |  7 ---
 tools/perf/util/session.h |  1 -
 6 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index c9a119e2113d..a5969fa64503 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -214,6 +214,7 @@ static int __cmd_annotate(struct perf_annotate *ann)
 
if (dump_trace) {
perf_session__fprintf_nr_events(session, stdout);
+   perf_evlist__fprintf_nr_events(session-evlist, stdout);
goto out;
}
 
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 3750d635f0f7..8043b5a7240a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -487,6 +487,7 @@ static int __cmd_report(struct report *rep)
 
if (dump_trace) {
perf_session__fprintf_nr_events(session, stdout);
+   perf_evlist__fprintf_nr_events(session-evlist, stdout);
return 0;
}
}
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index f72ad9c36e39..b143e404e5b1 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -3,6 +3,7 @@
 #include hist.h
 #include session.h
 #include sort.h
+#include evlist.h
 #include evsel.h
 #include annotate.h
 #include math.h
@@ -1405,6 +1406,21 @@ int hists__link(struct hists *leader, struct hists 
*other)
return 0;
 }
 
+
+size_t perf_evlist__fprintf_nr_events(struct perf_evlist *evlist, FILE *fp)
+{
+   struct perf_evsel *pos;
+   size_t ret = 0;
+
+   evlist__for_each(evlist, pos) {
+   ret += fprintf(fp, %s stats:\n, perf_evsel__name(pos));
+   ret += events_stats__fprintf(evsel__hists(pos)-stats, fp);
+   }
+
+   return ret;
+}
+
+
 u64 hists__total_period(struct hists *hists)
 {
return symbol_conf.filter_relative ? 
hists-stats.total_non_filtered_period :
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 04a46e32f42f..a039cd22b23c 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -139,6 +139,7 @@ size_t events_stats__fprintf(struct events_stats *stats, 
FILE *fp);
 
 size_t hists__fprintf(struct hists *hists, bool show_header, int max_rows,
  int max_cols, float min_pcnt, FILE *fp);
+size_t perf_evlist__fprintf_nr_events(struct perf_evlist *evlist, FILE *fp);
 
 void hists__filter_by_dso(struct hists *hists);
 void hists__filter_by_thread(struct hists *hists);
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 66cae50b5c4c..896bac73ea08 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1375,16 +1375,9 @@ size_t perf_session__fprintf_dsos_buildid(struct 
perf_session *session, FILE *fp
 
 size_t perf_session__fprintf_nr_events(struct perf_session *session, FILE *fp)
 {
-   struct perf_evsel *pos;
size_t ret = fprintf(fp, Aggregated stats:\n);
 
ret += events_stats__fprintf(session-stats, fp);
-
-   evlist__for_each(session-evlist, pos) {
-   ret += fprintf(fp, %s stats:\n, perf_evsel__name(pos));
-   ret += events_stats__fprintf(evsel__hists(pos)-stats, fp);
-   }
-
return ret;
 }
 
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index ffb440462008..a4be851f1a90 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -2,7 +2,6 @@
 #define __PERF_SESSION_H
 
 #include trace-event.h
-#include hist.h
 #include event.h
 #include header.h
 #include machine.h
-- 
1.9.3

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

[PATCH 05/24] perf sched: Stop updating hists stats, not used

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo a...@redhat.com

Not used here, remove to reduce perf_evsel/hists structs interaction.

Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: David Ahern dsah...@gmail.com
Cc: Don Zickus dzic...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Jean Pihet jean.pi...@linaro.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Stephane Eranian eran...@google.com
Link: http://lkml.kernel.org/n/tip-cb7wkk4a3jpoovzim914i...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/builtin-sched.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 9c9287fbf8e9..891c3930080e 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1431,9 +1431,6 @@ static int perf_sched__process_tracepoint_sample(struct 
perf_tool *tool __maybe_
 {
int err = 0;
 
-   evsel-hists.stats.total_period += sample-period;
-   hists__inc_nr_samples(evsel-hists, true);
-
if (evsel-handler != NULL) {
tracepoint_handler f = evsel-handler;
err = f(tool, evsel, sample, machine);
-- 
1.9.3

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

[PATCH 04/24] perf callchain: Move callchain_param to util object in to fix python test

[Arnaldo Carvalho de Melo]

From: Jiri Olsa jo...@kernel.org

In following commit we changed the location of callchains data:

  72a128aa083a7f4cc4f800718aaae05d9c698e26
  perf tools: Move callchain config from record_opts to callchain_param

Now all callchains stuff stays in callchain_param struct, which adds its
dependency for evsel.c object and breaks python perf.so usage
(unresolved callchain_param).

Moving callchain_param into callchain.c and adding it into
python-ext-sources unleash just another dependency hell, so I ended up
adding callchain_param into util.c for now.

Signed-off-by: Jiri Olsa jo...@kernel.org
Cc: Adrian Hunter adrian.hun...@intel.com
Cc: Corey Ashford cjash...@linux.vnet.ibm.com
Cc: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Milian Wolff m...@milianw.de
Cc: Namhyung Kim namhy...@kernel.org
Cc: Paul Mackerras pau...@samba.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Link: 
http://lkml.kernel.org/r/1412179229-19466-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
 tools/perf/util/hist.c | 7 ---
 tools/perf/util/util.c | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 86569fa3651d..b47595697140 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -14,13 +14,6 @@ static bool hists__filter_entry_by_thread(struct hists 
*hists,
 static bool hists__filter_entry_by_symbol(struct hists *hists,
  struct hist_entry *he);
 
-struct callchain_param callchain_param = {
-   .mode   = CHAIN_GRAPH_REL,
-   .min_percent = 0.5,
-   .order  = ORDER_CALLEE,
-   .key= CCKEY_FUNCTION
-};
-
 u16 hists__col_len(struct hists *hists, enum hist_column col)
 {
return hists-col_len[col];
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 24e8d871b74e..d5eab3f3323f 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -14,6 +14,14 @@
 #include byteswap.h
 #include linux/kernel.h
 #include unistd.h
+#include callchain.h
+
+struct callchain_param callchain_param = {
+   .mode   = CHAIN_GRAPH_REL,
+   .min_percent = 0.5,
+   .order  = ORDER_CALLEE,
+   .key= CCKEY_FUNCTION
+};
 
 /*
  * XXX We need to find a better place for these things...
-- 
1.9.3

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

Re: [PATCH v2] char: hw_random: core.c: Changed from using strncat to strlcat

[Rickard Strandqvist]

2014-10-14 17:36 GMT+02:00 Jason Cooper ja...@lakedaemon.net:
 On Mon, Oct 13, 2014 at 11:20:35PM +0200, Rickard Strandqvist wrote:
 2014-10-12 21:22 GMT+02:00 Jason Cooper ja...@lakedaemon.net:
  Rickard,
 
  On Sun, Oct 12, 2014 at 12:49:31PM +0200, Rickard Strandqvist wrote:
  Changed from using strncat to strlcat to simplify the code
 
  I'd like to see a little more explicit discussion here.  As Guenter got
  caught up in the mis-understanding, I doubt he'd be the only one.  I
  think it's worth spelling out that the old code prevents overflowing the
  buffer 'buf' of size PAGE_SIZE.  And that strlcat() does that internally
  allowing this code to be more readable.
 
  It should also be mentioned that the final strlen(buf) is safe because
  every operation on buf will insert a NULL terminator within the
  buffers limit.
 
  thx,
 
  Jason.
 
  Signed-off-by: Rickard Strandqvist 
  rickard_strandqv...@spectrumdigital.se
  ---

 [1]

   drivers/char/hw_random/core.c |   12 
   1 file changed, 4 insertions(+), 8 deletions(-)
 
  diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
  index aa30a25..1500cfd 100644
  --- a/drivers/char/hw_random/core.c
  +++ b/drivers/char/hw_random/core.c
  @@ -281,7 +281,6 @@ static ssize_t hwrng_attr_available_show(struct 
  device *dev,
 char *buf)
   {
int err;
  - ssize_t ret = 0;
struct hwrng *rng;
 
err = mutex_lock_interruptible(rng_mutex);
  @@ -289,16 +288,13 @@ static ssize_t hwrng_attr_available_show(struct 
  device *dev,
return -ERESTARTSYS;
buf[0] = '\0';
list_for_each_entry(rng, rng_list, list) {
  - strncat(buf, rng-name, PAGE_SIZE - ret - 1);
  - ret += strlen(rng-name);
  - strncat(buf,  , PAGE_SIZE - ret - 1);
  - ret++;
  + strlcat(buf, rng-name, PAGE_SIZE);
  + strlcat(buf,  , PAGE_SIZE);
}
  - strncat(buf, \n, PAGE_SIZE - ret - 1);
  - ret++;
  + strlcat(buf, \n, PAGE_SIZE);
mutex_unlock(rng_mutex);
 
  - return ret;
  + return strlen(buf);
   }
 
   static DEVICE_ATTR(rng_current, S_IRUGO | S_IWUSR,
  --
  1.7.10.4


 Hi

 Do not know if I understand this right, you want to explain strlcat
 function better then ..?

 I want to see that the submitter of the patch has thought this through
 and isn't just blindly doing s/strn/strl/g and some cleanup.

 Please keep in mind that the kernel community is *huge* and no one
 person can see everything going on.  The type of fixes and cleanup
 you're doing crosses many sub-systems.  As a result, you haven't popped
 up on anyones radar as a regular contributor within a sub-system yet.

 iow, I didn't have the thought in my head Rickard, yeah, he's the guy
 doing the cppcheck and strn/l cleanup properly because none of your
 patches have crossed my inbox until now.

 But while I think this is something you have to learn, rather than
 typing it in git comment.

 Wether it's appropriate for the git comment or not is debatable, I'll
 agree.  The point I'm trying to make is that reviewers aren't
 super-human.  All I saw at first is a patch from someone I don't know
 changing buffer handling in crypto/rng code.  I had no indication in the
 email as to how carefully this had been done.  I'll call that out every
 time. :)

 A short explanation, here [1], would have let first-time reviewers of
 your patches know that you had taken the time to grok the code and
 wasn't blindly fulfilling a eudyptula challenge or similar.


Hi Jason!

Thanks for your response.
Yes, I've done patches all over in Kernel. And the response is
different everywhere, and this was the first time I got this response
:-)

But sure! You mean I should put this in git comment, or just that it
should have been included as a cover letter?

How about adding this line.
By using strlcat it is much easier to ensure that you do not write
past the maximum string length, which could simplify this code a bit.

Kind regards
Rickard Strandqvist
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option

[Eric W. Biederman]

Seth Forshee seth.fors...@canonical.com writes:

 On Tue, Oct 14, 2014 at 01:01:02PM -0700, Eric W. Biederman wrote:
 Michael j Theall mthe...@us.ibm.com writes:
 
  Seth Forshee seth.fors...@canonical.com wrote on 10/14/2014 09:25:55 AM:
 
  From: Seth Forshee seth.fors...@canonical.com
  To: Miklos Szeredi mik...@szeredi.hu
  Cc: fuse-de...@lists.sourceforge.net, Serge H. Hallyn 
  serge.hal...@ubuntu.com, linux-kernel@vger.kernel.org, Seth 
  Forshee seth.fors...@canonical.com, Eric W. Biederman 
  ebied...@xmission.com, linux-fsde...@vger.kernel.org
  Date: 10/14/2014 09:27 AM
  Subject: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs
  only with a mount option
  
  Allowing unprivileged users to provide arbitrary xattrs via fuse
  mounts bypasses the normal restrictions on setting xattrs. Such
  mounts should be restricted to reading and writing xattrs in the
  user.* namespace.
  
 
  Can you explain how the normal restrictions on setting xattrs are 
  bypassed?
 
 If the fuse server is not run by root.  Which is a large part of the
 point of fuse.

 So the server could for example return trusted.* xattrs which were not
 set by a privileged user.

  My filesystem still needs security.* and system.*, and it looks like
  xattr_permission already prevents non-privileged users from accessing
  trusted.*
 
 If the filesystem is mounted with nosuid (typical of a non-privileged
 mount of fuse) then the security.* attributes are ignored.

 That I wasn't aware of. In fact I still haven't found where this
 restriction is implemented.

My memory may be have been incomplete.  What I was thinking of is
security/commoncap.c the MNT_NOSUID check in get_file_caps.

Upon inspection that appears limited to file capabilities, and while
there are a few other MNT_NOSUID checks under security the feel far from
complete.

Sigh.

This deserves a hard look because if MNT_NOSUID is not sufficient than
it may be possible for me to insert a usb stick with an extN filesystem
with the right labels having it auto-mounted nosuid and subvert the
security of something like selinux.

 Nonetheless, a userns mount could be done without nosuid (though that
 mount will also be unaccessible outside of that namespace).

  It's difficult though to tell whether a mount is being performed
  on behalf of an unprivileged user since fuse mounts are ususally
  done via a suid root helper. Thus a new mount option,
  privileged_xattrs, is added to indicated that xattrs from other
  namespaces are allowed. This option can only be supplied by
  system-wide root; supplying the option as an unprivileged user
  will cause the mount to fail.
 
  I can't say I'm convinced that this is the right direction to head.
 
 With respect to defaults we could keep the current default if you
 have the global CAP_SYS_ADMIN privilege when the mount takes place
 and then avoid breaking anything.

 Except that unprivileged mounts are normally done by a suid root helper,
 which is why I've required both global CAP_SYS_ADMIN and a mount option
 to get the current default behavior.

If nosuid is sufficient that may break existing setups for no good
reason.

Shrug.  I won't have much time for a bit but I figured I would highlight
the potential security hole in existing setups.  So someone with time
this week can look at that.

Eric

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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-next,v2] hyperv: Add handling of IP header with option field in netvsc_set_hash()

[Haiyang Zhang]

In case that the IP header has optional field at the end, this patch will
get the port numbers after that field, and compute the hash.

Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Reviewed-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/net/hyperv/netvsc_drv.c |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 0fcb5e7..0d60c91 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -162,7 +162,7 @@ union sub_key {
  * data: network byte order
  * return: host byte order
  */
-static u32 comp_hash(u8 *key, int klen, u8 *data, int dlen)
+static u32 comp_hash(u8 *key, int klen, void *data, int dlen)
 {
union sub_key subk;
int k_next = 4;
@@ -176,7 +176,7 @@ static u32 comp_hash(u8 *key, int klen, u8 *data, int dlen)
for (i = 0; i  dlen; i++) {
subk.kb = key[k_next];
k_next = (k_next + 1) % klen;
-   dt = data[i];
+   dt = ((u8 *)data)[i];
for (j = 0; j  8; j++) {
if (dt  0x80)
ret ^= subk.ka;
@@ -191,6 +191,7 @@ static u32 comp_hash(u8 *key, int klen, u8 *data, int dlen)
 static bool netvsc_set_hash(u32 *hash, struct sk_buff *skb)
 {
struct iphdr *iphdr;
+   __be32 dbuf[3];
int data_len;
bool ret = false;
 
@@ -200,12 +201,15 @@ static bool netvsc_set_hash(u32 *hash, struct sk_buff 
*skb)
iphdr = ip_hdr(skb);
 
if (iphdr-version == 4) {
-   if (iphdr-protocol == IPPROTO_TCP)
+   dbuf[0] = iphdr-saddr;
+   dbuf[1] = iphdr-daddr;
+   if (iphdr-protocol == IPPROTO_TCP) {
+   dbuf[2] = *(__be32 *)tcp_hdr(skb)-source;
data_len = 12;
-   else
+   } else {
data_len = 8;
-   *hash = comp_hash(netvsc_hash_key, HASH_KEYLEN,
- (u8 *)iphdr-saddr, data_len);
+   }
+   *hash = comp_hash(netvsc_hash_key, HASH_KEYLEN, dbuf, data_len);
ret = true;
}
 
-- 
1.7.1

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

[3.13.y.z extended stable] Linux 3.13.11.9

[Kamal Mostafa]

I am announcing the release of the Linux 3.13.11.9 kernel.

The updated 3.13.y tree can be found at: 
  git://kernel.ubuntu.com/ubuntu/linux.git linux-3.13.y
and can be browsed at:
  
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.13.y;a=shortlog

The diff from v3.13.11.8 is posted as a follow-up to this email.

The 3.13.y extended stable tree is maintained by the Ubuntu Kernel Team.
For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

 -Kamal

-- 
 Makefile   |   2 +-
 arch/arm/include/asm/tls.h |  64 ++
 arch/arm/kernel/irq.c  |   2 +-
 arch/arm/kernel/process.c  |   2 +
 arch/arm/kernel/thumbee.c  |   2 +-
 arch/arm/kernel/traps.c|  17 +-
 arch/arm/mm/alignment.c|   3 +
 arch/arm64/kernel/irq.c|   2 +-
 arch/arm64/kernel/process.c|  18 ++
 arch/arm64/kernel/sys_compat.c |   6 +
 arch/ia64/pci/fixup.c  |   3 +-
 arch/mips/boot/compressed/decompress.c |   1 +
 arch/mips/kernel/mcount.S  |  12 ++
 arch/parisc/Makefile   |   7 +-
 arch/parisc/kernel/syscall.S   | 233 -
 arch/x86/include/asm/vga.h |   6 -
 arch/x86/kernel/smpboot.c  |   3 +
 arch/x86/pci/fixup.c   |   4 +-
 block/genhd.c  |  26 +--
 block/partition-generic.c  |   2 +-
 drivers/acpi/acpi_cmos_rtc.c   |   2 +-
 drivers/ata/ahci.c |  10 +
 drivers/ata/ata_piix.c |   8 +
 drivers/cpufreq/integrator-cpufreq.c   |   4 +-
 drivers/gpu/drm/ast/ast_main.c |   3 +-
 drivers/gpu/drm/i915/i915_gem.c|  11 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  14 +-
 drivers/gpu/drm/i915/i915_reg.h|  12 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c|  66 +++---
 drivers/gpu/drm/i915/intel_tv.c|   4 +
 drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c |   1 -
 drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c  |   1 +
 drivers/gpu/drm/nouveau/nouveau_vga.c  |   9 +
 drivers/gpu/drm/radeon/cik.c   |   4 +-
 drivers/gpu/drm/radeon/cik_sdma.c  |   7 -
 drivers/gpu/drm/radeon/ni_dma.c|   6 -
 drivers/gpu/drm/radeon/r600_dma.c  |   9 -
 drivers/gpu/drm/radeon/radeon_atombios.c   |  33 ++-
 drivers/gpu/drm/radeon/radeon_device.c |  11 +-
 drivers/gpu/drm/radeon/radeon_semaphore.c  |   2 +-
 drivers/gpu/vga/vga_switcheroo.c   |   6 +
 drivers/gpu/vga/vgaarb.c   |  38 +++-
 drivers/iio/accel/bma180.c |   2 +-
 drivers/iio/adc/ad_sigma_delta.c   |   2 +-
 drivers/iio/adc/at91_adc.c |  10 +-
 .../iio/common/hid-sensors/hid-sensor-trigger.c|   3 +-
 drivers/iio/common/st_sensors/st_sensors_trigger.c |   2 +-
 drivers/iio/gyro/itg3200_buffer.c  |   2 +-
 drivers/iio/imu/inv_mpu6050/inv_mpu_trigger.c  |   2 +-
 drivers/iio/inkern.c   |   2 +-
 drivers/iio/magnetometer/st_magn_core.c|  52 +++--
 drivers/infiniband/hw/qib/qib_debugfs.c|   3 +-
 drivers/infiniband/hw/qib/qib_qp.c |   8 -
 drivers/infiniband/ulp/isert/ib_isert.c|   7 +-
 drivers/input/keyboard/atkbd.c |   8 -
 drivers/input/mouse/elantech.c |   7 +
 drivers/input/serio/i8042-x86ia64io.h  |  15 ++
 drivers/input/serio/serport.c  |  45 +++-
 drivers/iommu/arm-smmu.c   |  12 +-
 drivers/iommu/fsl_pamu_domain.c|  10 +-
 drivers/md/dm-cache-target.c   |   4 +-
 drivers/md/raid1.c |  40 ++--
 drivers/md/raid5.c |  18 +-
 drivers/media/i2c/adv7604.c|   2 +-
 drivers/media/pci/cx18/cx18-driver.c   |   1 +
 drivers/media/v4l2-core/videobuf2-core.c   |   2 +-
 drivers/media/v4l2-core/videobuf2-dma-sg.c |   2 +-
 drivers/net/can/at91_can.c |   8 +-
 drivers/net/can/flexcan.c  |  41 +++-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c   |  25 ++-
 drivers/net/wireless/iwlwifi/dvm/rxon.c|  12 ++
 drivers/net/wireless/iwlwifi/iwl-config.h  |   2 +
 drivers/net/wireless/iwlwifi/iwl-nvm-parse.c   |   4 +-
 

Re: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option

[Andy Lutomirski]

On Tue, Oct 14, 2014 at 2:13 PM, Eric W. Biederman
ebied...@xmission.com wrote:
 Seth Forshee seth.fors...@canonical.com writes:

 On Tue, Oct 14, 2014 at 01:01:02PM -0700, Eric W. Biederman wrote:
 Michael j Theall mthe...@us.ibm.com writes:

  Seth Forshee seth.fors...@canonical.com wrote on 10/14/2014 09:25:55 AM:
 
  From: Seth Forshee seth.fors...@canonical.com
  To: Miklos Szeredi mik...@szeredi.hu
  Cc: fuse-de...@lists.sourceforge.net, Serge H. Hallyn
  serge.hal...@ubuntu.com, linux-kernel@vger.kernel.org, Seth
  Forshee seth.fors...@canonical.com, Eric W. Biederman
  ebied...@xmission.com, linux-fsde...@vger.kernel.org
  Date: 10/14/2014 09:27 AM
  Subject: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs
  only with a mount option
 
  Allowing unprivileged users to provide arbitrary xattrs via fuse
  mounts bypasses the normal restrictions on setting xattrs. Such
  mounts should be restricted to reading and writing xattrs in the
  user.* namespace.
 
 
  Can you explain how the normal restrictions on setting xattrs are
  bypassed?

 If the fuse server is not run by root.  Which is a large part of the
 point of fuse.

 So the server could for example return trusted.* xattrs which were not
 set by a privileged user.

  My filesystem still needs security.* and system.*, and it looks like
  xattr_permission already prevents non-privileged users from accessing
  trusted.*

 If the filesystem is mounted with nosuid (typical of a non-privileged
 mount of fuse) then the security.* attributes are ignored.

 That I wasn't aware of. In fact I still haven't found where this
 restriction is implemented.

 My memory may be have been incomplete.  What I was thinking of is
 security/commoncap.c the MNT_NOSUID check in get_file_caps.

 Upon inspection that appears limited to file capabilities, and while
 there are a few other MNT_NOSUID checks under security the feel far from
 complete.

 Sigh.

 This deserves a hard look because if MNT_NOSUID is not sufficient than
 it may be possible for me to insert a usb stick with an extN filesystem
 with the right labels having it auto-mounted nosuid and subvert the
 security of something like selinux.

It's this code in selinux/hooks.c:

if ((bprm-file-f_path.mnt-mnt_flags  MNT_NOSUID) ||
(bprm-unsafe  LSM_UNSAFE_NO_NEW_PRIVS))
new_tsec-sid = old_tsec-sid;


One might argue that this should actually generate -EPERM instead of
ignoring the label, but it should be safe against untrusted media.


 Nonetheless, a userns mount could be done without nosuid (though that
 mount will also be unaccessible outside of that namespace).

  It's difficult though to tell whether a mount is being performed
  on behalf of an unprivileged user since fuse mounts are ususally
  done via a suid root helper. Thus a new mount option,
  privileged_xattrs, is added to indicated that xattrs from other
  namespaces are allowed. This option can only be supplied by
  system-wide root; supplying the option as an unprivileged user
  will cause the mount to fail.
 
  I can't say I'm convinced that this is the right direction to head.

 With respect to defaults we could keep the current default if you
 have the global CAP_SYS_ADMIN privilege when the mount takes place
 and then avoid breaking anything.

 Except that unprivileged mounts are normally done by a suid root helper,
 which is why I've required both global CAP_SYS_ADMIN and a mount option
 to get the current default behavior.

 If nosuid is sufficient that may break existing setups for no good
 reason.

 Shrug.  I won't have much time for a bit but I figured I would highlight
 the potential security hole in existing setups.  So someone with time
 this week can look at that.

I think I have a better solution.  I'll send it out.

Serge had also mentioned adding some kind of hook to help LSMs handle
user namespaces more intelligently.

--Andy


 Eric




-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: unaligned accesses in SLAB etc.

[mroos]

  I'd like to know that your another problem is related to commit
  bf0dea23a9c0 (mm/slab: use percpu allocator for cpu cache).  So,
  if the commit is reverted, your another problem is also gone
  completely?
 
 The other problem has been present forever.

Umm? I am afraid I have been describing it badly. This random 
SIGBUS+SIGSEGV problem is new - I have not seen it before.

I have been able to do kernel compiles for years on sparc64 (modulo 
specific bugs in specific configurations) and 3.17 + start/end swap 
patch seems also stable for most machine. With yesterdays git + align 
patch, it dies with SIGBUS multiple times during compilation so it's a 
new regression for me.

Will try reverting that commit tomorrow.

My only other current sparc64 problems that I am seeing - V210/V440 die 
during bootup if compiled with gcc 4.9 and V480 dies with FATAL 
exceptions during bootups since previous kernel release. Maybe also 
exit_mmap warning - I do not know if they have been fixed, I see them 
rarely.

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

Re: [PATCH v5] init: Disable defaults if init= fails

[Andy Lutomirski]

On Tue, Oct 14, 2014 at 2:00 PM, Andrew Morton
a...@linux-foundation.org wrote:
 On Wed, 1 Oct 2014 11:13:14 -0700 Andy Lutomirski l...@amacapital.net wrote:

 On Wed, Oct 1, 2014 at 11:05 AM,  j...@joshtriplett.org wrote:
  On Tue, Sep 30, 2014 at 09:53:56PM -0700, Andy Lutomirski wrote:
  I significantly prefer default N.  Scripts that play with init= really
  don't want the fallback, and I can imagine contexts in which it could
  be a security problem.
 
  While I certainly would prefer the non-fallback behavior for init as
  well, standard kernel practice has typically been to use default y for
  previously built-in features that become configurable.  And I'd
  certainly prefer a compile-time configuration option like this (even
  with default y) over a strictinit kernel command-line option.
 

 Fair enough.

 So: default y for a release or two, then switch the default?  Having
 default y will annoy virtme, though it's not the end of the world.
 Virtme is intended to work with more-or-less-normal kernels.


 Adding another Kconfig option is tiresome.  What was wrong with strictinit=?

The consensus seems to be that adding a non-default option to get
sensible behavior would be unfortunate.  Also, I don't like
strictinit=, since backwards-compatible setups will have to do
init=foo strictinit=foo.  My original proposal was init=foo
strictinit.

TBH, my preference would be to make strict mode unconditional.
http://xkcd.com/1172/

--Andy

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

[PATCH v2 0/3] Pinctrl driver for Amlogic Meson SoCs

[Beniamino Galvani]

Hi,

this series introduces a driver for Amlogic Meson pinctrl and GPIOs,
adding the basic infrastructure for all the SoCs of the Meson family
and configuration data specific for Meson8.

I tested the pinmux and GPIO functionalities on a Tronsmart Vega S89e
TV box and everything seems to work, however I'm not so familiar with
the pinctrl subsystem and thus any feedback is very welcome.

Changes since v1 [https://lkml.org/lkml/2014/10/7/712]
 - added missing checks of return values
 - indentation fixes
 - added missing definitions of groups and functions for Meson8

Beniamino Galvani (3):
  pinctrl: add driver for Amlogic Meson SoCs
  pinctrl: meson: add device tree bindings documentation
  ARM: dts: meson8: add pinctrl and gpio nodes

 .../devicetree/bindings/pinctrl/meson,pinctrl.txt  |  79 ++
 arch/arm/boot/dts/meson8-vega-s89e.dts |  16 +-
 arch/arm/boot/dts/meson8.dtsi  |  35 +
 arch/arm/mach-meson/Kconfig|   3 +
 drivers/pinctrl/Kconfig|   8 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/meson/Makefile |   2 +
 drivers/pinctrl/meson/pinctrl-meson.c  | 824 +
 drivers/pinctrl/meson/pinctrl-meson.h  | 217 ++
 drivers/pinctrl/meson/pinctrl-meson8.c | 534 +
 include/dt-bindings/gpio/meson8-gpio.h | 155 
 11 files changed, 1873 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
 create mode 100644 drivers/pinctrl/meson/Makefile
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson.c
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson.h
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson8.c
 create mode 100644 include/dt-bindings/gpio/meson8-gpio.h

-- 
1.9.1

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

[PATCH v2 3/3] ARM: dts: meson8: add pinctrl and gpio nodes

[Beniamino Galvani]

Add pinctrl node to meson8.dtsi and gpio-leds node to
meson8-vega-s89e.dts

Signed-off-by: Beniamino Galvani b.galv...@gmail.com
---
 arch/arm/boot/dts/meson8-vega-s89e.dts | 16 +++-
 arch/arm/boot/dts/meson8.dtsi  | 35 ++
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/meson8-vega-s89e.dts 
b/arch/arm/boot/dts/meson8-vega-s89e.dts
index 950998f..70a05c1 100644
--- a/arch/arm/boot/dts/meson8-vega-s89e.dts
+++ b/arch/arm/boot/dts/meson8-vega-s89e.dts
@@ -45,7 +45,9 @@
 
 
 /dts-v1/;
-/include/ meson8.dtsi
+#include meson8.dtsi
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/gpio/meson8-gpio.h
 
 / {
model = Tronsmart Vega S89 Elite;
@@ -58,8 +60,20 @@
memory {
reg = 0x4000 0x8000;
};
+
+   gpio-leds {
+   compatible = gpio-leds;
+
+   power {
+   gpios = gpio_ao GPIO_TEST_N GPIO_ACTIVE_LOW;
+   linux,default-trigger = none;
+   };
+   };
+
 };
 
 uart_AO {
status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = uart_ao_a;
 };
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 42e4026..c82f597 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -85,4 +85,39 @@
compatible = fixed-clock;
clock-frequency = 14166;
};
+
+   pinctrl: pinctrl@c1109880 {
+   compatible = amlogic,meson8-pinctrl;
+   reg = 0xc1109880 0x10;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   gpio: banks@c11080b0 {
+   reg = 0xc11080b0 0x28,
+ 0xc11080e4 0x18,
+ 0xc1108120 0x18,
+ 0xc1108030 0x30;
+   reg-names = mux, pull-enable, pull, gpio;
+   gpio-controller;
+   #gpio-cells = 2;
+   };
+
+   gpio_ao: ao-bank@c1108030 {
+   reg = 0xc8100014 0x4,
+ 0xc810002c 0x4,
+ 0xc8100024 0x8;
+   reg-names = mux, pull, gpio;
+   gpio-controller;
+   #gpio-cells = 2;
+   };
+
+   uart_ao_a: uart_ao_a {
+   uart_ao_a {
+   pins = uart_tx_ao_a, uart_rx_ao_a;
+   function = uart_ao;
+   };
+   };
+   };
+
 }; /* end of / */
-- 
1.9.1

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

[PATCH v2 1/3] pinctrl: add driver for Amlogic Meson SoCs

[Beniamino Galvani]

This is a driver for the pinmux and GPIO controller available in
Amlogic Meson SoCs. At the moment it only supports Meson8 devices,
however other SoC families like Meson6 and Meson8b (the Cortex-A5
variant) appear to be similar, with just different sets of banks and
registers.

GPIO interrupts are not supported at the moment due to lack of
documentation.

Signed-off-by: Beniamino Galvani b.galv...@gmail.com
---
 arch/arm/mach-meson/Kconfig|   3 +
 drivers/pinctrl/Kconfig|   8 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/meson/Makefile |   2 +
 drivers/pinctrl/meson/pinctrl-meson.c  | 824 +
 drivers/pinctrl/meson/pinctrl-meson.h  | 217 +
 drivers/pinctrl/meson/pinctrl-meson8.c | 534 +
 include/dt-bindings/gpio/meson8-gpio.h | 155 +++
 8 files changed, 1744 insertions(+)
 create mode 100644 drivers/pinctrl/meson/Makefile
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson.c
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson.h
 create mode 100644 drivers/pinctrl/meson/pinctrl-meson8.c
 create mode 100644 include/dt-bindings/gpio/meson8-gpio.h

diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index b289e8e..7c2988d 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -2,6 +2,9 @@ menuconfig ARCH_MESON
bool Amlogic Meson SoCs if ARCH_MULTI_V7
select GENERIC_IRQ_CHIP
select ARM_GIC
+   select PINCTRL
+   select PINCTRL_MESON
+   select ARCH_REQUIRE_GPIOLIB
 
 if ARCH_MESON
 
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index c6a66de..22b05e1 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -108,6 +108,14 @@ config PINCTRL_FALCON
depends on SOC_FALCON
depends on PINCTRL_LANTIQ
 
+config PINCTRL_MESON
+   bool Amlogic Meson pin controller driver
+   depends on ARCH_MESON
+   select PINMUX
+   select PINCONF
+   select GENERIC_PINCONF
+   select OF_GPIO
+
 config PINCTRL_ROCKCHIP
bool
select PINMUX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 51f52d3..7b22f89 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
 obj-$(CONFIG_PINCTRL_BAYTRAIL) += pinctrl-baytrail.o
 obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
 obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
+obj-$(CONFIG_PINCTRL_MESON)+= meson/
 obj-$(CONFIG_PINCTRL_PALMAS)   += pinctrl-palmas.o
 obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
 obj-$(CONFIG_PINCTRL_SINGLE)   += pinctrl-single.o
diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
new file mode 100644
index 000..03a90b4
--- /dev/null
+++ b/drivers/pinctrl/meson/Makefile
@@ -0,0 +1,2 @@
+obj-y  += pinctrl-meson.o
+obj-y  += pinctrl-meson8.o
diff --git a/drivers/pinctrl/meson/pinctrl-meson.c 
b/drivers/pinctrl/meson/pinctrl-meson.c
new file mode 100644
index 000..a02f50bc
--- /dev/null
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -0,0 +1,824 @@
+/*
+ * Pin controller and GPIO driver for Amlogic Meson SoCs
+ *
+ * Copyright (C) 2014 Beniamino Galvani b.galv...@gmail.com
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/device.h
+#include linux/gpio.h
+#include linux/init.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/pinctrl/pinconf-generic.h
+#include linux/pinctrl/pinconf.h
+#include linux/pinctrl/pinctrl.h
+#include linux/pinctrl/pinmux.h
+#include linux/platform_device.h
+#include linux/seq_file.h
+#include linux/spinlock.h
+
+#include ../core.h
+#include ../pinctrl-utils.h
+#include pinctrl-meson.h
+
+static void meson_domain_set_bit(struct meson_domain *domain,
+void __iomem *addr, unsigned int bit,
+unsigned int value)
+{
+   unsigned long flags;
+   unsigned int data;
+
+   spin_lock_irqsave(domain-lock, flags);
+   data = readl(addr);
+
+   if (value)
+   data |= BIT(bit);
+   else
+   data = ~BIT(bit);
+
+   writel(data, addr);
+   spin_unlock_irqrestore(domain-lock, flags);
+}
+
+static struct meson_domain *meson_pinctrl_get_domain(struct meson_pinctrl *pc,
+int pin)
+{
+   struct meson_domain *domain;
+   int i, j;
+
+   for (i = 0; i  pc-num_domains; i++) {
+   domain = pc-domains[i];
+   for (j = 0; j  domain-data-num_banks; j++) {
+   

Re: [PATCH v4 4/6] ARM: rockchip: add basic smp support for rk3288

[Heiko Stübner]

Am Dienstag, 14. Oktober 2014, 13:24:03 schrieb Doug Anderson:
 Kever,
 
 On Mon, Oct 13, 2014 at 1:12 PM, Kever Yang kever.y...@rock-chips.com 
wrote:
  +   /*
  +* We need to soft reset the cpu when we turn off the cpu power
  domain, +* or else the active processors might be stalled when
  the individual +* processor is powered down.
  +*/
  +   if (read_cpuid_part_number() != ARM_CPU_PART_CORTEX_A9) {
 
 I haven't done a full review of this patch, but it seems unlikely that
 your uses of read_cpuid_part_number() and read_cpuid_part() in this
 patch are correct.  You use both functions and in both cases compare
 the results to ARM_CPU_PART_CORTEX_A9.

I think read_cpuid_part() would be the correct one, as it does

read_cpuid_id()  ARM_CPU_PART_MASK

which in turn should mask the correct parts of the cpuid to match against 
ARM_CPU_PART_CORTEX_A9 [0].



[0] http://lxr.free-electrons.com/source/arch/arm/include/asm/cputype.h#L77
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] pinctrl: meson: add device tree bindings documentation

[Beniamino Galvani]

Add device tree bindings documentation for Amlogic Meson pinmux and
GPIO controller.

Signed-off-by: Beniamino Galvani b.galv...@gmail.com
---
 .../devicetree/bindings/pinctrl/meson,pinctrl.txt  | 79 ++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
new file mode 100644
index 000..6645fa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
@@ -0,0 +1,79 @@
+* Amlogic Meson pinmux controller
+
+Pins are organized in banks; all banks except AO are controlled by the
+same set of registers, while the AO bank uses a dedicated register
+range. The device tree uses sub-nodes to represent set of banks which
+share the same address space.
+
+Required properties for the root node:
+ - compatible: amlogic,meson8-pinctrl
+ - reg: address and size of the common registers controlling gpio irq
+   functionality
+
+Required properties for gpio sub-nodes:
+ - reg: should contain address and size for mux, pull-enable, pull and
+   gpio register sets
+ - reg-names: an array of strings describing the reg entries. Must
+   contain mux, pull and gpio. pull-enable is optional and
+   when it is missing the pull registers are used instead
+ - gpio-controller: identifies the node as a gpio controller
+ - #gpio-cells: must be 2
+
+Valid gpio sub-nodes name are:
+ - banks for the standard banks
+ - ao-bank for the AO bank which belong to the special always-on
+   power domain
+
+Required properties for configuration nodes:
+ - pins: the name of a pin group. The list of all available groups can
+   be found in driver sources.
+ - function: the name of a function to activate for the specified set
+   of groups. The list of all available functions can be found in
+   driver sources.
+
+Example:
+
+   pinctrl: pinctrl@c1109880 {
+   compatible = amlogic,meson8-pinctrl;
+   reg = 0xc1109880 0x10;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   gpio: banks@c11080b0 {
+   reg = 0xc11080b0 0x28,
+ 0xc11080e4 0x18,
+ 0xc1108120 0x18,
+ 0xc1108030 0x30;
+   reg-names = mux, pull-enable, pull, gpio;
+   gpio-controller;
+   #gpio-cells = 2;
+   };
+
+   gpio_ao: ao-bank@c1108030 {
+   reg = 0xc8100014 0x4,
+ 0xc810002c 0x4,
+ 0xc8100024 0x8;
+   reg-names = mux, pull, gpio;
+   gpio-controller;
+   #gpio-cells = 2;
+   };
+
+   nand {
+   nand {
+   pins = nand_io, nand_io_ce0, nand_io_ce1,
+  nand_io_rb0, nand_ale, nand_cle,
+  nand_wen_clk, nand_ren_clk, 
nand_dqs,
+  nand_ce2, nand_ce3;
+   function = nand;
+   };
+   };
+
+   uart_ao_a: uart_ao_a {
+   uart_ao_a {
+   pins = uart_tx_ao_a, uart_rx_ao_a;
+  uart_cts_ao_a, uart_rts_ao_a;
+   function = uart_ao;
+   };
+   };
+   };
-- 
1.9.1

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

Re: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs only with a mount option

[Eric W. Biederman]

Andy Lutomirski l...@amacapital.net writes:

 On Tue, Oct 14, 2014 at 2:13 PM, Eric W. Biederman
 ebied...@xmission.com wrote:
 Seth Forshee seth.fors...@canonical.com writes:

 On Tue, Oct 14, 2014 at 01:01:02PM -0700, Eric W. Biederman wrote:
 Michael j Theall mthe...@us.ibm.com writes:

  Seth Forshee seth.fors...@canonical.com wrote on 10/14/2014 09:25:55 
  AM:
 
  From: Seth Forshee seth.fors...@canonical.com
  To: Miklos Szeredi mik...@szeredi.hu
  Cc: fuse-de...@lists.sourceforge.net, Serge H. Hallyn
  serge.hal...@ubuntu.com, linux-kernel@vger.kernel.org, Seth
  Forshee seth.fors...@canonical.com, Eric W. Biederman
  ebied...@xmission.com, linux-fsde...@vger.kernel.org
  Date: 10/14/2014 09:27 AM
  Subject: [fuse-devel] [PATCH v4 4/5] fuse: Support privileged xattrs
  only with a mount option
 
  Allowing unprivileged users to provide arbitrary xattrs via fuse
  mounts bypasses the normal restrictions on setting xattrs. Such
  mounts should be restricted to reading and writing xattrs in the
  user.* namespace.
 
 
  Can you explain how the normal restrictions on setting xattrs are
  bypassed?

 If the fuse server is not run by root.  Which is a large part of the
 point of fuse.

 So the server could for example return trusted.* xattrs which were not
 set by a privileged user.

  My filesystem still needs security.* and system.*, and it looks like
  xattr_permission already prevents non-privileged users from accessing
  trusted.*

 If the filesystem is mounted with nosuid (typical of a non-privileged
 mount of fuse) then the security.* attributes are ignored.

 That I wasn't aware of. In fact I still haven't found where this
 restriction is implemented.

 My memory may be have been incomplete.  What I was thinking of is
 security/commoncap.c the MNT_NOSUID check in get_file_caps.

 Upon inspection that appears limited to file capabilities, and while
 there are a few other MNT_NOSUID checks under security the feel far from
 complete.

 Sigh.

 This deserves a hard look because if MNT_NOSUID is not sufficient than
 it may be possible for me to insert a usb stick with an extN filesystem
 with the right labels having it auto-mounted nosuid and subvert the
 security of something like selinux.

 It's this code in selinux/hooks.c:

 if ((bprm-file-f_path.mnt-mnt_flags  MNT_NOSUID) ||
 (bprm-unsafe  LSM_UNSAFE_NO_NEW_PRIVS))
 new_tsec-sid = old_tsec-sid;


 One might argue that this should actually generate -EPERM instead of
 ignoring the label, but it should be safe against untrusted media.

Fair enough.  Smack does not replicate any form of that check so smack
appears vulnerable to untrusted media.

I don't think we have any other security modules beyond smack and
selinux that use labels.

 Nonetheless, a userns mount could be done without nosuid (though that
 mount will also be unaccessible outside of that namespace).

  It's difficult though to tell whether a mount is being performed
  on behalf of an unprivileged user since fuse mounts are ususally
  done via a suid root helper. Thus a new mount option,
  privileged_xattrs, is added to indicated that xattrs from other
  namespaces are allowed. This option can only be supplied by
  system-wide root; supplying the option as an unprivileged user
  will cause the mount to fail.
 
  I can't say I'm convinced that this is the right direction to head.

 With respect to defaults we could keep the current default if you
 have the global CAP_SYS_ADMIN privilege when the mount takes place
 and then avoid breaking anything.

 Except that unprivileged mounts are normally done by a suid root helper,
 which is why I've required both global CAP_SYS_ADMIN and a mount option
 to get the current default behavior.

 If nosuid is sufficient that may break existing setups for no good
 reason.

 Shrug.  I won't have much time for a bit but I figured I would highlight
 the potential security hole in existing setups.  So someone with time
 this week can look at that.

 I think I have a better solution.  I'll send it out.

 Serge had also mentioned adding some kind of hook to help LSMs handle
 user namespaces more intelligently.

Eric

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