[PATCH RESEND 06/36] cputime: Convert guest time accounting to nsecs

cputime_t is being obsolete and replaced by nsecs units in order to make internal timestamps less opaque and more granular. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens

[PATCH RESEND 06/36] cputime: Convert guest time accounting to nsecs

cputime_t is being obsolete and replaced by nsecs units in order to make internal timestamps less opaque and more granular. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik

[PATCH RESEND 19/36] posix-timers: Convert internals to use nsecs

Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Also convert posix-cpu-timers to use nsec based internal counters to simplify it. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

[PATCH RESEND 19/36] posix-timers: Convert internals to use nsecs

Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Also convert posix-cpu-timers to use nsec based internal counters to simplify it. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin

[PATCH RESEND 35/36] cputime: Remove unused nsec_to_cputime

It's unused now. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu

[PATCH RESEND 35/36] cputime: Remove unused nsec_to_cputime

It's unused now. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Stanislaw Gruszka Cc: Wanpeng Li Signed-off-by:

[PATCH RESEND 34/36] s390: Remove unused cputime definitions

Since the core doesn't deal with cputime_t anymore, most of these APIs have been left unused. Lets remove these. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens

[PATCH RESEND 31/36] ia64: Remove unused cputime definitions

This nsec based cputime_t implementation isn't used anymore. We can remove it. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky

[PATCH RESEND 34/36] s390: Remove unused cputime definitions

Since the core doesn't deal with cputime_t anymore, most of these APIs have been left unused. Lets remove these. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik van Riel

[PATCH RESEND 31/36] ia64: Remove unused cputime definitions

This nsec based cputime_t implementation isn't used anymore. We can remove it. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Ingo

[PATCH RESEND 36/36] cputime: Remove asm generic headers

cputime_t is now only used by two archs: * powerpc (when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y) * s390 And since the core doesn't use it anymore, we don't need any arch support from the others. So we can remove their stub implementations. A final cleanup would be to provide an

[PATCH RESEND 32/36] s390: Make arch_cpu_idle_time() to return nsecs

This way we don't need to deal with cputime_t details from the core code. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky

[PATCH RESEND 36/36] cputime: Remove asm generic headers

cputime_t is now only used by two archs: * powerpc (when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y) * s390 And since the core doesn't use it anymore, we don't need any arch support from the others. So we can remove their stub implementations. A final cleanup would be to provide an

[PATCH RESEND 32/36] s390: Make arch_cpu_idle_time() to return nsecs

This way we don't need to deal with cputime_t details from the core code. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Ingo Molnar

[PATCH RESEND 22/36] cputime: Push time to account_user_time() in nsecs

This is one more step toward converting cputime accounting to pure nsecs. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky

[PATCH RESEND 22/36] cputime: Push time to account_user_time() in nsecs

This is one more step toward converting cputime accounting to pure nsecs. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Ingo Molnar

[PATCH RESEND 23/36] cputime: Push time to account_steal_time() in nsecs

This is one more step toward converting cputime accounting to pure nsecs. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky

[PATCH RESEND 20/36] itimer: Convert internal cputime_t units to nsec

Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Also convert itimers to use nsec based internal counters. This simplifies it and remove the whole game with error/inc_error which served to deal with cputime_t random granularity. Cc:

[PATCH RESEND 21/36] sched: Remove temporary cputime_t accessors

Now that the whole cputime conversion to nsec units is complete, we can remove the compatibility accessors. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc:

[PATCH RESEND 23/36] cputime: Push time to account_steal_time() in nsecs

This is one more step toward converting cputime accounting to pure nsecs. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Ingo Molnar

[PATCH RESEND 20/36] itimer: Convert internal cputime_t units to nsec

Use the new nsec based cputime accessors as part of the whole cputime conversion from cputime_t to nsecs. Also convert itimers to use nsec based internal counters. This simplifies it and remove the whole game with error/inc_error which served to deal with cputime_t random granularity. Cc:

[PATCH RESEND 21/36] sched: Remove temporary cputime_t accessors

Now that the whole cputime conversion to nsec units is complete, we can remove the compatibility accessors. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik van Riel Cc:

[PATCH RESEND 18/36] posix-timers: Use TICK_NSEC instead of a dynamically ad-hoc calculated version

Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu

