Re: [PATCH v3 20/25] ARM: owl: Implement CPU enable-method for S500

Am 01.03.2017 um 11:40 schrieb Andreas Färber: > Am 01.03.2017 um 08:19 schrieb kbuild test robot: >> Hi Andreas, >> >> [auto build test ERROR on next-20170228] >> [also build test ERROR on v4.10] >> [cannot apply to robh/for-next linus/master linux/master v4.9-rc8 v4.9-rc7 >> v4.9-rc6] >> [if

Re: [PATCH v3 20/25] ARM: owl: Implement CPU enable-method for S500

Am 01.03.2017 um 11:40 schrieb Andreas Färber: > Am 01.03.2017 um 08:19 schrieb kbuild test robot: >> Hi Andreas, >> >> [auto build test ERROR on next-20170228] >> [also build test ERROR on v4.10] >> [cannot apply to robh/for-next linus/master linux/master v4.9-rc8 v4.9-rc7 >> v4.9-rc6] >> [if

Re: [PATCH v4 3/3] perf: powerpc: choose local entry point with kretprobes

On Thu, 2 Mar 2017 23:25:07 +0530 "Naveen N. Rao" wrote: > perf now uses an offset from _text/_stext for kretprobes if the kernel > supports it, rather than the actual function name. As such, let's choose > the LEP for powerpc ABIv2 so as to ensure the probe

[PATCHv5] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace operation to specify if registers need to saved/restored by the ftrace handler. This is needed by kgraft and possibly other ftrace-based tools, and the ARM architecture is currently lacking this feature. It would also be the

Re: [PATCH v4 3/3] perf: powerpc: choose local entry point with kretprobes

On Thu, 2 Mar 2017 23:25:07 +0530 "Naveen N. Rao" wrote: > perf now uses an offset from _text/_stext for kretprobes if the kernel > supports it, rather than the actual function name. As such, let's choose > the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only > if the kernel

[PATCHv5] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace operation to specify if registers need to saved/restored by the ftrace handler. This is needed by kgraft and possibly other ftrace-based tools, and the ARM architecture is currently lacking this feature. It would also be the

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On 03/03/2017 03:06 PM, Russell King - ARM Linux wrote: On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote: v4l2_pipeline_inherit_controls() will add the v4l2 controls from all subdev entities in a

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On 03/03/2017 03:06 PM, Russell King - ARM Linux wrote: On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote: v4l2_pipeline_inherit_controls() will add the v4l2 controls from all subdev entities in a

Re: [PATCH 0/3] ipc subsystem refcounter conversions

On Mon, 20 Feb 2017 13:29:46 +0200 Elena Reshetova wrote: > Now when new refcount_t type and API are finally merged > (see include/linux/refcount.h), the following > patches convert various refcounters in the ipc susystem from atomic_t > to refcount_t. By doing this

Re: [PATCH 0/3] ipc subsystem refcounter conversions

On Mon, 20 Feb 2017 13:29:46 +0200 Elena Reshetova wrote: > Now when new refcount_t type and API are finally merged > (see include/linux/refcount.h), the following > patches convert various refcounters in the ipc susystem from atomic_t > to refcount_t. By doing this we prevent intentional or

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

On Fri, 2017-03-03 at 17:36 -0500, J. Bruce Fields wrote: > The patch ordering is a little annoying as I'd like to be able to be > able to verify the implementation at the same time these new interfaces > are added, but, I don't know, I don't have a better idea. > Fair point. My thinking was

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

On Fri, 2017-03-03 at 17:36 -0500, J. Bruce Fields wrote: > The patch ordering is a little annoying as I'd like to be able to be > able to verify the implementation at the same time these new interfaces > are added, but, I don't know, I don't have a better idea. > Fair point. My thinking was

Re: Hundreds of null PATH records for *init_module syscall audit logs

On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs wrote: > On 2017-02-28 23:15, Steve Grubb wrote: >> On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote: >> > Sorry, I forgot to include Cc: in this cover letter for context to the 4 >> > alt patches. >> > >> >

Re: [RFC PATCH v1 29/30] fs: track whether the i_version has been queried with an i_state flag

On Wed, Dec 21 2016, Jeff Layton wrote: > @@ -2072,7 +2093,12 @@ inode_cmp_iversion(const struct inode *inode, const > u64 old) > static inline bool > inode_iversion_need_inc(struct inode *inode) > { > - return true; > + bool ret; > + > + spin_lock(>i_lock); > + ret =

Re: [RFC PATCH v1 29/30] fs: track whether the i_version has been queried with an i_state flag

On Wed, Dec 21 2016, Jeff Layton wrote: > @@ -2072,7 +2093,12 @@ inode_cmp_iversion(const struct inode *inode, const > u64 old) > static inline bool > inode_iversion_need_inc(struct inode *inode) > { > - return true; > + bool ret; > + > + spin_lock(>i_lock); > + ret =

Re: Hundreds of null PATH records for *init_module syscall audit logs

On Fri, Mar 3, 2017 at 4:14 PM, Richard Guy Briggs wrote: > On 2017-02-28 23:15, Steve Grubb wrote: >> On Tuesday, February 28, 2017 10:37:04 PM EST Richard Guy Briggs wrote: >> > Sorry, I forgot to include Cc: in this cover letter for context to the 4 >> > alt patches. >> > >> > On 2017-02-28

Re: Hundreds of null PATH records for *init_module syscall audit logs

On Tue, Feb 28, 2017 at 10:37 PM, Richard Guy Briggs wrote: > Sorry, I forgot to include Cc: in this cover letter for context to the 4 > alt patches. > > On 2017-02-28 22:15, Richard Guy Briggs wrote: >> The background to this is: >>

Re: Hundreds of null PATH records for *init_module syscall audit logs

On Tue, Feb 28, 2017 at 10:37 PM, Richard Guy Briggs wrote: > Sorry, I forgot to include Cc: in this cover letter for context to the 4 > alt patches. > > On 2017-02-28 22:15, Richard Guy Briggs wrote: >> The background to this is: >> https://github.com/linux-audit/audit-kernel/issues/8 >>

Re: [PATCH 4/5] clk: sunxi-ng: Add driver for A83T CCU

On 03/03, Maxime Ripard wrote: > On Wed, Mar 01, 2017 at 11:17:05AM -0800, Stephen Boyd wrote: > > > Can someone explain what the issue is? Could something like > > clk_get_phase() + clk_get_rate() tell us if we're in one mode > > vs. the other? > > So we have two modes of operation for that

Re: [PATCH 4/5] clk: sunxi-ng: Add driver for A83T CCU

On 03/03, Maxime Ripard wrote: > On Wed, Mar 01, 2017 at 11:17:05AM -0800, Stephen Boyd wrote: > > > Can someone explain what the issue is? Could something like > > clk_get_phase() + clk_get_rate() tell us if we're in one mode > > vs. the other? > > So we have two modes of operation for that

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Saturday, March 04, 2017 01:03:17 AM Rafael J. Wysocki wrote: > On Thursday, March 02, 2017 02:03:22 PM Viresh Kumar wrote: > > The same code is present both within and outside the loop and it doesn't > > look like it provides any additional benefit. > > Well, not quite. This is on purpose. >

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Saturday, March 04, 2017 01:03:17 AM Rafael J. Wysocki wrote: > On Thursday, March 02, 2017 02:03:22 PM Viresh Kumar wrote: > > The same code is present both within and outside the loop and it doesn't > > look like it provides any additional benefit. > > Well, not quite. This is on purpose. >

Re: [PATCH 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer

Hi simran, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.10 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/simran-singhal/staging-nvec

Re: [PATCH v4 1/3] perf: probe: factor out the ftrace README scanning

On Thu, 2 Mar 2017 23:25:05 +0530 "Naveen N. Rao" wrote: > Simplify and separate out the ftrace README scanning logic into a > separate helper. This is used subsequently to scan for all patterns of > interest and to cache the result. > > Since we are only

Re: [PATCH v4 1/3] perf: probe: factor out the ftrace README scanning

On Thu, 2 Mar 2017 23:25:05 +0530 "Naveen N. Rao" wrote: > Simplify and separate out the ftrace README scanning logic into a > separate helper. This is used subsequently to scan for all patterns of > interest and to cache the result. > > Since we are only interested in availability of probe

Re: [PATCH 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer

Hi simran, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.10 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/simran-singhal/staging-nvec

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Thursday, March 02, 2017 02:03:22 PM Viresh Kumar wrote: > The same code is present both within and outside the loop and it doesn't > look like it provides any additional benefit. Well, not quite. This is on purpose. Note the "if (j == smp_processor_id())" condition within the loop and think

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

On Thursday, March 02, 2017 02:03:22 PM Viresh Kumar wrote: > The same code is present both within and outside the loop and it doesn't > look like it provides any additional benefit. Well, not quite. This is on purpose. Note the "if (j == smp_processor_id())" condition within the loop and think

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

Hi Jason, On Fri, Mar 03, 2017 at 04:02:56PM -0800, Jason Uy wrote: > HI James, > > Maybe instead of that, we should do this instead > > If ((IS_ERR(d->clk) && PTR_ERR(d->clk)) || !old) IS_ERR(x) matches a range of non-zero negative values, so it implies PTR_ERR(x) already, so it doesn't

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

Hi Jason, On Fri, Mar 03, 2017 at 04:02:56PM -0800, Jason Uy wrote: > HI James, > > Maybe instead of that, we should do this instead > > If ((IS_ERR(d->clk) && PTR_ERR(d->clk)) || !old) IS_ERR(x) matches a range of non-zero negative values, so it implies PTR_ERR(x) already, so it doesn't

Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps

On Thu, 2 Mar 2017 17:30:54 +0100 Michal Hocko wrote: > > It's not that I think you're wrong: it *is* an implementation detail. > > But we take a bit of incoherency from batching all over the place, so > > it's a little odd to take a stand over this particular instance of it >

Re: [PATCH V5 6/6] proc: show MADV_FREE pages info in smaps

On Thu, 2 Mar 2017 17:30:54 +0100 Michal Hocko wrote: > > It's not that I think you're wrong: it *is* an implementation detail. > > But we take a bit of incoherency from batching all over the place, so > > it's a little odd to take a stand over this particular instance of it > > - whether

[PATCH net] rxrpc: Call state should be read with READ_ONCE() under some circumstances

The call state may be changed at any time by the data-ready routine in response to received packets, so if the call state is to be read and acted upon several times in a function, READ_ONCE() must be used unless the call state lock is held. Signed-off-by: David Howells ---

[PATCH net] rxrpc: Call state should be read with READ_ONCE() under some circumstances

The call state may be changed at any time by the data-ready routine in response to received packets, so if the call state is to be read and acted upon several times in a function, READ_ONCE() must be used unless the call state lock is held. Signed-off-by: David Howells --- net/rxrpc/input.c

RE: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

HI James, Maybe instead of that, we should do this instead If ((IS_ERR(d->clk) && PTR_ERR(d->clk)) || !old) Note that this is what is done in the probe function of the dw driver. Regards, Jason -Original Message- From: James Hogan [mailto:james.ho...@imgtec.com] Sent: March-03-17 3:07

Re: [PATCH 0/2] fix the traced mt-exec deadlock

ebied...@xmission.com (Eric W. Biederman) writes: > The big lesson for me, and what was not obvious from your change > description is that we are changing the user space visible semantics > of exec+ptrace and that cred_guard_mutex is not at all the problem (as > we always take cred_guard_mutex in

RE: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

HI James, Maybe instead of that, we should do this instead If ((IS_ERR(d->clk) && PTR_ERR(d->clk)) || !old) Note that this is what is done in the probe function of the dw driver. Regards, Jason -Original Message- From: James Hogan [mailto:james.ho...@imgtec.com] Sent: March-03-17 3:07

Re: [PATCH 0/2] fix the traced mt-exec deadlock

ebied...@xmission.com (Eric W. Biederman) writes: > The big lesson for me, and what was not obvious from your change > description is that we are changing the user space visible semantics > of exec+ptrace and that cred_guard_mutex is not at all the problem (as > we always take cred_guard_mutex in

Re: [RFC PATCH v1 30/30] fs: convert i_version counter over to an atomic64_t

On Wed, Dec 21 2016, Jeff Layton wrote: > > +/* > + * We borrow the top bit in the i_version to use as a flag to tell us whether > + * it has been queried since we last bumped it. If it has, then we must bump > + * it and set the flag. Note that this means that we have to handle wrapping > + *

Re: [RFC PATCH v1 30/30] fs: convert i_version counter over to an atomic64_t

On Wed, Dec 21 2016, Jeff Layton wrote: > > +/* > + * We borrow the top bit in the i_version to use as a flag to tell us whether > + * it has been queried since we last bumped it. If it has, then we must bump > + * it and set the flag. Note that this means that we have to handle wrapping > + *

Re: [PATCH v3 4/5] clk: hi6220: add debug APB clock

On 03/03, Leo Yan wrote: > The debug APB clock is absent in hi6220 driver, so this patch is to add > support for it. > > Signed-off-by: Leo Yan > --- Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux

Re: [PATCH v3 4/5] clk: hi6220: add debug APB clock

On 03/03, Leo Yan wrote: > The debug APB clock is absent in hi6220 driver, so this patch is to add > support for it. > > Signed-off-by: Leo Yan > --- Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

On Wed, Dec 21 2016, Jeff Layton wrote: > We already have inode_inc_iversion. Add inode_set_iversion, > inode_get_iversion, inode_cmp_iversion and inode_iversion_need_inc. This list of added interfaces is incomplete. And some of these interfaces could really use some justification up front. You

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

On Wed, Dec 21 2016, Jeff Layton wrote: > We already have inode_inc_iversion. Add inode_set_iversion, > inode_get_iversion, inode_cmp_iversion and inode_iversion_need_inc. This list of added interfaces is incomplete. And some of these interfaces could really use some justification up front. You

Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver

On 03/03, Vlad Zakharov wrote: > Hi Michael, Stephen, > > On Tue, 2017-02-21 at 16:11 +0300, Vlad Zakharov wrote: > > AXS10X boards manages it's clocks using various PLLs. These PLL has same > > dividers and corresponding control registers mapped to different addresses. > > So we add one common

Re: [PATCH v2] clk/axs10x: introduce AXS10X pll driver

On 03/03, Vlad Zakharov wrote: > Hi Michael, Stephen, > > On Tue, 2017-02-21 at 16:11 +0300, Vlad Zakharov wrote: > > AXS10X boards manages it's clocks using various PLLs. These PLL has same > > dividers and corresponding control registers mapped to different addresses. > > So we add one common

Re: [PATCH] Documentation/sphinx: fix primary_domain configuration

On Fri, 3 Mar 2017 12:24:05 + John Keeping wrote: > With Sphinx 1.5.3 I get the warning: > > WARNING: primary_domain 'C' not found, ignored. > > It seems that domain names in Sphinx are case-sensitive and for the C > domain the name must be lower case. Applied,

Re: [PATCH] Documentation/sphinx: fix primary_domain configuration

On Fri, 3 Mar 2017 12:24:05 + John Keeping wrote: > With Sphinx 1.5.3 I get the warning: > > WARNING: primary_domain 'C' not found, ignored. > > It seems that domain names in Sphinx are case-sensitive and for the C > domain the name must be lower case. Applied, thanks. jon

Re: [PATCH v2 09/17] Documentation: kernel-parameters: Document owl earlycon

Am 03.03.2017 um 23:46 schrieb Jonathan Corbet: > On Fri, 24 Feb 2017 04:40:47 +0100 > Andreas Färber wrote: > >> +owl, >> +Start an early, polled-mode console on an Owl serial >> +port at the specified address. The serial

Re: [PATCH v2 09/17] Documentation: kernel-parameters: Document owl earlycon

Am 03.03.2017 um 23:46 schrieb Jonathan Corbet: > On Fri, 24 Feb 2017 04:40:47 +0100 > Andreas Färber wrote: > >> +owl, >> +Start an early, polled-mode console on an Owl serial >> +port at the specified address. The serial port must >> +

Re: subdevice config into pointer (was Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times)

Hi! > > > > > Making the sub-device bus configuration a pointer should be in a > > > > > separate > > > > > patch. It makes sense since the entire configuration is not valid for > > > > > all > > > > > sub-devices attached to the ISP anymore. I think it originally was a > > > > > separate

Re: subdevice config into pointer (was Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times)

Hi! > > > > > Making the sub-device bus configuration a pointer should be in a > > > > > separate > > > > > patch. It makes sense since the entire configuration is not valid for > > > > > all > > > > > sub-devices attached to the ISP anymore. I think it originally was a > > > > > separate

[Update][PATCH v2 3/3] cpufreq: intel_pstate: Avoid triggering cpu_frequency tracepoint unnecessarily

From: Rafael J. Wysocki In the passive mode the cpu_frequency trace event is already triggered by the cpufreq core or by scaling governors, so intel_pstate should not trigger it once again for the same P-state updates. In addition to that, the frequency returned by

[Update][PATCH v2 3/3] cpufreq: intel_pstate: Avoid triggering cpu_frequency tracepoint unnecessarily

From: Rafael J. Wysocki In the passive mode the cpu_frequency trace event is already triggered by the cpufreq core or by scaling governors, so intel_pstate should not trigger it once again for the same P-state updates. In addition to that, the frequency returned by intel_cpufreq_fast_switch()

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

On Fri, Mar 03, 2017 at 03:31:06PM +0200, Andy Shevchenko wrote: > On Fri, 2017-03-03 at 00:21 +, James Hogan wrote: > > The CONFIG_HAVE_CLK=n implementation of devm_clk_get() in particular > > seems highly questionable to me, given that commit 93abe8e4b13a ("clk: > > add non CONFIG_HAVE_CLK

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

On Fri, Mar 03, 2017 at 03:31:06PM +0200, Andy Shevchenko wrote: > On Fri, 2017-03-03 at 00:21 +, James Hogan wrote: > > The CONFIG_HAVE_CLK=n implementation of devm_clk_get() in particular > > seems highly questionable to me, given that commit 93abe8e4b13a ("clk: > > add non CONFIG_HAVE_CLK

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

On Sat, Mar 04, 2017 at 09:54:44AM +1100, Dave Chinner wrote: > On Thu, Mar 02, 2017 at 04:45:40PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > Even though kmem_zalloc_greedy is documented it might fail the current > > code doesn't really implement this properly and

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

On Sat, Mar 04, 2017 at 09:54:44AM +1100, Dave Chinner wrote: > On Thu, Mar 02, 2017 at 04:45:40PM +0100, Michal Hocko wrote: > > From: Michal Hocko > > > > Even though kmem_zalloc_greedy is documented it might fail the current > > code doesn't really implement this properly and loops on the

Re: [PATCH 01/10] perf, tools, stat: Factor out callback for collecting event values

On Fri, Mar 03, 2017 at 11:33:03AM +0100, Jiri Olsa wrote: > On Tue, Feb 28, 2017 at 10:49:15PM -0800, Andi Kleen wrote: > > SNIP > > > +static void collect_data(struct perf_evsel *counter, > > + void (*cb)(struct perf_evsel *counter, void *data, > > +

Re: [PATCH 01/10] perf, tools, stat: Factor out callback for collecting event values

On Fri, Mar 03, 2017 at 11:33:03AM +0100, Jiri Olsa wrote: > On Tue, Feb 28, 2017 at 10:49:15PM -0800, Andi Kleen wrote: > > SNIP > > > +static void collect_data(struct perf_evsel *counter, > > + void (*cb)(struct perf_evsel *counter, void *data, > > +

Re: [PATCH 1/2] mm: use is_migrate_highatomic() to simplify the code

On Fri, 3 Mar 2017 14:18:08 +0100 Michal Hocko wrote: > On Fri 03-03-17 19:10:13, Xishi Qiu wrote: > > Introduce two helpers, is_migrate_highatomic() and > > is_migrate_highatomic_page(). > > Simplify the code, no functional changes. > > static inline helpers would be nicer

Re: [PATCH 1/2] mm: use is_migrate_highatomic() to simplify the code

On Fri, 3 Mar 2017 14:18:08 +0100 Michal Hocko wrote: > On Fri 03-03-17 19:10:13, Xishi Qiu wrote: > > Introduce two helpers, is_migrate_highatomic() and > > is_migrate_highatomic_page(). > > Simplify the code, no functional changes. > > static inline helpers would be nicer than macros

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > tl;dr: I think we can greatly reduce the cost of the inode->i_version > counter, by exploiting the fact that we don't need to increment it > if no one is looking at it. We can also clean up the code to prepare > to eventually expose

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

On Wed, Dec 21, 2016 at 12:03:17PM -0500, Jeff Layton wrote: > tl;dr: I think we can greatly reduce the cost of the inode->i_version > counter, by exploiting the fact that we don't need to increment it > if no one is looking at it. We can also clean up the code to prepare > to eventually expose

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

Hi Jason, On Fri, Mar 03, 2017 at 09:43:55AM -0800, Jason Uy wrote: > James, > > Can you verify that changing the code to the following fixes your problem? > > if (IS_ERR_OR_NULL(d->clk) || !old) > goto out; It does, however I'm not at all convinced it is correct. clk_get either returns a

Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used

Hi Jason, On Fri, Mar 03, 2017 at 09:43:55AM -0800, Jason Uy wrote: > James, > > Can you verify that changing the code to the following fixes your problem? > > if (IS_ERR_OR_NULL(d->clk) || !old) > goto out; It does, however I'm not at all convinced it is correct. clk_get either returns a

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote: > Hi Steve, > > On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote: > > v4l2_pipeline_inherit_controls() will add the v4l2 controls from > > all subdev entities in a pipeline to a given video device. > > > >

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote: > Hi Steve, > > On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote: > > v4l2_pipeline_inherit_controls() will add the v4l2 controls from > > all subdev entities in a pipeline to a given video device. > > > >

[PATCH] hwmon: (dell-smm) Add Dell XPS 15 9560 into DMI list

It was reported that dell-smm-hwmon is working fine on Dell XPS 15 9560. Link: http://www.spinics.net/lists/platform-driver-x86/msg10751.html Reported-by: Vasile Dumitrescu Signed-off-by: Pali Rohár --- drivers/hwmon/dell-smm-hwmon.c |7

[PATCH] hwmon: (dell-smm) Add Dell XPS 15 9560 into DMI list

It was reported that dell-smm-hwmon is working fine on Dell XPS 15 9560. Link: http://www.spinics.net/lists/platform-driver-x86/msg10751.html Reported-by: Vasile Dumitrescu Signed-off-by: Pali Rohár --- drivers/hwmon/dell-smm-hwmon.c |7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [PATCH] doc/ko_KR/memory-barriers: Update control-dependencies section

On Fri, 3 Mar 2017 15:44:02 +0900 SeongJae Park wrote: > This commit applies upstream change, commit c8241f8553e8 ("doc: Update > control-dependencies section of memory-barriers.txt"), to Korean > translation. Applied to the docs tree, thanks. jon

Re: [PATCH] doc/ko_KR/memory-barriers: Update control-dependencies section

On Fri, 3 Mar 2017 15:44:02 +0900 SeongJae Park wrote: > This commit applies upstream change, commit c8241f8553e8 ("doc: Update > control-dependencies section of memory-barriers.txt"), to Korean > translation. Applied to the docs tree, thanks. jon

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

On Thu, Mar 02, 2017 at 04:45:40PM +0100, Michal Hocko wrote: > From: Michal Hocko > > Even though kmem_zalloc_greedy is documented it might fail the current > code doesn't really implement this properly and loops on the smallest > allowed size for ever. This is a problem

Re: [PATCH 1/2] xfs: allow kmem_zalloc_greedy to fail

On Thu, Mar 02, 2017 at 04:45:40PM +0100, Michal Hocko wrote: > From: Michal Hocko > > Even though kmem_zalloc_greedy is documented it might fail the current > code doesn't really implement this properly and loops on the smallest > allowed size for ever. This is a problem because vzalloc might

[patch v2] mm, vmstat: print non-populated zones in zoneinfo

Initscripts can use the information (protection levels) from /proc/zoneinfo to configure vm.lowmem_reserve_ratio at boot. vm.lowmem_reserve_ratio is an array of ratios for each configured zone on the system. If a zone is not populated on an arch, /proc/zoneinfo suppresses its output. This

[patch v2] mm, vmstat: print non-populated zones in zoneinfo

Initscripts can use the information (protection levels) from /proc/zoneinfo to configure vm.lowmem_reserve_ratio at boot. vm.lowmem_reserve_ratio is an array of ratios for each configured zone on the system. If a zone is not populated on an arch, /proc/zoneinfo suppresses its output. This

Re: [PATCH] mm, swap: Fix a race in free_swap_and_cache()

On Wed, 1 Mar 2017 22:38:09 +0800 "Huang, Ying" wrote: > Before using cluster lock in free_swap_and_cache(), the > swap_info_struct->lock will be held during freeing the swap entry and > acquiring page lock, so the page swap count will not change when > testing page

Re: [PATCH] mm, swap: Fix a race in free_swap_and_cache()

On Wed, 1 Mar 2017 22:38:09 +0800 "Huang, Ying" wrote: > Before using cluster lock in free_swap_and_cache(), the > swap_info_struct->lock will be held during freeing the swap entry and > acquiring page lock, so the page swap count will not change when > testing page information later. But

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

On 03/03/2017 03:45 AM, Sakari Ailus wrote: On Thu, Mar 02, 2017 at 03:07:21PM -0800, Steve Longerbeam wrote: On 03/02/2017 07:53 AM, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:15PM -0800, Steve Longerbeam wrote: Add a new FRAME_TIMEOUT event to signal that a video

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

On 03/03/2017 03:45 AM, Sakari Ailus wrote: On Thu, Mar 02, 2017 at 03:07:21PM -0800, Steve Longerbeam wrote: On 03/02/2017 07:53 AM, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:15PM -0800, Steve Longerbeam wrote: Add a new FRAME_TIMEOUT event to signal that a video

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On 03/03/2017 11:17 AM, Sakari Ailus wrote: Hi Steve, On Thu, Mar 02, 2017 at 06:12:43PM -0800, Steve Longerbeam wrote: On 03/02/2017 03:48 PM, Steve Longerbeam wrote: On 03/02/2017 08:02 AM, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

On 03/03/2017 11:17 AM, Sakari Ailus wrote: Hi Steve, On Thu, Mar 02, 2017 at 06:12:43PM -0800, Steve Longerbeam wrote: On 03/02/2017 03:48 PM, Steve Longerbeam wrote: On 03/02/2017 08:02 AM, Sakari Ailus wrote: Hi Steve, On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam

Re: [PATCH] Documentation: Update path to sysrq.txt

On Fri, 24 Feb 2017 10:42:14 +0200 Krzysztof Kozlowski wrote: > Commit 9d85025b0418 ("docs-rst: create an user's manual book") moved the > sysrq.txt leaving old paths in the kernel docs. Applied to the docs tree, thanks. jon

Re: [PATCH] Documentation: Update path to sysrq.txt

On Fri, 24 Feb 2017 10:42:14 +0200 Krzysztof Kozlowski wrote: > Commit 9d85025b0418 ("docs-rst: create an user's manual book") moved the > sysrq.txt leaving old paths in the kernel docs. Applied to the docs tree, thanks. jon

Re: [PATCH] PM / OPP: Documentation: Fix opp-microvolt in examples

On Friday, March 03, 2017 09:28:05 AM Stephen Boyd wrote: > On 03/01/2017 03:09 AM, Viresh Kumar wrote: > > The triplet present in "opp-microvolt" property should be in the order > > , while all the examples have it in the order > > . > > > > Fix it. > > > > Luckily all of the users of

Re: [PATCH] PM / OPP: Documentation: Fix opp-microvolt in examples

On Friday, March 03, 2017 09:28:05 AM Stephen Boyd wrote: > On 03/01/2017 03:09 AM, Viresh Kumar wrote: > > The triplet present in "opp-microvolt" property should be in the order > > , while all the examples have it in the order > > . > > > > Fix it. > > > > Luckily all of the users of

[PATCH] net: smsc: smc91c92_cs: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/smsc/smc91c92_cs.c | 98

[PATCH] net: smsc: smc91c92_cs: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/smsc/smc91c92_cs.c | 98

Re: [PATCH v2 09/17] Documentation: kernel-parameters: Document owl earlycon

On Fri, 24 Feb 2017 04:40:47 +0100 Andreas Färber wrote: > + owl, > + Start an early, polled-mode console on an Owl serial > + port at the specified address. The serial port must > + already be setup and

Re: [PATCH v2 09/17] Documentation: kernel-parameters: Document owl earlycon

On Fri, 24 Feb 2017 04:40:47 +0100 Andreas Färber wrote: > + owl, > + Start an early, polled-mode console on an Owl serial > + port at the specified address. The serial port must > + already be setup and configured. Options

Re: [patch] mm, zoneinfo: print non-populated zones

On Fri, 3 Mar 2017, Anshuman Khandual wrote: > > This patch shows statistics for non-populated zones in /proc/zoneinfo. > > The zones exist and hold a spot in the vm.lowmem_reserve_ratio array. > > Without this patch, it is not possible to determine which index in the > > array controls which

Re: [patch] mm, zoneinfo: print non-populated zones

On Fri, 3 Mar 2017, Anshuman Khandual wrote: > > This patch shows statistics for non-populated zones in /proc/zoneinfo. > > The zones exist and hold a spot in the vm.lowmem_reserve_ratio array. > > Without this patch, it is not possible to determine which index in the > > array controls which

Re: [PATCH 4/4] thp: fix MADV_DONTNEED vs clear soft dirty race

On Thu, 2 Mar 2017 18:10:34 +0300 "Kirill A. Shutemov" wrote: > Yet another instance of the same race. > > Fix is identical to change_huge_pmd(). Nit: someone who is reading this changelog a year from now will be quite confused - how do they work out what the

Re: [PATCH 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer

Hi simran, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.10 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/simran-singhal/staging-nvec

Re: [PATCH 4/4] thp: fix MADV_DONTNEED vs clear soft dirty race

On Thu, 2 Mar 2017 18:10:34 +0300 "Kirill A. Shutemov" wrote: > Yet another instance of the same race. > > Fix is identical to change_huge_pmd(). Nit: someone who is reading this changelog a year from now will be quite confused - how do they work out what the race was? I'll add : See "thp:

Re: [PATCH 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer

Hi simran, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.10 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/simran-singhal/staging-nvec

[PATCH] sparc64: Fix size check in huge_pte_alloc

Signed-off-by: Nitin Gupta --- arch/sparc/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c index 323bc6b..3016850 100644 --- a/arch/sparc/mm/hugetlbpage.c +++

[PATCH] sparc64: Fix size check in huge_pte_alloc

Signed-off-by: Nitin Gupta --- arch/sparc/mm/hugetlbpage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c index 323bc6b..3016850 100644 --- a/arch/sparc/mm/hugetlbpage.c +++ b/arch/sparc/mm/hugetlbpage.c @@ -261,7

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

The patch ordering is a little annoying as I'd like to be able to be able to verify the implementation at the same time these new interfaces are added, but, I don't know, I don't have a better idea. Anyway, various nits: On Wed, Dec 21, 2016 at 12:03:28PM -0500, Jeff Layton wrote: > We already

Re: [RFC PATCH v1 11/30] fs: new API for handling i_version

The patch ordering is a little annoying as I'd like to be able to be able to verify the implementation at the same time these new interfaces are added, but, I don't know, I don't have a better idea. Anyway, various nits: On Wed, Dec 21, 2016 at 12:03:28PM -0500, Jeff Layton wrote: > We already

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