[PATCH RESEND 18/36] posix-timers: Use TICK_NSEC instead of a dynamically ad-hoc calculated version

Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Tony Luck Cc: Fenghua Yu Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Stanislaw Gruszka Cc: Wanpeng Li Signed-off-by: Frederic Weisbecker

Re: [PATCH v3 0/5] Serial slave device bus

Hi, On Wed, Jan 25, 2017 at 02:23:38PM -0600, Rob Herring wrote: > Here's V3 of the serdev bus support with all the review feedback so far > incorporated. Greg applied the first 4 patches already. I also found a > problem in the tty_port_wakeup changes and have fixed that. > > I've added serdev

Re: [PATCH v3 0/5] Serial slave device bus

Hi, On Wed, Jan 25, 2017 at 02:23:38PM -0600, Rob Herring wrote: > Here's V3 of the serdev bus support with all the review feedback so far > incorporated. Greg applied the first 4 patches already. I also found a > problem in the tty_port_wakeup changes and have fixed that. > > I've added serdev

Re: squashfs-tools: Add -offset option to skip n bytes at the start of the file

On Sun, Jan 29, 2017 at 2:00 PM, Ritesh Raj Sarraf wrote: > On Sun, 2017-01-29 at 03:33 -0800, probonopd wrote: >> Yes, I am not happy about that. >> You could either push your change to the squashfs folks >> Sent a PR half a year ago but no reaction:

Re: squashfs-tools: Add -offset option to skip n bytes at the start of the file

On Sun, Jan 29, 2017 at 2:00 PM, Ritesh Raj Sarraf wrote: > On Sun, 2017-01-29 at 03:33 -0800, probonopd wrote: >> Yes, I am not happy about that. >> You could either push your change to the squashfs folks >> Sent a PR half a year ago but no reaction: plougher/squashfs-tools#13 - is >> something

Re: [PATCH] perf tools: Create for_each_event{_system, _file} macros for tracepoints iteration

On 01/30/2017 09:38 PM, Jiri Olsa wrote: On Mon, Jan 30, 2017 at 07:32:03PM +0900, Taeung Song wrote: SNIP looks almost the same as for_each_event_system macro, what's the difference other than 'ftrace' check? Little thing. In parse-events.c for_each_event macro contains tp_event_has_id()

Re: [PATCH] perf tools: Create for_each_event{_system, _file} macros for tracepoints iteration

On 01/30/2017 09:38 PM, Jiri Olsa wrote: On Mon, Jan 30, 2017 at 07:32:03PM +0900, Taeung Song wrote: SNIP looks almost the same as for_each_event_system macro, what's the difference other than 'ftrace' check? Little thing. In parse-events.c for_each_event macro contains tp_event_has_id()

Re: [PATCH 60/60] staging: lustre: libcfs: fix minimum size check for libcfs ioctl

> It looks like what happened is there were two patches applied out of > sync. Let's add a fixes tag and CC the original author. So the only problem here is the commit message. I will update it then. > Fixes: ed2f549dc0f6 ("staging: lustre: libcfs: test if userland data is to > small") > >

Re: [PATCH 60/60] staging: lustre: libcfs: fix minimum size check for libcfs ioctl

> It looks like what happened is there were two patches applied out of > sync. Let's add a fixes tag and CC the original author. So the only problem here is the commit message. I will update it then. > Fixes: ed2f549dc0f6 ("staging: lustre: libcfs: test if userland data is to > small") > >

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

On 01/30/2017 04:31 PM, Russell King - ARM Linux wrote: On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote: +++ b/drivers/staging/media/imx/imx-mipi-csi2.c ... +#define DEVICE_NAME "imx6-mipi-csi2" Why is the device/driver named imx6-mipi-csi2, but the module named

Re: [PATCH v3 21/24] media: imx: Add MIPI CSI-2 Receiver subdev driver

On 01/30/2017 04:31 PM, Russell King - ARM Linux wrote: On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote: +++ b/drivers/staging/media/imx/imx-mipi-csi2.c ... +#define DEVICE_NAME "imx6-mipi-csi2" Why is the device/driver named imx6-mipi-csi2, but the module named

Re: timerfd: use-after-free in timerfd_remove_cancel

On Mon, Jan 30, 2017 at 07:41:59PM +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers use-after-free in timerfd_remove_cancel: > https://gist.githubusercontent.com/dvyukov/202576d437c84ffbbe52e9ccd77e1b44/raw/5562bff8626a73627157331ea2b837f59080ac84/gistfile1.txt > > BUG:

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/30/2017 05:06 PM, Russell King - ARM Linux wrote: On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote: Trying this driver with an imx219 camera (which works with Philipp's driver) results in not much happening... no /dev/media* node for it, no subdevs, no nothing.

Re: timerfd: use-after-free in timerfd_remove_cancel

On Mon, Jan 30, 2017 at 07:41:59PM +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers use-after-free in timerfd_remove_cancel: > https://gist.githubusercontent.com/dvyukov/202576d437c84ffbbe52e9ccd77e1b44/raw/5562bff8626a73627157331ea2b837f59080ac84/gistfile1.txt > > BUG:

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/30/2017 05:06 PM, Russell King - ARM Linux wrote: On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote: Trying this driver with an imx219 camera (which works with Philipp's driver) results in not much happening... no /dev/media* node for it, no subdevs, no nothing.

[PATCH v4 2nd 3/4] ramoops: support multiple pmsg instances

This enables ramoops to deal with multiple pmsg instances. A User can configure the size of each buffers by its module parameter as follows. pmsg_size=0x1000,0x2000,... Then, the ramoops allocates multiple buffers and tells the number of buffers to pstore to create multiple /dev/pmsg[ID].

[PATCH v4 2nd 0/4] pstore: ramoops: support multiple pmsg instances

The following series implements multiple pmsg. This feature allows userspace program to control individual content aging or priority. If a pstore backend module(e.g. ramoops) requires the multiple pmsg instances when registering itself to pstore, multiple /dev/pmsg[ID] are created. Writes to each

[PATCH v4 2nd 3/4] ramoops: support multiple pmsg instances

This enables ramoops to deal with multiple pmsg instances. A User can configure the size of each buffers by its module parameter as follows. pmsg_size=0x1000,0x2000,... Then, the ramoops allocates multiple buffers and tells the number of buffers to pstore to create multiple /dev/pmsg[ID].

[PATCH v4 2nd 0/4] pstore: ramoops: support multiple pmsg instances

The following series implements multiple pmsg. This feature allows userspace program to control individual content aging or priority. If a pstore backend module(e.g. ramoops) requires the multiple pmsg instances when registering itself to pstore, multiple /dev/pmsg[ID] are created. Writes to each

[PATCH v4 2nd 4/4] selftests/pstore: add testcases for multiple pmsg instances

From: Hiraku Toyooka To test multiple pmsg, we should check that /dev/pmsg[N] (N > 0) is available. After reboot, we should check that pmsg-[backend]-[N] which keeps content is detected even if pmsg-[backend]-[N-M] (0 < M <= N) doesn't exist due to lack of

[PATCH v4 2nd 2/4] pstore: support multiple pmsg instances

From: Hiraku Toyooka This enables pmsg to deal with multiple instances. One possible use is content priority control on limited persistent store space. By using different buffers, we can prevent important messages from being overwritten by less important messages.

[PATCH v4 2nd 1/4] ramoops: Add __ramoops_init_prz() as generic function

This commit adds generic function __ramoops_init_prz() to reduce redundancy between ramoops_init_prz() and ramoops_init_przs(). Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Hiraku Toyooka Cc: Anton Vorontsov

[PATCH v4 2nd 4/4] selftests/pstore: add testcases for multiple pmsg instances

From: Hiraku Toyooka To test multiple pmsg, we should check that /dev/pmsg[N] (N > 0) is available. After reboot, we should check that pmsg-[backend]-[N] which keeps content is detected even if pmsg-[backend]-[N-M] (0 < M <= N) doesn't exist due to lack of contents. So this adds the following

[PATCH v4 2nd 2/4] pstore: support multiple pmsg instances

From: Hiraku Toyooka This enables pmsg to deal with multiple instances. One possible use is content priority control on limited persistent store space. By using different buffers, we can prevent important messages from being overwritten by less important messages. When pstore backend module

[PATCH v4 2nd 1/4] ramoops: Add __ramoops_init_prz() as generic function

This commit adds generic function __ramoops_init_prz() to reduce redundancy between ramoops_init_prz() and ramoops_init_przs(). Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Hiraku Toyooka Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Mark Salyzyn Cc: Seiji Aguchi Cc: Shuah Khan

[PATCH] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

pmc_reprogram_counter() always sets a sample period based on the value of pmc->counter. However, hsw_hw_config() rejects sample periods less than 2^31 - 1. So for example, a KVM guest doing perf stat -e r2005101c4 sleep 0 will count some conditional branch events, deschedule the task, reschedule

[PATCH] KVM: x86: never specify a sample period for virtualized in_tx_cp counters

pmc_reprogram_counter() always sets a sample period based on the value of pmc->counter. However, hsw_hw_config() rejects sample periods less than 2^31 - 1. So for example, a KVM guest doing perf stat -e r2005101c4 sleep 0 will count some conditional branch events, deschedule the task, reschedule

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

On 01/30/2017 05:36 PM, Anshuman Khandual wrote: >> Let's say we had a CDM node with 100x more RAM than the rest of the >> system and it was just as fast as the rest of the RAM. Would we still >> want it isolated like this? Or would we want a different policy? > > But then the other argument

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

On 01/30/2017 05:36 PM, Anshuman Khandual wrote: >> Let's say we had a CDM node with 100x more RAM than the rest of the >> system and it was just as fast as the rest of the RAM. Would we still >> want it isolated like this? Or would we want a different policy? > > But then the other argument

Re: [PATCH 6/6] staging: bcm2835-v4l2: Apply spelling fixes from checkpatch.

On Mon, 2017-01-30 at 12:05 -0800, Eric Anholt wrote: > Joe Perches writes: > > > On Fri, 2017-01-27 at 13:55 -0800, Eric Anholt wrote: > > > Generated with checkpatch.pl --fix-inplace and git add -p out of the > > > results. > > > > Maybe another. > > > > > diff --git

Re: [PATCH 6/6] staging: bcm2835-v4l2: Apply spelling fixes from checkpatch.

On Mon, 2017-01-30 at 12:05 -0800, Eric Anholt wrote: > Joe Perches writes: > > > On Fri, 2017-01-27 at 13:55 -0800, Eric Anholt wrote: > > > Generated with checkpatch.pl --fix-inplace and git add -p out of the > > > results. > > > > Maybe another. > > > > > diff --git

Re: [RFC V2 02/12] mm: Isolate HugeTLB allocations away from CDM nodes

On 01/30/2017 05:03 PM, Anshuman Khandual wrote: > On 01/30/2017 10:49 PM, Dave Hansen wrote: >> On 01/29/2017 07:35 PM, Anshuman Khandual wrote: >>> HugeTLB allocation/release/accounting currently spans across all the nodes >>> under N_MEMORY node mask. Coherent memory nodes should not be part of

Re: [RFC V2 02/12] mm: Isolate HugeTLB allocations away from CDM nodes

On 01/30/2017 05:03 PM, Anshuman Khandual wrote: > On 01/30/2017 10:49 PM, Dave Hansen wrote: >> On 01/29/2017 07:35 PM, Anshuman Khandual wrote: >>> HugeTLB allocation/release/accounting currently spans across all the nodes >>> under N_MEMORY node mask. Coherent memory nodes should not be part of

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

On 01/30/2017 11:04 PM, Dave Hansen wrote: > On 01/29/2017 07:35 PM, Anshuman Khandual wrote: >> * CDM node's zones are not part of any other node's FALLBACK zonelist >> * CDM node's FALLBACK list contains it's own memory zones followed by >> all system RAM zones in regular order as before >> *

Re: [RFC V2 03/12] mm: Change generic FALLBACK zonelist creation process

On 01/30/2017 11:04 PM, Dave Hansen wrote: > On 01/29/2017 07:35 PM, Anshuman Khandual wrote: >> * CDM node's zones are not part of any other node's FALLBACK zonelist >> * CDM node's FALLBACK list contains it's own memory zones followed by >> all system RAM zones in regular order as before >> *

Re: [PATCH v3 4/4] arm64: dts: msm8996: Add SLPI SMP2P dt node.

On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote: > Add smp2p support to communicate with slpi processor. > > Signed-off-by: Avaneesh Kumar Dwivedi Reviewed-by: Bjorn Andersson Regards, Bjorn

Re: [PATCH v3 4/4] arm64: dts: msm8996: Add SLPI SMP2P dt node.

On Mon 30 Jan 07:03 PST 2017, Avaneesh Kumar Dwivedi wrote: > Add smp2p support to communicate with slpi processor. > > Signed-off-by: Avaneesh Kumar Dwivedi Reviewed-by: Bjorn Andersson Regards, Bjorn

g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

On Mon, 30 Jan 2017, Ondrej Zary wrote: > > Also tested two CD-ROM drives and they didn't work (machine hangs). They > didn't work before and looks like they never worked with PDMA. > > The fundamental problem of PDMA is that it either transfers all required > data or it breaks horribly.

g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

On Mon, 30 Jan 2017, Ondrej Zary wrote: > > Also tested two CD-ROM drives and they didn't work (machine hangs). They > didn't work before and looks like they never worked with PDMA. > > The fundamental problem of PDMA is that it either transfers all required > data or it breaks horribly.

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/cadence/macb.h between commit: dc97a89e726c ("net: macb: Fix 64 bit addressing support for GEM") from the net tree and commit: c2594d804d5c ("macb: Common code to enable ptp support for

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/cadence/macb.h between commit: dc97a89e726c ("net: macb: Fix 64 bit addressing support for GEM") from the net tree and commit: c2594d804d5c ("macb: Common code to enable ptp support for

[PATCH 3/3] remoteproc: qcom: Use common SMD edge handler

Call the common SMD edge handler to instantiate subdevices to bring associated SMD edges up and down as the remoteproc is started and stopped. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/Kconfig | 2 ++ drivers/remoteproc/qcom_adsp_pil.c | 6 ++

[PATCH 1/3] remoteproc: qcom-common: Extract non-mdt related helper

In preparation for moving the mdt loader out of remoteproc let's move the somewhat unrelated resource table dummy helper to a Qualcomm "common" file. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/Kconfig | 6 + drivers/remoteproc/Makefile

[PATCH 3/3] remoteproc: qcom: Use common SMD edge handler

Call the common SMD edge handler to instantiate subdevices to bring associated SMD edges up and down as the remoteproc is started and stopped. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/Kconfig | 2 ++ drivers/remoteproc/qcom_adsp_pil.c | 6 ++

[PATCH 1/3] remoteproc: qcom-common: Extract non-mdt related helper

In preparation for moving the mdt loader out of remoteproc let's move the somewhat unrelated resource table dummy helper to a Qualcomm "common" file. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/Kconfig | 6 + drivers/remoteproc/Makefile | 1 +

[PATCH 2/3] remoteproc: qcom: wcnss: Make SMD handling common

Move the SMD edge handling to the Qualcomm common file to make it reusable for other Qualcomm remoteproc drivers. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/qcom_common.c | 50 drivers/remoteproc/qcom_common.h | 15

[PATCH 2/3] remoteproc: qcom: wcnss: Make SMD handling common

Move the SMD edge handling to the Qualcomm common file to make it reusable for other Qualcomm remoteproc drivers. Signed-off-by: Bjorn Andersson --- drivers/remoteproc/qcom_common.c | 50 drivers/remoteproc/qcom_common.h | 15 ++--

Re: [PATCH RFC] powerpc/32: fix handling of stack protector with recent GCC

On Mon, Jan 30, 2017 at 04:12:53PM -0800, Christian Kujau wrote: > On Mon, 16 Jan 2017, Christophe Leroy wrote: > > Since 2005, powerpc GCC doesn't manage anymore __stack_chk_guard as > > a global variable but as some value located at -0x7008(r2) > > Is this still an "RFC" or is there a chance

Re: [PATCH RFC] powerpc/32: fix handling of stack protector with recent GCC

On Mon, Jan 30, 2017 at 04:12:53PM -0800, Christian Kujau wrote: > On Mon, 16 Jan 2017, Christophe Leroy wrote: > > Since 2005, powerpc GCC doesn't manage anymore __stack_chk_guard as > > a global variable but as some value located at -0x7008(r2) > > Is this still an "RFC" or is there a chance

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/mellanox/mlx5/core/en_tc.c between commit: 3e621b19b0bb ("net/mlx5e: Support TC encapsulation offloads with upper devices") from the net tree and commits: 75c33da82736 ("net/mlx5e: TC ipv4

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/mellanox/mlx5/core/en_tc.c between commit: 3e621b19b0bb ("net/mlx5e: Support TC encapsulation offloads with upper devices") from the net tree and commits: 75c33da82736 ("net/mlx5e: TC ipv4

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/30/2017 04:45 PM, Russell King - ARM Linux wrote: Hi, Trying this driver with an imx219 camera (which works with Philipp's driver) results in not much happening... no /dev/media* node for it, no subdevs, no nothing. No clues as to what's missing either. Only messages from imx-media

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/30/2017 04:45 PM, Russell King - ARM Linux wrote: Hi, Trying this driver with an imx219 camera (which works with Philipp's driver) results in not much happening... no /dev/media* node for it, no subdevs, no nothing. No clues as to what's missing either. Only messages from imx-media

linux-next: manual merge of the pm tree with the mips tree

Hi Rafael, Today's linux-next merge of the pm tree got a conflict in: arch/mips/configs/lemote2f_defconfig between commit: b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change") from the mips tree and commit: e7f73a76e07a ("cpufreq: Remove

linux-next: manual merge of the pm tree with the mips tree

Hi Rafael, Today's linux-next merge of the pm tree got a conflict in: arch/mips/configs/lemote2f_defconfig between commit: b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change") from the mips tree and commit: e7f73a76e07a ("cpufreq: Remove

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote: > Trying this driver with an imx219 camera (which works with Philipp's > driver) results in not much happening... no /dev/media* node for it, > no subdevs, no nothing. No clues as to what's missing either. Only > messages

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote: > Trying this driver with an imx219 camera (which works with Philipp's > driver) results in not much happening... no /dev/media* node for it, > no subdevs, no nothing. No clues as to what's missing either. Only > messages

Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()

On Mon, Jan 30, 2017 at 04:41:48PM +0100, Boris Brezillon wrote: > Rename devm_get_gpiod_from_child() into > devm_fwnode_get_gpiod_from_child() to reflect the fact that this > function is operating on a fwnode object. I believe this is completely pointless rename. Are you planning on adding

Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()

On Mon, Jan 30, 2017 at 04:41:48PM +0100, Boris Brezillon wrote: > Rename devm_get_gpiod_from_child() into > devm_fwnode_get_gpiod_from_child() to reflect the fact that this > function is operating on a fwnode object. I believe this is completely pointless rename. Are you planning on adding

[PATCH -next] platform: x86: fix silead_dmi build error and depends

rement anyway. Maybe it can be removed... --- linux-next-20170130.orig/drivers/platform/x86/Kconfig +++ linux-next-20170130/drivers/platform/x86/Kconfig @@ -1079,7 +1079,7 @@ config INTEL_TURBO_MAX_3 config SILEAD_DMI bool "Tablets with Silead touchscreens" - depends on ACPI

linux-next: build failure after merge of the v4l-dvb tree

x51: port to rc-core") I have used the v4l-dvb tree from next-20170130 for today. -- Cheers, Stephen Rothwell

[PATCH -next] platform: x86: fix silead_dmi build error and depends

Dunlap Cc: Hans de Goede --- drivers/platform/x86/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I don't see why the "depends on INPUT" was there at all, but I modified its requirement anyway. Maybe it can be removed... --- linux-next-20170130.orig/drivers/platform/x

linux-next: build failure after merge of the v4l-dvb tree

x51: port to rc-core") I have used the v4l-dvb tree from next-20170130 for today. -- Cheers, Stephen Rothwell

Re: [RFC V2 02/12] mm: Isolate HugeTLB allocations away from CDM nodes

On 01/30/2017 10:49 PM, Dave Hansen wrote: > On 01/29/2017 07:35 PM, Anshuman Khandual wrote: >> HugeTLB allocation/release/accounting currently spans across all the nodes >> under N_MEMORY node mask. Coherent memory nodes should not be part of these >> allocations. So use system_ram() call to

[PATCH] MAINTAINERS: Add missing rpmsg include path

Signed-off-by: Bjorn Andersson --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index eb5a6fc8d6f9..c8f743ef3cc8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10514,6 +10514,7 @@ S: Maintained F: drivers/rpmsg/

Re: [RFC V2 02/12] mm: Isolate HugeTLB allocations away from CDM nodes

On 01/30/2017 10:49 PM, Dave Hansen wrote: > On 01/29/2017 07:35 PM, Anshuman Khandual wrote: >> HugeTLB allocation/release/accounting currently spans across all the nodes >> under N_MEMORY node mask. Coherent memory nodes should not be part of these >> allocations. So use system_ram() call to

[PATCH] MAINTAINERS: Add missing rpmsg include path

Signed-off-by: Bjorn Andersson --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index eb5a6fc8d6f9..c8f743ef3cc8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10514,6 +10514,7 @@ S: Maintained F: drivers/rpmsg/ F:

Re: [PATCH v2] clk: add more managed APIs

On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote: > On Mon, Jan 30, 2017 at 10:55:51AM -0800, Stephen Boyd wrote: > > On 01/29, Dmitry Torokhov wrote: > > > When converting a driver to managed resources it is desirable to be able > > > to > > > manage all resources in the same

Re: [PATCH v2] clk: add more managed APIs

On Mon, Jan 30, 2017 at 11:22:14AM -0800, Guenter Roeck wrote: > On Mon, Jan 30, 2017 at 10:55:51AM -0800, Stephen Boyd wrote: > > On 01/29, Dmitry Torokhov wrote: > > > When converting a driver to managed resources it is desirable to be able > > > to > > > manage all resources in the same

Re: [PATCH 13/60] staging: lustre: obdclass: health_check to report unhealthy upon LBUG

> Wat? > > I'm sorry but this patch makes no sense at all. > > On Sat, Jan 28, 2017 at 07:04:41PM -0500, James Simmons wrote: > > From: Bruno Faccini > > > > When a LBUG has occurred, without panic_on_lbug being set, > > health_check sysfs file must return an

Re: [PATCH 13/60] staging: lustre: obdclass: health_check to report unhealthy upon LBUG

> Wat? > > I'm sorry but this patch makes no sense at all. > > On Sat, Jan 28, 2017 at 07:04:41PM -0500, James Simmons wrote: > > From: Bruno Faccini > > > > When a LBUG has occurred, without panic_on_lbug being set, > > health_check sysfs file must return an unhealthy state. > > Why? Its a

Re: [PATCHv3 perf/core 1/6] tools lib bpf: Add BPF program pinning APIs.

Em Mon, Jan 30, 2017 at 01:16:18PM -0800, Joe Stringer escreveu: > On 30 January 2017 at 12:28, Arnaldo Carvalho de Melo wrote: > > --- > > Thus, a return value of size or more means that the output was > > truncated. > > --- > Good spotting, I looked over the committed

Re: [PATCHv3 perf/core 1/6] tools lib bpf: Add BPF program pinning APIs.

Em Mon, Jan 30, 2017 at 01:16:18PM -0800, Joe Stringer escreveu: > On 30 January 2017 at 12:28, Arnaldo Carvalho de Melo wrote: > > --- > > Thus, a return value of size or more means that the output was > > truncated. > > --- > Good spotting, I looked over the committed versions and tested

[PATCH] rpmsg: qcom: smd: Return positively when not enabled

Remoteproc treats the error codes returned from the stubbed SMD API as errors, but the fact that SMD is not enabled should not affect remoteproc's ability to start the remote processors. Signed-off-by: Bjorn Andersson --- include/linux/rpmsg/qcom_smd.h | 6 ++ 1

[PATCH] rpmsg: qcom: smd: Return positively when not enabled

Remoteproc treats the error codes returned from the stubbed SMD API as errors, but the fact that SMD is not enabled should not affect remoteproc's ability to start the remote processors. Signed-off-by: Bjorn Andersson --- include/linux/rpmsg/qcom_smd.h | 6 ++ 1 file changed, 2

[PATCH v3] clk: add more managed APIs

When converting a driver to managed resources it is desirable to be able to manage all resources in the same fashion. This change allows managing clock prepared and enabled state in the same way we manage many other resources. This adds the following managed APIs: -

[PATCH v3] clk: add more managed APIs

When converting a driver to managed resources it is desirable to be able to manage all resources in the same fashion. This change allows managing clock prepared and enabled state in the same way we manage many other resources. This adds the following managed APIs: -

<    1   2   3   4   5   6   7   8   9   10   >