Re: [Patch] irqdomain: Introduce new interfaces to support hierarchy irqdomains

[Jiang Liu]

On 2014/9/23 17:43, Joe.C wrote:
> On Mon, 2014-09-22 at 16:17 +0800, Jiang Liu wrote:
>> @@ -388,7 +389,6 @@ EXPORT_SYMBOL_GPL(irq_create_direct_mapping);
>>  unsigned int irq_create_mapping(struct irq_domain *domain,
>>  irq_hw_number_t hwirq)
>>  {
>> -unsigned int hint;
>>  int virq;
>>  
>>  pr_debug("irq_create_mapping(0x%p, 0x%lx)\n", domain, hwirq);
>> @@ -410,12 +410,8 @@ unsigned int irq_create_mapping(struct irq_domain 
>> *domain,
>>  }
>>  
>>  /* Allocate a virtual interrupt number */
>> -hint = hwirq % nr_irqs;
>> -if (hint == 0)
>> -hint++;
>> -virq = irq_alloc_desc_from(hint, of_node_to_nid(domain->of_node));
>> -if (virq <= 0)
>> -virq = irq_alloc_desc_from(1, of_node_to_nid(domain->of_node));
>> +virq = irq_domain_alloc_descs(-1, 1, hwirq,
>> +  of_node_to_nid(domain->of_node));
> 
> If I read this correct, the resulting virq is different after your
> change.
It should have the same effect. We just factored out original code as
a function, so it could be reused.

> 
>>  if (virq <= 0) {
>>  pr_debug("-> virq allocation failed\n");
>>  return 0;
>> @@ -490,7 +486,10 @@ unsigned int irq_create_of_mapping(struct 
>> of_phandle_args *irq_data)
>>  }
>>  
>>  /* Create mapping */
>> -virq = irq_create_mapping(domain, hwirq);
>> +if (irq_domain_is_hierarchy(domain))
>> +virq = irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE, irq_data);
>> +else
>> +virq = irq_create_mapping(domain, hwirq);
>>  if (!virq)
>>  return virq;
> 
> hwirq returned from xlat above is lost. Without hwirq or virq, how do we
> know which irq are we working for?
> Also, if the irq_desc/irq_data was already created, this will create
> another one. Should we do irq_find_mapping just like irq_create_mapping?
When irq_create_of_mapping is called, IRQ desc/irq_data haven't been
allocated yet. The parameter irq_data is type of struct of_phandle_args
instead of struct irq_data:)

We pass irq_data to irq_domain_alloc_irqs(), the we could reconstruct
hwirq from irq_data if needed.

To make the code clearer, I plan to change code as below:
unsigned int irq_create_of_mapping(struct of_phandle_args *irq_data)
{
struct irq_domain *domain;
irq_hw_number_t hwirq;
unsigned int type = IRQ_TYPE_NONE;
unsigned int virq;

domain = irq_data->np ? irq_find_host(irq_data->np) :
irq_default_domain;
if (!domain) {
pr_warn("no irq domain found for %s !\n",
of_node_full_name(irq_data->np));
return 0;
}

+if (irq_domain_is_hierarchy(domain))
+return irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE,
irq_data);
+
/* If domain has no translation, then we assume interrupt line */
if (domain->ops->xlate == NULL)
hwirq = irq_data->args[0];
else {
if (domain->ops->xlate(domain, irq_data->np, irq_data->args,
irq_data->args_count, ,
))
return 0;
}

/* Create mapping */
virq = irq_create_mapping(domain, hwirq);
if (!virq)
return virq;

/* Set type if specified and different than the current one */
if (type != IRQ_TYPE_NONE &&
type != irq_get_trigger_type(virq))
irq_set_irq_type(virq, type);
return virq;
}
EXPORT_SYMBOL_GPL(irq_create_of_mapping);

>> +int __irq_domain_alloc_irqs(struct irq_domain *domain, int irq_base,
>> +unsigned int nr_irqs, int node, void *arg,
>> +bool realloc)
>> +{
>> +int i, ret, virq;
>> +
>> +if (domain == NULL) {
>> +domain = irq_default_domain;
>> +if (WARN(!domain, "domain is NULL; cannot allocate IRQ\n"))
>> +return -EINVAL;
>> +}
>> +
>> +if (!domain->ops->alloc) {
>> +pr_debug("domain->ops->alloc() is NULL\n");
>> +return -ENOSYS;
>> +}
>> +
>> +if (realloc && irq_base >= 0) {
>> +virq =  irq_base;
>  ^
> extra space here.
Will fix it in next version.
Thanks, Joe!
Gerry
> 
> Joe.C
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the samsung tree

[Stephen Rothwell]

Hi Kukjin,

On Wed, 24 Sep 2014 12:04:36 +0900 Kukjin Kim  wrote:
>
> > After merging the samsung tree, today's linux-next build (arm 
> > multi_v7_defconfig)
> > failed like this:
> > 
> > arch/arm/boot/dts/exynos5250-snow.dts:13:46: fatal error: 
> > dt-bindings/clock/maxim,max77686.h: No such
> > file or directory
> >  #include 
> >   ^
> > 
> + Mike
> 
> Hmm... I think, inclusion of the header file should be included in Mike's clk
> tree...What's wrong?

Mike's clk tree is included in linux-next well after your tree ... and
does Mike's tree get included in the arm-soc tree like your does?  So,
clearly you can't build this tree on its own?

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

linux-next: manual merge of the tip tree with the audit tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/ptrace.c between commit 91397401bb50 ("ARCH: AUDIT:
audit_syscall_entry() should not require the arch") from the audit tree
and commit e0ffbaabc46d ("x86: Split syscall_trace_enter into two
phases") from the tip tree.

I fixed it up (see below - there is more cleanup possible since
do_audit_syscall_entry() no longer needs its "arch" argument) and can
carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/x86/kernel/ptrace.c
index eb1c87f0b03b,29576c244699..
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@@ -1441,24 -1441,126 +1441,126 @@@ void send_sigtrap(struct task_struct *t
force_sig_info(SIGTRAP, , tsk);
  }
  
- 
- #ifdef CONFIG_X86_32
- # define IS_IA32  1
- #elif defined CONFIG_IA32_EMULATION
- # define IS_IA32  is_compat_task()
- #else
- # define IS_IA32  0
+ static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch)
+ {
+ #ifdef CONFIG_X86_64
+   if (arch == AUDIT_ARCH_X86_64) {
 -  audit_syscall_entry(arch, regs->orig_ax, regs->di,
++  audit_syscall_entry(regs->orig_ax, regs->di,
+   regs->si, regs->dx, regs->r10);
+   } else
  #endif
+   {
 -  audit_syscall_entry(arch, regs->orig_ax, regs->bx,
++  audit_syscall_entry(regs->orig_ax, regs->bx,
+   regs->cx, regs->dx, regs->si);
+   }
+ }
  
  /*
-  * We must return the syscall number to actually look up in the table.
-  * This can be -1L to skip running any syscall at all.
+  * We can return 0 to resume the syscall or anything else to go to phase
+  * 2.  If we resume the syscall, we need to put something appropriate in
+  * regs->orig_ax.
+  *
+  * NB: We don't have full pt_regs here, but regs->orig_ax and regs->ax
+  * are fully functional.
+  *
+  * For phase 2's benefit, our return value is:
+  * 0: resume the syscall
+  * 1: go to phase 2; no seccomp phase 2 needed
+  * anything else: go to phase 2; pass return value to seccomp
   */
- long syscall_trace_enter(struct pt_regs *regs)
+ unsigned long syscall_trace_enter_phase1(struct pt_regs *regs, u32 arch)
+ {
+   unsigned long ret = 0;
+   u32 work;
+ 
+   BUG_ON(regs != task_pt_regs(current));
+ 
+   work = ACCESS_ONCE(current_thread_info()->flags) &
+   _TIF_WORK_SYSCALL_ENTRY;
+ 
+   /*
+* If TIF_NOHZ is set, we are required to call user_exit() before
+* doing anything that could touch RCU.
+*/
+   if (work & _TIF_NOHZ) {
+   user_exit();
+   work &= ~TIF_NOHZ;
+   }
+ 
+ #ifdef CONFIG_SECCOMP
+   /*
+* Do seccomp first -- it should minimize exposure of other
+* code, and keeping seccomp fast is probably more valuable
+* than the rest of this.
+*/
+   if (work & _TIF_SECCOMP) {
+   struct seccomp_data sd;
+ 
+   sd.arch = arch;
+   sd.nr = regs->orig_ax;
+   sd.instruction_pointer = regs->ip;
+ #ifdef CONFIG_X86_64
+   if (arch == AUDIT_ARCH_X86_64) {
+   sd.args[0] = regs->di;
+   sd.args[1] = regs->si;
+   sd.args[2] = regs->dx;
+   sd.args[3] = regs->r10;
+   sd.args[4] = regs->r8;
+   sd.args[5] = regs->r9;
+   } else
+ #endif
+   {
+   sd.args[0] = regs->bx;
+   sd.args[1] = regs->cx;
+   sd.args[2] = regs->dx;
+   sd.args[3] = regs->si;
+   sd.args[4] = regs->di;
+   sd.args[5] = regs->bp;
+   }
+ 
+   BUILD_BUG_ON(SECCOMP_PHASE1_OK != 0);
+   BUILD_BUG_ON(SECCOMP_PHASE1_SKIP != 1);
+ 
+   ret = seccomp_phase1();
+   if (ret == SECCOMP_PHASE1_SKIP) {
+   regs->orig_ax = -1;
+   ret = 0;
+   } else if (ret != SECCOMP_PHASE1_OK) {
+   return ret;  /* Go directly to phase 2 */
+   }
+ 
+   work &= ~_TIF_SECCOMP;
+   }
+ #endif
+ 
+   /* Do our best to finish without phase 2. */
+   if (work == 0)
+   return ret;  /* seccomp and/or nohz only (ret == 0 here) */
+ 
+ #ifdef CONFIG_AUDITSYSCALL
+   if (work == _TIF_SYSCALL_AUDIT) {
+   /*
+* If there is no more work to be done except auditing,
+* then audit in phase 1.  Phase 2 always audits, so, if
+* we audit here, then we can't go on to phase 2.
+*/
+   do_audit_syscall_entry(regs, arch);
+   return 0;
+   }
+ #endif
+ 
+   

Re: [PATCH] dma: cppi41: Switch to using managed resource in probe

[Kiran Padwal]

On Tuesday 23 September 2014 09:10 PM, Vinod Koul wrote:
> On Tue, Sep 23, 2014 at 06:20:46PM +0530, Kiran Padwal wrote:
>> This change uses managed resource APIs to allocate resources such as,
>> mem, irq in order to simplify the driver unload or failure cases.
>>
>> Signed-off-by: Kiran Padwal 
>> ---
>>  drivers/dma/cppi41.c |   15 ---
>>  1 file changed, 4 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
>> index 5921ce3..d3700fb 100644
>> --- a/drivers/dma/cppi41.c
>> +++ b/drivers/dma/cppi41.c
>> @@ -938,7 +938,7 @@ static int cppi41_dma_probe(struct platform_device *pdev)
>>  if (!glue_info)
>>  return -EINVAL;
>>  
>> -cdd = kzalloc(sizeof(*cdd), GFP_KERNEL);
>> +cdd = devm_kzalloc(>dev, sizeof(*cdd), GFP_KERNEL);
>>  if (!cdd)
>>  return -ENOMEM;
>>  
>> @@ -959,10 +959,8 @@ static int cppi41_dma_probe(struct platform_device 
>> *pdev)
>>  cdd->qmgr_mem = of_iomap(dev->of_node, 3);
>>  
>>  if (!cdd->usbss_mem || !cdd->ctrl_mem || !cdd->sched_mem ||
>> -!cdd->qmgr_mem) {
>> -ret = -ENXIO;
>> -goto err_remap;
>> -}
>> +!cdd->qmgr_mem)
>> +return -ENXIO;
>>  
>>  pm_runtime_enable(dev);
>>  ret = pm_runtime_get_sync(dev);
>> @@ -989,7 +987,7 @@ static int cppi41_dma_probe(struct platform_device *pdev)
>>  
>>  cppi_writel(USBSS_IRQ_PD_COMP, cdd->usbss_mem + USBSS_IRQ_ENABLER);
>>  
>> -ret = request_irq(irq, glue_info->isr, IRQF_SHARED,
>> +ret = devm_request_irq(>dev, irq, glue_info->isr, IRQF_SHARED,
>>  dev_name(dev), cdd);
>>  if (ret)
>>  goto err_irq;
>> @@ -1009,7 +1007,6 @@ static int cppi41_dma_probe(struct platform_device 
>> *pdev)
>>  err_of:
>>  dma_async_device_unregister(>ddev);
>>  err_dma_reg:
>> -free_irq(irq, cdd);
>>  err_irq:
>>  cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
>>  cleanup_chans(cdd);
>> @@ -1023,8 +1020,6 @@ err_get_sync:
>>  iounmap(cdd->ctrl_mem);
>>  iounmap(cdd->sched_mem);
>>  iounmap(cdd->qmgr_mem);
>> -err_remap:
>> -kfree(cdd);
>>  return ret;
>>  }
>>  
>> @@ -1036,7 +1031,6 @@ static int cppi41_dma_remove(struct platform_device 
>> *pdev)
>>  dma_async_device_unregister(>ddev);
>>  
>>  cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
>> -free_irq(cdd->irq, cdd);
> pls use devm_free_irq() explicitly here, other wise your controller is active 
> and able
> to send interrupts and driver object is getting removed. It is the role of
> driver to quiesce device before releasing
> 

Thanks, I will take care of that and resend the patch.



--
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 1/2] perf: Add sampling of the raw monotonic clock

[Namhyung Kim]

Hi Pawel,

On Tue, 23 Sep 2014 18:03:06 +0100, Pawel Moll wrote:
> This patch adds an option to sample raw monotonic clock
> value with any perf event, with the the aim of allowing
> time correlation between data coming from perf and
> additional performance-related information generated in
> userspace.
>
> In order to correlate timestamps in perf data stream
> with events happening in userspace (be it JITed debug
> symbols or hwmon-originating environment data), user
> requests a more or less periodic event (sched_switch
> trace event of a hrtimer-based cpu-clock being the
> most obvious examples) with PERF_SAMPLE_TIME *and*
> PERF_SAMPLE_CLOCK_RAW_MONOTONIC and stamps
> user-originating data with values obtained from
> clock_gettime(CLOCK_MONOTONIC_RAW). Then, during
> analysis, one looks at the perf events immediately
> preceding and following (in terms of the
> clock_raw_monotonic sample) the userspace event and
> does simple linear approximation to get the equivalent
> perf time.
>
> perf event user event
>-O--+-O--> t_mono
> :  | :
> :  V :
>-OO--> t_perf

Probably a dumb question: why not make PERF_SAMPLE_TIME being monotonic
clock instead of adding a new PERF_SAMPLE_CLOCK_XXX flag?  Maybe we can
add a new ioctl command like PERF_EVENT_IOC_SET_CLOCK so that one can
pass a clock id.

Thanks,
Namhyung


>
> Signed-off-by: Pawel Moll 
> ---
> Changes since v1:
>
> - none
>
>  include/linux/perf_event.h  |  2 ++
>  include/uapi/linux/perf_event.h |  4 +++-
>  kernel/events/core.c| 13 +
>  3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 707617a..28b73b2 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -602,6 +602,8 @@ struct perf_sample_data {
>* Transaction flags for abort events:
>*/
>   u64 txn;
> + /* Raw monotonic timestamp, for userspace time correlation */
> + u64 clock_raw_monotonic;
>  };
>  
>  static inline void perf_sample_data_init(struct perf_sample_data *data,
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 9269de2..e5a75c5 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -137,8 +137,9 @@ enum perf_event_sample_format {
>   PERF_SAMPLE_DATA_SRC= 1U << 15,
>   PERF_SAMPLE_IDENTIFIER  = 1U << 16,
>   PERF_SAMPLE_TRANSACTION = 1U << 17,
> + PERF_SAMPLE_CLOCK_RAW_MONOTONIC = 1U << 18,
>  
> - PERF_SAMPLE_MAX = 1U << 18, /* non-ABI */
> + PERF_SAMPLE_MAX = 1U << 19, /* non-ABI */
>  };
>  
>  /*
> @@ -686,6 +687,7 @@ enum perf_event_type {
>*  { u64   weight;   } && PERF_SAMPLE_WEIGHT
>*  { u64   data_src; } && PERF_SAMPLE_DATA_SRC
>*  { u64   transaction; } && 
> PERF_SAMPLE_TRANSACTION
> +  *  { u64   clock_raw_monotonic; } && 
> PERF_SAMPLE_CLOCK_RAW_MONOTONIC
>* };
>*/
>   PERF_RECORD_SAMPLE  = 9,
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index f9c1ed0..f6df547 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -1216,6 +1216,9 @@ static void perf_event__header_size(struct perf_event 
> *event)
>   if (sample_type & PERF_SAMPLE_TRANSACTION)
>   size += sizeof(data->txn);
>  
> + if (sample_type & PERF_SAMPLE_CLOCK_RAW_MONOTONIC)
> + size += sizeof(data->clock_raw_monotonic);
> +
>   event->header_size = size;
>  }
>  
> @@ -4456,6 +4459,13 @@ static void __perf_event_header__init_id(struct 
> perf_event_header *header,
>   data->cpu_entry.cpu  = raw_smp_processor_id();
>   data->cpu_entry.reserved = 0;
>   }
> +
> + if (sample_type & PERF_SAMPLE_CLOCK_RAW_MONOTONIC) {
> + struct timespec now;
> +
> + getrawmonotonic();
> + data->clock_raw_monotonic = timespec_to_ns();
> + }
>  }
>  
>  void perf_event_header__init_id(struct perf_event_header *header,
> @@ -4714,6 +4724,9 @@ void perf_output_sample(struct perf_output_handle 
> *handle,
>   if (sample_type & PERF_SAMPLE_TRANSACTION)
>   perf_output_put(handle, data->txn);
>  
> + if (sample_type & PERF_SAMPLE_CLOCK_RAW_MONOTONIC)
> + perf_output_put(handle, data->clock_raw_monotonic);
> +
>   if (!event->attr.watermark) {
>   int wakeup_events = event->attr.wakeup_events;
--
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  

linux-next: manual merge of the tip tree with the audit tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
arch/x86/kernel/entry_64.S between commit b4f0d3755c5e ("audit: x86:
drop arch from __audit_syscall_entry() interface") from the audit tree
and commit 1dcf74f6edfc ("x86_64, entry: Use split-phase
syscall_trace_enter for 64-bit syscalls") from the tip tree.

I fixed it up (probably incorrectly - I removed the auditsys section
as that is what the latter did) and can carry the fix as necessary (no
action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [GIT PULL] qcom DT changes for v3.18-2

[Olof Johansson]

On Mon, Sep 22, 2014 at 03:15:47PM -0500, Kumar Gala wrote:
> The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
> 
>   Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git 
> tags/qcom-dt-for-3.18-2
> 
> for you to fetch changes up to aabff7bfe55afd01d71a5f11d4a84bd873c20f5e:
> 
>   ARM: DT: msm8960: Add sdcc nodes (2014-09-22 13:49:43 -0500)
> 
> 
> Qualcomm ARM Based Device Tree Updates for v3.18-2
> 
> * Added SDCC nodes on MSM8960/CDP and MSM8660/SURF
> * Added I2C and SDCC4/WLAN on APQ8064/IFC6410
> * Added I2C on MSM8984/DB8074

Merged, thanks!

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

Re: [GIT PULL] qcom DT changes for v3.18

[Olof Johansson]

On Fri, Sep 12, 2014 at 02:40:41PM -0500, Kumar Gala wrote:
> The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:
> 
>   Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom.git 
> tags/qcom-dt-for-3.18
> 
> for you to fetch changes up to edb81ca3bf586ad526ee67b245cb87f7c7142a87:
> 
>   ARM: DT: QCOM: apq8064: Add dma support for sdcc node (2014-09-11 12:07:40 
> -0500)
> 
> 
> Qualcomm ARM Based Device Tree Updates for v3.18
> 
> * Added APQ8084 dt support for clocks, serial, pinctrl, and IFC6540 board
> * Added IPQ8064 dt support for basic SoC and AP148 board
> * Added APQ8064 dt support for pinctrl, reset, SDHC, and multimedia clocks
> * Added PMIC 8058 dt support on MSM8660, enables PMIC based power key,
>   keypad, rtc, and vibrator
> * Added PMIC 8921 dt support on MSM8960, enables PMIC based power key,
>   keypad, and rtc

Merged, thanks.


-Olof
--
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] soc: qcom: do not disable the iface clock in probe

[Olof Johansson]

On Tue, Sep 23, 2014 at 08:20:54PM +0100, Srinivas Kandagatla wrote:
> since commit 31964ffebbb9 ("tty: serial: msm: Remove direct access to GSBI")'
> serial hangs if earlyprintk are enabled.
> 
> This hang is noticed only when the GSBI driver is probed and all the
> earlyprintks before gsbi probe are seen on the console.
> The reason why it hangs is because GSBI driver disables hclk in its
> probe function without realizing that the serial IP might be in use by
> a bootconsole. As gsbi driver disables the clock in probe the
> bootconsole locks up.
> 
> Turning off hclk's could be dangerous if there are system components
> like earlyprintk using the hclk.
> 
> This patch fixes the issue by delegating the clock management to
> probe and remove functions in gsbi rather than disabling the clock in probe.
> 
> More detailed problem description can be found here:
> http://www.spinics.net/lists/linux-arm-msm/msg10589.html
> 
> Tested-by: Linus Walleij 
> Signed-off-by: Srinivas Kandagatla 
> ---
> Hi Kevin, 
> 
> Am resending this patch with reference to the problem and adding more
> details to the log.
> 
> Could you pick this fix for the next rc, as this fixes a serial console
> hang with earlyprintk on SOCs like APQ8064.
> 
> Changes since v1:
>   - added more info in the change log as requested by Kumar and Kevin.

Applied to fixes.


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

Re: [GIT PULL] at91: drivers for 3.18 #2 (bis)

[Olof Johansson]

On Mon, Sep 15, 2014 at 06:12:43PM +0200, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> I re-send this pull-request with the work done by Maxime to take Arnd's
> comments into annount: removal of the early_platform devices, and by keeping
> the old mechanism with a function exported by the PIT timer and called by the
> board files.
> 
> Here is the old message that I sent you: just as a reference.
> "
> This pull-request is focused on the work that Maxime did for migrating our
> timer (PIT) to the clocksource sub-system. A big cleanup happened which allows
> us to be even closer to the point when we have only the bare minimum in our
> formerly crowded mach-at91 directory.
> "
> 
> This pull-request goes on top of what is already in your at91/drivers branch.
> 
> Thanks, best regards,
> 
> The following changes since commit 405a72c5e78b5c560c8b2711d4000fa5eb063e1b:
> 
>   power: reset: at91-poweroff: fix wakeup status register index (2014-09-01 
> 18:40:44 +0200)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-drivers2
> 
> for you to fetch changes up to b052ff30cd450c91a32e8e928979bca021462996:
> 
>   ARM: at91: PIT: Move the driver to drivers/clocksource (2014-09-15 17:55:48 
> +0200)
> 
> 
> Second drivers series for AT91/3.18:
> - move of the PIT (basic timer) from mach-at91 to its proper location:
>   drivers/clocksource
> - big cleanup of this driver along the way

Thanks, merged.


-Olof
--
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] irqdomain: Introduce new interfaces to support hierarchy irqdomains

[Jiang Liu]

Thanks Randy! I will fix these issues in next version.
Regards!
Gerry

On 2014/9/23 1:30, Randy Dunlap wrote:
> On 09/22/14 01:17, Jiang Liu wrote:
>> ---
>>  Documentation/IRQ-domain.txt |   71 +
>>  include/linux/irq.h  |3 +
>>  include/linux/irqdomain.h|   86 ++
>>  kernel/irq/Kconfig   |3 +
>>  kernel/irq/chip.c|3 +
>>  kernel/irq/irqdomain.c   |  360 
>> --
>>  6 files changed, 510 insertions(+), 16 deletions(-)
>>
>> diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
>> index 8a8b82c9ca53..062f6b6088b4 100644
>> --- a/Documentation/IRQ-domain.txt
>> +++ b/Documentation/IRQ-domain.txt
>> @@ -151,3 +151,74 @@ used and no descriptor gets allocated it is very 
>> important to make sure
>>  that the driver using the simple domain call irq_create_mapping()
>>  before any irq_find_mapping() since the latter will actually work
>>  for the static IRQ assignment case.
>> +
>> + Hierarchy IRQ domain 
>> +On some architectures, there may be multiple interrupt controllers
>> +involved in delivering an interrupt from the device to the target CPU.
>> +Let's look at a typical interrupt delivering path on x86 platforms:
>> +
>> +Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU
>> +
>> +There are three interrupt controllers involved:
>> +1) IOAPIC controller
>> +2) Interrupt remapping controller
>> +3) Local APIC controller
>> +
>> +To support such a hardware topology and make software architecture match
>> +hardware architecture, an irq_domain data structure is built for each
>> +interrupt controller and those irq_domains are organized into hierarchy.
>> +When building irq_domain hierarchy, the irq_domain near to the device is
>> +child and the irq_domain near to CPU is parent. So a hierarchy structure
>> +as below will be built for the example above.
>> +CPU Vector irq_domain (root irq_domain to manage CPU vectors)
>> +^
>> +|
>> +Interrupt Remapping irq_domain (manage irq_remapping entries)
>> +^
>> +|
>> +IOAPIC irq_domain (manage IOAPIC delivery entries/pins)
>> +
>> +There are four major interfaces to use hierarchy irq_domain:
>> +1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt
>> +   controller related resources to deliver these interrupts.
>> +2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controler
> 
>  controller
> 
>> +   related resources associated with these interrupts.
>> +3) irq_domain_activate_irq(): activate interrupt controller hardware to
>> +   deliver the interrupt.
>> +3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
>> +   to stopping delivering the interrupt.
> 
>   to stop
> 
>> +
>> +Following changes are needed to support hierarchy irq_domain.
>> +1) a new field 'parent' is added to struct irq_domain, it's used to
> 
>   irq_domain;
> 
>> +   maintain irq_domain hierarchy information.
>> +2) a new field 'parent_data' is added to struct irq_data, it's used to
> 
>irq_data;
> 
>> +   build hierarchy irq_data to match hierarchy irq_domains. The irq_data
>> +   is used to store irq_domain pointer and hardware irq number.
>> +3) new callbacks are added to struct irq_domain_ops to support hierarchy
>> +   irq_domain operations.
>> +
>> +With support of hierarchy irq_domain and hierarchy irq_data ready, an
>> +irq_domain structure is built for each interrupt controller, and an
>> +irq_data structure is allocated for each irq_domain associated with an
>> +IRQ. Now we could go one step further to support stacked(hierarchy)
>> +irq_chip. That is, an irq_chip is associated with each irq_data along
>> +the hierarchy. A child irq_chip may implement a required action by
>> +itself or by cooperating with its parent irq_chip.
>> +
>> +With stacked irq_chip, interrupt controller driver only needs to deal
>> +with the hardware managed by itself and may ask for services from its
>> +parent irq_chip when needed. So we could achieve a much more cleaner
> 
> a much cleaner
> 
>> +software architecture.
>> +
>> +For an interrupt controller driver to support hierarchy irq_domain, it
>> +needs to:
>> +1) Implement irq_domain_ops.alloc and irq_domain_ops.free
>> +2) Optionally implement irq_domain_ops.activate and
>> +   irq_domain_ops.deactivate.
>> +3) Optionally implement an irq_chip to manage the interrupt controller
>> +   hardware.
>> +4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,
>> +   they are unused with hierarchy irq_domain.
>> +
>> +Hierarchy irq_domain may also be used to support other architectures,
>> +such as ARM, ARM64 etc.
> 
>> diff --git a/include/linux/irqdomain.h 

Re: [PATCH] parisc:Remove unnecessary FIXMES in init.c

[Guenter Roeck]

On Tue, Sep 23, 2014 at 09:49:43PM -0400, Nicholas Krause wrote:
> This removes the two fixmes in the file, init.c for compiler hints
> for comments related to compiler hints in linux_gateway_page_addr
> and map_hpux_gateway_page to change from FIXME to HINT in order
> for people reading this code to understand that these are compiler
> hints.
> 

"* const" tells the compiler that a pointer is a constant.
It doesn't tell the compiler that the data shall not be treated
as DP-relative.

FIXME as in: We should find a better way to tell the compiler to
not treat this data as DP-relative.

Can you please stop this ?

Guenter

> Signed-off-by: Nicholas Krause 
> ---
>  arch/parisc/mm/init.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
> index 0bef864..668102e 100644
> --- a/arch/parisc/mm/init.c
> +++ b/arch/parisc/mm/init.c
> @@ -733,7 +733,7 @@ static void __init pagetable_init(void)
>  static void __init gateway_init(void)
>  {
>   unsigned long linux_gateway_page_addr;
> - /* FIXME: This is 'const' in order to trick the compiler
> + /* HINT: This is 'const' in order to trick the compiler
>  into not treating it as DP-relative data. */
>   extern void * const linux_gateway_page;
>  
> @@ -761,7 +761,7 @@ map_hpux_gateway_page(struct task_struct *tsk, struct 
> mm_struct *mm)
>   unsigned long start_pte;
>   unsigned long address;
>   unsigned long hpux_gw_page_addr;
> - /* FIXME: This is 'const' in order to trick the compiler
> + /* HINT: This is 'const' in order to trick the compiler
>  into not treating it as DP-relative data. */
>   extern void * const hpux_gateway_page;
>  
> -- 
> 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/
> 
> 
--
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] net_dma: fix memory leak in dma_pin_iocvec_pages

[Vinod Koul]

On Wed, Sep 03, 2014 at 01:28:59PM +0400, Roman Gushchin wrote:
> dma_pin_iovec_pages() calls get_user_pages() for each iovec. If
> get_user_pages() returns a number smaller than the requested number,
> dma_pin_iovec_pages() calls dma_unpin_iovec_pages(). It releases
> previously allocated iovecs, but pages pinned by last get_user_pages()
> call remain unreleased.
> Fix this by calling put_page() for each such page.
> 
Applied, thanks

-- 
~Vinod
--
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 linux-next] Documentation: mic: mpssd: Disable mpssd builds for kernels < 3.13

[ashutosh dixit]

On Tue, Sep 23 2014 at 09:59:32 PM, Andrew Morton  
wrote:
> On Tue, 23 Sep 2014 21:51:09 -0700 ashutosh dixit  
> wrote:
>
>> On Tue, Sep 23 2014 at 05:58:19 PM, Peter Foley  wrote:
>> > On Tue, Sep 23, 2014 at 8:51 PM, Andrew Morton
>> >  wrote:
>> >> Can't we just fix the Makefiles?  Cook up a rule which makes
>> >> headers_install (if needed) before building Documentation/?
>> >
>> > Currently, the ordering is enforced by
>> > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Makefile#n946
>> > I'll take a look at making Documentation/ depend on headers_install.
>> >
>> I would think it is preferable to keep the 'make headers_install' and
>> 'make Documentation/' steps separate, as they currently are, so that
>> only the people who need to upgrade system headers do that, rather than
>> forcing people to upgrade system headers each time something in
>> Documentation/ is recompiled and moreover doing that compile/install as
>> root.
>
> headers_install installs into ./usr/include and ./include.  It's local
> to the kernel build tree.

Sorry about that. Yes, the build indeed succeeds if run after
headers_install, so making Documentation/ depend on headers_install is
indeed a possibility.
--
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 1/3] usb: gadget: Refactor request completion

[Michal Sojka]

Dear Felipe,

On Wed, Sep 17 2014, Felipe Balbi wrote:
> On Wed, Sep 17, 2014 at 09:21:11AM +0200, Michal Sojka wrote:
>> All USB peripheral controller drivers called completion routines
>> directly. This patch moves the completion call from drivers to
>> usb_gadget_giveback_request(), in order to have a place where common
>> functionality can be added.
>> 
>> All places in drivers/usb/ matching "[-.]complete(" were replaced with a
>> call to usb_gadget_giveback_request(). This was compile-tested with all
>> ARM drivers enabled and runtime-tested for musb.
>> 
>> Signed-off-by: Michal Sojka 
>> ---
>>  drivers/usb/chipidea/udc.c  |  6 +++---
>>  drivers/usb/dwc2/gadget.c   |  6 +++---
>>  drivers/usb/dwc3/gadget.c   |  2 +-
>>  drivers/usb/gadget/udc/amd5536udc.c |  2 +-
>>  drivers/usb/gadget/udc/at91_udc.c   |  2 +-
>>  drivers/usb/gadget/udc/atmel_usba_udc.c |  4 ++--
>>  drivers/usb/gadget/udc/bcm63xx_udc.c|  2 +-
>>  drivers/usb/gadget/udc/dummy_hcd.c  | 10 +-
>>  drivers/usb/gadget/udc/fotg210-udc.c|  2 +-
>>  drivers/usb/gadget/udc/fsl_qe_udc.c |  6 +-
>>  drivers/usb/gadget/udc/fsl_udc_core.c   |  6 ++
>>  drivers/usb/gadget/udc/fusb300_udc.c|  2 +-
>>  drivers/usb/gadget/udc/goku_udc.c   |  2 +-
>>  drivers/usb/gadget/udc/gr_udc.c |  2 +-
>>  drivers/usb/gadget/udc/lpc32xx_udc.c|  2 +-
>>  drivers/usb/gadget/udc/m66592-udc.c |  2 +-
>>  drivers/usb/gadget/udc/mv_u3d_core.c|  8 ++--
>>  drivers/usb/gadget/udc/mv_udc_core.c|  8 ++--
>>  drivers/usb/gadget/udc/net2272.c|  2 +-
>>  drivers/usb/gadget/udc/net2280.c|  2 +-
>>  drivers/usb/gadget/udc/omap_udc.c   |  2 +-
>>  drivers/usb/gadget/udc/pch_udc.c|  2 +-
>>  drivers/usb/gadget/udc/pxa25x_udc.c |  2 +-
>>  drivers/usb/gadget/udc/pxa27x_udc.c |  2 +-
>>  drivers/usb/gadget/udc/r8a66597-udc.c   |  2 +-
>>  drivers/usb/gadget/udc/s3c-hsudc.c  |  3 +--
>>  drivers/usb/gadget/udc/s3c2410_udc.c|  2 +-
>>  drivers/usb/gadget/udc/udc-core.c   | 19 +++
>>  drivers/usb/musb/musb_gadget.c  |  2 +-
>>  drivers/usb/renesas_usbhs/mod_gadget.c  |  2 +-
>>  include/linux/usb/gadget.h  |  8 
>
> I would rather split this into several patches, btw. With the
> introduction of usb_gadget_giveback_request() being the first one in the
> series. It's easier to review that way.

This would be no problem.

>> diff --git a/drivers/usb/gadget/udc/udc-core.c 
>> b/drivers/usb/gadget/udc/udc-core.c
>> index b0d9817..29789f1 100644
>> --- a/drivers/usb/gadget/udc/udc-core.c
>> +++ b/drivers/usb/gadget/udc/udc-core.c
>> @@ -106,6 +106,25 @@ EXPORT_SYMBOL_GPL(usb_gadget_unmap_request);
>>  
>>  /* 
>> - */
>>  
>> +/**
>> + * usb_gadget_giveback_request - give the request back to the gadget layer
>> + * Context: in_interrupt()
>> + *
>> + * This is called by device controller drivers in order to return the
>> + * completed request back to the gadget layer.
>> + */
>> +void usb_gadget_giveback_request(struct usb_ep *ep,
>> +struct usb_request *req)
>> +{
>> +if (likely(req->complete))
>> +req->complete(ep, req);
>> +else
>> +pr_err("%s : req->complete must not be NULL\n", __func__);
>
> let it Oops. We require ->complete to be valid, if there's any gadget
> driver not setting ->complete, it deserves to oops so we can the
> error.

The Oops was there before, but I removed it because greg k-h didn't want
it. See http://marc.info/?l=linux-usb=140917381611947=2. Do you
still want the oops here?

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

Re: [PATCH 1/2] dmaengine: Add QCOM ADM DMA driver

[Vinod Koul]

On Tue, Sep 23, 2014 at 05:10:02PM -0500, Andy Gross wrote:
> 
> 
> > > + break;
> > > + default:
> > > + achan->slave.src_maxburst = 0;
> > > + achan->slave.dst_maxburst = 0;
> > Why clear these for error cases
> 
> With the return I shouldn't need to.  I'll fix this.
> 
> > > + ret = -EINVAL;
> > > + break;
> > > + }
> > > +
> > > + if (!ret)
> > > + writel(achan->blk_size,
> > > + adev->regs + HI_CRCI_CTL(achan->id, adev->ee));
> > and why do we write to HW on this. Shouldn't this be done when you program
> > the descriptor?
> 
> It could be deferred to later.  The main point is that I don't see the
> slave_config happening every transaction.  I was only modifying it now instead
> of making a register write for every transaction.
Well wouldn't it cause a problem if you write to hardware and a transaction
is already in progress.
So it makese sense to write every time at transaction start with latest
value programmed.

> > 
> > > +static enum dma_status adm_tx_status(struct dma_chan *chan, dma_cookie_t 
> > > cookie,
> > > + struct dma_tx_state *txstate)
> > > +{
> > > + struct adm_chan *achan = to_adm_chan(chan);
> > > + struct virt_dma_desc *vd;
> > > + enum dma_status ret;
> > > + unsigned long flags;
> > > + size_t residue = 0;
> > > +
> > > + ret = dma_cookie_status(chan, cookie, txstate);
> > > +
> > Last arg can be null to this, so before you do residue calcluation and block
> > interrupts would make sense to return from here if arg is NULL
> 
> Good catch.  Will fix.
> 
> > 
> > > + spin_lock_irqsave(>vc.lock, flags);
> > > +
> > > + vd = vchan_find_desc(>vc, cookie);
> > > + if (vd)
> > > + residue = container_of(vd, struct adm_async_desc, vd)->length;
> > > + else if (achan->curr_txd && achan->curr_txd->vd.tx.cookie == cookie)
> > > + residue = achan->curr_txd->length;
> > so this is current cookie, so you need to read from HW on current position
> 
> There is no way to get current position unfortunately without relying on
> unreliable debug registers.
In that case would it make sense to return complete txn length?

-- 
~Vinod
--
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: [lxc-devel] device namespaces

[Eric W. Biederman]

riya khanna  writes:

> (Please pardon multiple emails, artifact of merging all separate 
> conversations)
>
> Thanks for your feedback! 
>
> Letting the kernel know about what devices a container could access (based on
> device cgroups) and having devtmpfs in the kernel create device nodes for a
> container that map to corresponding CUSE nodes is what I thought of. For
> example, "echo 29:0 > /proc//devices" would prepare a virtual framebuffer
> (based on real fb0 SCREENINFO properties) for this process provided 
> permissions
> allow this operation. To view the framebuffer, the CUSE based virtual device
> would talk to the actual hardware. Since namespaces would have different view 
> of
> the underlying devices, "sysfs" has to made aware of this as well. 
>
> Please let me know your inputs. Thanks again!

The solution hugely depends on what you are trying to do with it.

The situation today is that device nodes are slowly fading out.  In
another 20 years linux may not have any device nodes at all.

Therefore the question becomes what are you trying to support.

If it is just filtering of existing device nodes.  We can do a pretty
good approximation with bind mounts.

If you want to emulate a device you can use normal fuse (not cuse).
As normal fuse file will support arbitrary ioctls.

There are a few cases where it is desirable to emulate what devpts
does for allowing arbitrary users to creating virtual devices in the
kernel.  Loop devices in particular.

Ultimately given the existence of device hotplug I don't see any call
for being able to create device nodes with well known device numbers
(fundamentally what a device namespace would be about).

The conversation last year was about people wanting to multiplex devices
that don't have multiplexer support in the kernel.  If that is your
desire I think it is entirely reasonable to device type by device type
add support for multiplexing that device type to the kernel, or
potentially just use fuse or cuse to implement your multiplexer in
userspace but that has the potential to be unusably slow.

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/

Re: [PATCH linux-next] Documentation: mic: mpssd: Disable mpssd builds for kernels < 3.13

[Andrew Morton]

On Tue, 23 Sep 2014 21:51:09 -0700 ashutosh dixit  
wrote:

> On Tue, Sep 23 2014 at 05:58:19 PM, Peter Foley  wrote:
> > On Tue, Sep 23, 2014 at 8:51 PM, Andrew Morton
> >  wrote:
> >> Can't we just fix the Makefiles?  Cook up a rule which makes
> >> headers_install (if needed) before building Documentation/?
> >
> > Currently, the ordering is enforced by
> > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Makefile#n946
> > I'll take a look at making Documentation/ depend on headers_install.
> >
> I would think it is preferable to keep the 'make headers_install' and
> 'make Documentation/' steps separate, as they currently are, so that
> only the people who need to upgrade system headers do that, rather than
> forcing people to upgrade system headers each time something in
> Documentation/ is recompiled and moreover doing that compile/install as
> root.

headers_install installs into ./usr/include and ./include.  It's local
to the kernel build tree.

--
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 linux-next] Documentation: mic: mpssd: Disable mpssd builds for kernels < 3.13

[ashutosh dixit]

On Tue, Sep 23 2014 at 05:58:19 PM, Peter Foley  wrote:
> On Tue, Sep 23, 2014 at 8:51 PM, Andrew Morton
>  wrote:
>> Can't we just fix the Makefiles?  Cook up a rule which makes
>> headers_install (if needed) before building Documentation/?
>
> Currently, the ordering is enforced by
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Makefile#n946
> I'll take a look at making Documentation/ depend on headers_install.
>
I would think it is preferable to keep the 'make headers_install' and
'make Documentation/' steps separate, as they currently are, so that
only the people who need to upgrade system headers do that, rather than
forcing people to upgrade system headers each time something in
Documentation/ is recompiled and moreover doing that compile/install as
root.
--
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 ] Remove numa_balancing sysctl dependence on CONFIG_SCHED_DEBUG

[Andi Kleen]

John Blackwood  writes:

> numa: numa_balancing sysctl scope change
>
> Make the 'numa_balancing' sysctl parameter no longer dependent upon
> CONFIG_SCHED_DEBUG so it can be used in non-debug kernels.

Looks good.
-Andi

>
> Signed-off-by: John Blackwood 
>
> Index: b/kernel/sysctl.c
> ===
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -389,6 +389,9 @@ static struct ctl_table kern_table[] = {
>   .mode   = 0644,
>   .proc_handler   = proc_dointvec,
>   },
> +#endif /* CONFIG_NUMA_BALANCING */
> +#endif /* CONFIG_SCHED_DEBUG */
> +#ifdef CONFIG_NUMA_BALANCING
>   {
>   .procname   = "numa_balancing",
>   .data   = NULL, /* filled in by handler */
> @@ -399,7 +402,6 @@ static struct ctl_table kern_table[] = {
>   .extra2 = ,
>   },
>  #endif /* CONFIG_NUMA_BALANCING */
> -#endif /* CONFIG_SCHED_DEBUG */
>   {
>   .procname   = "sched_rt_period_us",
>   .data   = _sched_rt_period,

-- 
a...@linux.intel.com -- Speaking for myself only
--
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] Export functions from pcie-designware

[Mohit KUMAR DCG]

Hello Bjorn,

> -Original Message-
> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> Sent: Friday, September 19, 2014 10:46 AM
> To: Mohit KUMAR DCG
> Cc: Fabio Estevam; mat...@sai.msu.ru; Jingoo Han; linux-
> p...@vger.kernel.org; linux-kernel; matwey.korni...@gmail.com
> Subject: Re: [PATCH] Export functions from pcie-designware
> 
> On Tue, Sep 16, 2014 at 10:11:22PM -0700, Bjorn Helgaas wrote:
> > On Tue, Sep 16, 2014 at 9:54 PM, Mohit KUMAR DCG
>  wrote:
> > > Hello Bjorn,
> > >
> > >> -Original Message-
> > >> From: Bjorn Helgaas [mailto:bhelg...@google.com]
> > >> Sent: Wednesday, September 17, 2014 5:09 AM
> > >> To: Fabio Estevam
> > >> Cc: mat...@sai.msu.ru; Mohit KUMAR DCG; Jingoo Han; linux-
> > >> p...@vger.kernel.org; linux-kernel; matwey.korni...@gmail.com
> > >> Subject: Re: [PATCH] Export functions from pcie-designware
> > >>
> > >> On Sat, Aug 30, 2014 at 10:07:30AM -0300, Fabio Estevam wrote:
> > >> > On Sat, Aug 30, 2014 at 9:24 AM,   wrote:
> > >> > > From: "Matwey V. Kornilov" 
> > >> > >
> > >> > > pcie-spear13xx when built as module requires the functions from
> > >> > > pcie-
> > >> designware.
> > >> > > Export them properly.
> > >>
> > >> I don't know how valuable pcie-spear13xx as a module is.  No other
> > >> host drivers are supported as a module.  Maybe we should just
> > >> change pcie- spear13xx from tristate to bool?
> > >>
> > > -  Sachin's patch is already doing this:
> > > http://www.spinics.net/lists/linux-pci/msg33665.html
> > >
> > > You acknowledge it to apply for v3.17 but somehow it has been left out.
> >
> > Oops, sorry!  I was pretty sure I remembered a patch like this, but
> > somehow I deleted the branch before it got fully merged.  Anyway, I
> > re-did it.  Thanks for the reminder.
> 
> Actually, I *had* already merged it, and it's been in Linus' tree since
> 2014-09-03 15:45:48 (GMT) and appeared in v3.17-rc4:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers
> /pci/host/Kconfig?id=f16c15a0e0ea
> 
- yes, its been merged. I think Fabio was working with v3.17-rc2 or earlier.

Fabio,
Pls let us know if you still have any concern after  merging of this patch.

Thanks
Mohit

> Or am I still missing something?
> 
> Bjorn
--
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: mmotm 2014-09-22-16-57 uploaded

[Guenter Roeck]

On Tue, Sep 23, 2014 at 02:53:56PM -0700, Guenter Roeck wrote:
> 
> > Neither of these patches enables CONFIG_NET.  They just add dependencies.
> > 
> This means CONFIG_NET is now disabled in at least 31 configurations where
> it used to be enabled before (per my count), and there may be additional
> impact due to the additional changes of "select X" to "depends on X".
> 
> 3.18 is going to be interesting.
> 
Actually, turns out the changes are already in 3.17.

In case anyone is interested, here is a list of now broken configurations
(where 'broken' is defined as "CONFIG NET used to be defined, but
is not defined anymore"). No guarantee for completeness or correctness.

mips:gpr_defconfig
mips:ip27_defconfig
mips:jazz_defconfig
mips:loongson3_defconfig
mips:malta_defconfig
mips:malta_kvm_defconfig
mips:malta_kvm_guest_defconfig
mips:mtx1_defconfig
mips:nlm_xlp_defconfig
mips:nlm_xlr_defconfig
mips:rm200_defconfig
parisc:a500_defconfig
parisc:c8000_defconfig
powerpc:c2k_defconfig
powerpc:pmac32_defconfig
powerpc:ppc64_defconfig
powerpc:ppc64e_defconfig
powerpc:pseries_defconfig
powerpc:pseries_le_defconfig
s390:default_defconfig
s390:gcov_defconfig
s390:performance_defconfig
s390:zfcpdump_defconfig
sh:sdk7780_defconfig
sh:sh2007_defconfig
sparc:sparc64_defconfig

Several ia64 configurations were affected as well, but that
has already been fixed.

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

[PATCH] x86: Fix section conflict for numachip

[Andi Kleen]

From: Andi Kleen 

A variable cannot be both __read_mostly and const. This
is a meaningless combination.

Just make it only const.

This fixes the LTO build with numachip enabled.

Signed-off-by: Andi Kleen 
---
 arch/x86/kernel/apic/apic_numachip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic_numachip.c 
b/arch/x86/kernel/apic/apic_numachip.c
index a5b45df..2f8be54 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -32,7 +32,7 @@
 
 static int numachip_system __read_mostly;
 
-static const struct apic apic_numachip __read_mostly;
+static const struct apic apic_numachip;
 
 static unsigned int get_apic_id(unsigned long x)
 {
-- 
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: [PATCH v7 0/3] Qualcomm Resource Power Manager driver

[Bjorn Andersson]

On Tue 23 Sep 01:17 PDT 2014, Srinivas Kandagatla wrote:

> Hi Bjorn,
> 
> Thankyou for the new patchset.
> 
> I got few device-tree patches for apq8064 usb, sata, phy and hdmi which 
> depend on rpm header file. It will be nice to get this functionality 
> into 3.18.
> 

We should be able to send out the dts patches separate of these.

> Do you think we should take these patches via arm-soc tree?
> 

Both Lee and Mark indicated that they will pull the parts individually. However
both of the patches depend on the header file created in patch 1, someone needs
to take both for it to work out?

Regards,
Bjorn
--
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 3/4] pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver

[Bjorn Andersson]

On Mon 15 Sep 07:44 PDT 2014, Ivan T. Ivanov wrote:

> This is the pinctrl, pinmux, pinconf and gpiolib driver for the
> Qualcomm GPIO sub-function blocks found in the PMIC chips.
> 
> Signed-off-by: Ivan T. Ivanov 

I think this looks pretty good, just some minor comments. Mostly on the future
compatibility of the Kconfig and compatible.

It's much in line with what I hacked up for pm8xxx, I was just hoping to get
something from Thomas regarding irq_read_line() before pushing it again...

> ---
>  drivers/pinctrl/qcom/Kconfig  |  12 +
>  drivers/pinctrl/qcom/Makefile |   1 +
>  drivers/pinctrl/qcom/pinctrl-spmi-pmic-gpio.c | 942 
> ++
>  3 files changed, 955 insertions(+)
>  create mode 100644 drivers/pinctrl/qcom/pinctrl-spmi-pmic-gpio.c
> 
> diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
> index d160a71..123248f 100644
> --- a/drivers/pinctrl/qcom/Kconfig
> +++ b/drivers/pinctrl/qcom/Kconfig
> @@ -39,4 +39,16 @@ config PINCTRL_MSM8X74
>   This is the pinctrl, pinmux, pinconf and gpiolib driver for the
>   Qualcomm TLMM block found in the Qualcomm 8974 platform.
> 
> +config PINCTRL_SPMI_PMIC

As SPMI is a MIPI specification for doing power management I think it's safe to
assume that this is not going to be the only "spmi pmic" pinctrl driver.
So please make this a little bit more specific by throwing in a QCOM here.

> +   tristate "Qualcomm SPMI PMIC pin controller driver"
> +   depends on GPIOLIB && OF
> +   select PINMUX
> +   select PINCONF
> +   select GENERIC_PINCONF
> +   help
> + This is the pinctrl, pinmux, pinconf and gpiolib driver for the
> + Qualcomm GPIO and MPP blocks found in the Qualcomm PMIC's chips,
> + which are using SPMI for communication with SoC. Example PMIC's
> + devices are pm8841, pm8941 and pma8084.
> +
>  endif
> diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
> index 2a02602..396130c 100644
> --- a/drivers/pinctrl/qcom/Makefile
> +++ b/drivers/pinctrl/qcom/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_PINCTRL_APQ8064)   += pinctrl-apq8064.o
>  obj-$(CONFIG_PINCTRL_IPQ8064)  += pinctrl-ipq8064.o
>  obj-$(CONFIG_PINCTRL_MSM8960)  += pinctrl-msm8960.o
>  obj-$(CONFIG_PINCTRL_MSM8X74)  += pinctrl-msm8x74.o
> +obj-$(CONFIG_PINCTRL_SPMI_PMIC)+= pinctrl-spmi-pmic-gpio.o
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-pmic-gpio.c 
> b/drivers/pinctrl/qcom/pinctrl-spmi-pmic-gpio.c
> new file mode 100644
> index 000..493f0d3
> --- /dev/null
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-pmic-gpio.c

This is fine, no need to change as we have qcom in the path...

[..]
> +
> +/**
> + * struct pmic_gpio_pad - keep current GPIO settings

Some indentation in this table would be nice.
Content look sane though.

> + * @base: Address base in SPMI device.
> + * @irq: IRQ number which this GPIO generate.
> + * @is_enabled: Set to false when GPIO should be put in high Z state.
> + * @out_value: Cached pin output value
> + * @have_buffer: Set to true if GPIO output could be configured in push-pull,
> + * open-drain or open-source mode.
> + * @output_enabled: Set to true if GPIO output logic is enabled.
> + * @input_enabled: Set to true if GPIO input buffer logic is enabled.
> + * @num_sources: Number of power-sources supported by this GPIO.
> + * @power_source: Current power-source used.
> + * @buffer_type: Push-pull, open-drain or open-source.
> + * @pullup: Constant current which flow trough GPIO output buffer.
> + * @strength: No, Low, Medium, High
> + * @function: See pmic_gpio_functions[]
> + */
> +struct pmic_gpio_pad {
> +   u16 base;
> +   int irq;
> +   bool is_enabled;
> +   bool out_value;
> +   bool have_buffer;
> +   bool output_enabled;
> +   bool input_enabled;
> +   unsigned int num_sources;
> +   unsigned int power_source;
> +   unsigned int buffer_type;
> +   unsigned int pullup;
> +   unsigned int strength;
> +   unsigned int function;
> +};
> +
[..]
> +
> +static int pmic_gpio_parse_dt_config(struct device_node *np,
> +struct pinctrl_dev *pctldev,
> +unsigned long **configs,
> +unsigned int *nconfs)
> +{
> +   struct pmic_gpio_bindings *par;
> +   unsigned long cfg;
> +   int ret, i;
> +   u32 val;
> +
> +   for (i = 0; i < ARRAY_SIZE(pmic_gpio_bindings); i++) {
> +

Empty line

> +   par = _gpio_bindings[i];
> +   ret = of_property_read_u32(np, par->property, );
> +
> +   /* property not found */
> +   if (ret == -EINVAL)
> +   continue;
> +
> +   /* use zero as default value */
> +   if (ret)
> +   val = 0;
> +
> +   dev_dbg(pctldev->dev, "found %s with value %u\n",
> +  

Re: [PATCH 1/5] rhashtable: Remove gfp_flags from insert and remove functions

[Eric W. Biederman]

Thomas Graf  writes:

> On 09/15/14 at 05:35am, Eric Dumazet wrote:
>> On Mon, 2014-09-15 at 14:18 +0200, Thomas Graf wrote:
>> > As the expansion/shrinking is moved to a worker thread, no allocations
>> > will be performed anymore.
>> > 
>> 
>> You meant : no GFP_ATOMIC allocations ?
>> 
>> I would rephrase using something like :
>> 
>> Because hash resizes are potentially time consuming, they'll be
>> performed in process context where GFP_KERNEL allocations are preferred.
>
> I meant to say no allocations in insert/remove anymore but your wording
> is even clearer. I'll update it.
>
>> > -  tbl = kzalloc(size, flags);
>> > +  tbl = kzalloc(size, GFP_KERNEL);
>> 
>> Add __GFP_NOWARN, as you fallback to vzalloc ?
>
> Good point.

It needs to be both __GFP_NOWARN and __GFP_NORETRY.

Otherwise the system will kick in the OOM killer before it falls back to
vzalloc.  Which I can't imagine anyone wanting.

Look at the history of alloc_fdmem in fs/file.c for the real world
reasoning.

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/

Re: [PATCH] i2c: rk3x: adjust the LOW divison based on characteristics of SCL

[Doug Anderson]

Addy,

On Tue, Sep 23, 2014 at 6:55 PM, Addy Ke  wrote:
> 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
> - Fast-mode plus:
>   the minimum HIGH period of the scl clock is 0.26us
>   the minimum LOW period of the scl clock is 0.5us
> - HS-mode(<1.7MHz):
>   the minimum HIGH period of the scl clock is 0.12us
>   the minimum LOW period of the scl clock is 0.32us
> - HS-mode(<3.4MHz):
>   the minimum HIGH period of the scl clock is 0.06us
>   the minimum LOW period of the scl clock is 0.16us
>
> 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 formula.
>
> Signed-off-by: Addy Ke 
> ---
>  drivers/i2c/busses/i2c-rk3x.c | 79 
> +++
>  1 file changed, 72 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 93cfc83..49d67b7 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -428,18 +428,83 @@ out:
> return IRQ_HANDLED;
>  }
>
> +static void rk3x_i2c_get_ratios(unsigned long scl_rate,
> +   unsigned long *high_ratio,
> +   unsigned long *low_ratio)
> +{
> +   /* 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
> +* - Fast-mode plus:
> +*   the minimum HIGH period of the scl clock is 0.26us
> +*   the minimum LOW period of the scl clock is 0.5us
> +* - HS-mode(<1.7MHz):
> +*   the minimum HIGH period of the scl clock is 0.12us
> +*   the minimum LOW period of the scl clock is 0.32us
> +* - HS-mode(<3.4MHz):
> +*   the minimum HIGH period of the scl clock is 0.06us
> +*   the minimum LOW period of the scl clock is 0.16us

Is the rest of the driver ready for Fast-mode plus or HS mode?  If not
then maybe leave those off?  If nothing else the commit message should
indicate that this is just being forward thinking.

> +*/
> +   if (scl_rate <= 10) {
> +   *high_ratio = 40;
> +   *low_ratio = 47;
> +   } else if (scl_rate <= 40) {
> +   *high_ratio = 6;
> +   *low_ratio = 13;
> +   } else if (scl_rate <= 100) {
> +   *high_ratio = 26;
> +   *low_ratio = 50;
> +   } else if (scl_rate <= 170) {
> +   *high_ratio = 12;
> +   *low_ratio = 32;
> +   } else {
> +   *high_ratio = 6;
> +   *low_ratio = 16;

Since it's only the ratio of high to low that matters, you can combine
the last two.  12 : 32 == 6 : 16

> +   }
> +}
> +
> +static void rk3x_i2c_calc_divs(unsigned long i2c_rate, unsigned long 
> scl_rate,
> +  unsigned long *divh, unsigned long *divl)
> +{
> +   unsigned long high_ratio, low_ratio;
> +   unsigned long ratio_sum;
> +
> +   rk3x_i2c_get_ratios(scl_rate, _ratio, _ratio);
> +   ratio_sum = high_ratio + low_ratio;
> +
> +   /* T_high = T_clk * (divh + 1) * 8
> +* T_low = T_clk * (divl + 1) * 8
> +* T_scl = T_high + T_low
> +* T_scl = 1 / scl_rate
> +* T_clk = 1 / i2c_rate
> +* T_high : T_low = high_ratio : low_ratio
> +* ratio_sum = high_ratio + low_ratio
> +*
> +* so:
> +* divh = (i2c_rate * high_ratio) / (scl_rate * ratio_sum * 8) - 1
> +* divl = (i2c_rate * low_ratio) / (scl_rate * ratio_sum * 8) - 1
> +*/
> +   *divh = DIV_ROUND_UP(i2c_rate * high_ratio, scl_rate * ratio_sum * 8);
> +   if (*divh)
> +   *divh = *divh - 1;
> +
> +   *divl = DIV_ROUND_UP(i2c_rate * low_ratio, scl_rate * ratio_sum * 8);
> +   if (*divl)
> +   *divl = *divl - 1;

When I sent you the sample formulas I purposely did it differently
than this.  Any reason you changed from my formulas?

  div_low = DIV_ROUND_UP(clk_rate * low_ratio, scl_rate * 8 * ratio_sum)
  div_high = DIV_ROUND_UP(clk_rate, scl_rate * 8) - div_low

  div_low -= 1
  if div_high:
div_high -= 1

Why did I do it that way?

* Assuming i2c_rate and the ratio is non-zero then you can assume that
DIV_ROUND_UP gives a value that is >= 1.  No need to test the result
against 0.

* (I think) you'll get a more 

RE: [RESEND][PATCHv2 1/2] procfs: show hierarchy of pid namespace

[Chen, Hanxiao]

Hi,

> -Original Message-
> From: Mateusz Guzik [mailto:mgu...@redhat.com]
> On Mon, Sep 22, 2014 at 05:53:33PM +0800, Chen Hanxiao wrote:
> > This patch will show the hierarchy of pid namespace
> > by /proc/pidns_hierarchy like:
> >
> > [root@localhost ~]#cat /proc/pidns_hierarchy
> > /proc/18060/ns/pid /proc/18102/ns/pid /proc/1534/ns/pid
> > /proc/18060/ns/pid /proc/18102/ns/pid /proc/1600/ns/pid
> > /proc/1550/ns/pid
> >
> 
> I don't really know the area, just had a quick look and the patch does
> not seem right.
> 
> > +/*
> > + *  /proc/pidns_hierarchy
> > + *  show the hierarchy of pid namespace
> > + */
> > +
> > +#define NS_HIERARCHY   "pidns_hierarchy"
> > +
> > +static LIST_HEAD(pidns_list);
> > +static LIST_HEAD(pidns_tree);
> > +static DEFINE_MUTEX(pidns_list_lock);
> > +
> > +/* list for host pid collection */
> > +struct pidns_list {
> > +   struct list_head list;
> > +   struct pid *pid;
> > +};
> > +
> > +static void free_pidns_list(struct list_head *head)
> > +{
> > +   struct pidns_list *tmp, *pos;
> > +
> > +   list_for_each_entry_safe(pos, tmp, head, list) {
> > +   list_del(>list);
> > +   kfree(pos);
> > +   }
> > +}
> > +
> > +/*
> > + * Only add init pid in different namespaces
> > + */
> > +static int
> > +pidns_list_really_add(struct pid *pid, struct list_head *list_head)
> > +{
> > +   struct pidns_list *tmp, *pos;
> > +
> > +   if (!is_child_reaper(pid))
> > +   return 0;
> > +
> > +   list_for_each_entry_safe(pos, tmp, list_head, list)
> > +   if (ns_of_pid(pid) == ns_of_pid(pos->pid))
> > +   return 0;
> > +
> > +   return 1;
> > +}
> > +
> > +static int
> > +pidns_list_add(struct pid *pid, struct list_head *list_head)
> > +{
> > +   struct pidns_list *ent;
> > +
> > +   ent = kmalloc(sizeof(*ent), GFP_KERNEL);
> > +   if (!ent)
> > +   return -ENOMEM;
> > +
> 
> A call from proc_pidns_list_refresh will enter with rcu read-locked.
> Is it really ok to sleep in such case?
> 

The flag should be GFP_ATOMIC.

> > +   ent->pid = pid;
> > +   if (pidns_list_really_add(pid, list_head))
> > +   list_add_tail(>list, list_head);
> > +
> 
> Does not this leak memory if pidns_list_really_add returns 0?
> 
Will fix.

> Also, you just add stuff to the list and don't ref it in any way, so for
> instance in proc_pidns_list_refresh below...

I add stuffs to list called 'pidns_list',
then screen them to form a new list called 'pidns_tree'.

> 
> > +static void
> > +pidns_list_filter(void)
> > +{
> > +   struct pidns_list *tmp, *pos;
> > +   struct pidns_list *tmp_t, *pos_t;
> > +   struct pid_namespace *ns0, *ns1;
> > +   struct pid *pid0, *pid1;
> > +   int flag = 0;
> > +
> > +   /* screen pid with relationship
> > +* in pidns_list, we may add pids like
> > +* ns0   ns1   ns2
> > +* pid1->pid2->pid3
> > +* we should keep pid3 and screen pid1, pid2
> > +*/
> > +   list_for_each_entry_safe(pos, tmp, _list, list) {
> > +   list_for_each_entry_safe(pos_t, tmp_t, _list, list) {
> 
> At this point maybe it would be beneficial to have a list of children
> namespaces in pid_namespace?

pid_namespace don't have such member to identify who is its children.
It only knew who is its parent.
So I had to use a double loop to check
whether one pid be another pid's children.

> 
> > +   flag = 0;
> > +   pid0 = pos->pid;
> > +   pid1 = pos_t->pid;
> > +   ns0 = pid0->numbers[pid0->level].ns;
> > +   ns1 = pid1->numbers[pid1->level].ns;
> > +   if (pos->pid->level < pos_t->pid->level)
> > +   for (; ns1 != NULL; ns1 = ns1->parent)
> > +   if (ns0 == ns1) {
> > +   flag = 1;
> > +   break;
> > +   }
> > +   if (flag == 1)
> > +   break;
> > +   }
> > +
> > +   if (flag == 0)
> > +   pidns_list_add(pos->pid, _tree);
> > +   }
> > +
> > +   free_pidns_list(_list);
> > +}
> > +
> 
> > +/* collect pids in pidns_list,
> > + * then remove duplicated ones,
> > + * add the rest to pidns_tree
> > + */
> > +static void proc_pidns_list_refresh(void)
> > +{
> > +   struct pid *pid;
> > +   struct task_struct *p;
> > +
> > +   /* collect pid in differet ns */
> > +   rcu_read_lock();
> > +   for_each_process(p) {
> > +   pid = task_pid(p);
> > +   if (pid && (pid->level > 0))
> > +   pidns_list_add(pid, _list);
> > +   }
> > +   rcu_read_unlock();
> > +
> > +   /* screen duplicate pids */
> > +   pidns_list_filter();
> 
> What makes it safe to traverse the list after rcu_read_unlock?

pidns_list_filter should be moved before rcu_read_unlock.

> 
> > +}
> > +
> > +static int nslist_proc_show(struct seq_file *m, void *v)
> > +{
> > +   struct pidns_list *tmp, 

RE: linux-next: build failure after merge of the samsung tree

[Kukjin Kim]

Kukjin Kim wrote:
> 
> Stephen Rothwell wrote:
> >
> > Hi Kukjin,
> >
> Hi Stephen,
> 
> > After merging the samsung tree, today's linux-next build (arm 
> > multi_v7_defconfig)
> > failed like this:
> >
> > arch/arm/boot/dts/exynos5250-snow.dts:13:46: fatal error: 
> > dt-bindings/clock/maxim,max77686.h: No
> such
> > file or directory
> >  #include 
> >   ^
> >
> + Mike
> 
> Hmm... I think, inclusion of the header file should be included in Mike's clk
> tree...What's wrong?
> 
Just note, I've merged Mike's clk-next into my -next tree.

> > Caused by commit c04c92ed5614 ("ARM: dts: Add rtc_src clk for s3c-rtc on 
> > exynos5250-snow").
> >
> > In file included from arch/arm/mach-tegra/cpuidle-tegra114.c:17:0:
> > arch/arm/mach-tegra/cpuidle-tegra114.c: In function 
> > 'tegra114_idle_power_down':
> > arch/arm/include/asm/firmware.h:64:24: error: too few arguments to function 
> > 'firmware_ops->do_idle'
> >   ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
> > ^
> > arch/arm/mach-tegra/cpuidle-tegra114.c:52:6: note: in expansion of macro 
> > 'call_firmware_op'
> >   if (call_firmware_op(do_idle) == -ENOSYS)
> >   ^
> >
> > Caused by commit f5217f3b9332 ("ARM: EXYNOS: add AFTR mode support to
> > firmware do_idle method").
> 
> OK, I'll revert it firstly. Thanks.
> 
Reverted just now.

> >
> > I have used the samsung tree from next-20140923 for today.
> 
> OK.
> 
> - Kukjin

--
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] fs, LLVMLinux: Remove warning from COMPATIBLE_IOCTL

[Behan Webster]

From: Mark Charlebois 

cmd in COMPATIBLE_IOCTL is always a u32, so cast it so there isn't a warning
about an overflow in XFORM.

Signed-off-by: Mark Charlebois 
Signed-off-by: Behan Webster 
Acked-by: Arnd Bergmann 
---
 fs/compat_ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index afec645..f6ce1aa 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -810,7 +810,7 @@ static int compat_ioctl_preallocate(struct file *file,
  */
 #define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
 
-#define COMPATIBLE_IOCTL(cmd) XFORM(cmd),
+#define COMPATIBLE_IOCTL(cmd) XFORM((u32)cmd),
 /* ioctl should not be warned about even if it's not implemented.
Valid reasons to use this:
- It is implemented with ->compat_ioctl on some device, but programs
-- 
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] arm, vt8500, LLVMLlinux: Use mcr instead of mcr% for mach-vt8500

[Behan Webster]

The ASM below does not compile with clang and is not the way that the mcr
command is used in other parts of the kernel.

arch/arm/mach-vt8500/vt8500.c:72:11: error: invalid % escape in inline assembly 
string
asm("mcr%? p15, 0, %0, c7, c0, 4" : : "r" (0));
~^~~~
1 error generated.

There are other forms that are supported on different ARM instruction sets but
generally the kernel just uses mcr as it is supported in all ARM instruction
sets.

Signed-off-by: Behan Webster 
Reviewed-by: Mark Charlebois 
Acked-by: Will Deacon 
---
 arch/arm/mach-vt8500/vt8500.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 2da7be3..3bc0dc9 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -69,7 +69,7 @@ static void vt8500_power_off(void)
 {
local_irq_disable();
writew(5, pmc_base + VT8500_HCR_REG);
-   asm("mcr%? p15, 0, %0, c7, c0, 4" : : "r" (0));
+   asm("mcr p15, 0, %0, c7, c0, 4" : : "r" (0));
 }
 
 static void __init vt8500_init(void)
-- 
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 v6 1/2] regulator: st-pwm: get voltage and duty table from dts

[Doug Anderson]

Chris,

On Tue, Sep 23, 2014 at 7:51 PM, Chris Zhong  wrote:
>
> On 09/24/2014 10:13 AM, Doug Anderson wrote:
>>
>> Chris,
>>
>> On Tue, Sep 23, 2014 at 6:47 PM, Chris Zhong  wrote:
>>>
>>> On 09/24/2014 07:43 AM, Doug Anderson wrote:

 Chris,

 On Tue, Sep 23, 2014 at 8:53 AM, Chris Zhong  wrote:
>
> Get voltage & duty table from device tree might be better, other
> platforms can also use this
> driver without any modify.
>
> Signed-off-by: Chris Zhong 
> Reviewed-by: Doug Anderson 

 I finally managed to get everything setup and I've now tested this
 myself on an rk3288-based board.

 Tested-by: Doug Anderson 

 I'd imagine the next step is for Lee to comment on the patch and when
 he's happy with it Mark Brown will land it?


 One thing that's still a bit odd (though no different than the
 behavior of the driver from before you touched it, so it shouldn't
 block landing IMHO) is that at boot time this regulator will report
 that it's at the highest voltage but the voltage won't actually change
 until the first client sets the voltage.
>>>
>>> Yes, I knew this problem, since the default of duty cycle is 0, not a
>>> true
>>> value.
>>> If we can get duty from pwm, this regulator will report a correct
>>> voltage.
>>
>> I don't think it's possible in all cases to figure out what the
>> voltage was before this regulator was probed.
>>
>> * pin might have been input w/ pullup, pulldown, or no pull
>> * pin might have been driven high or driven low
>>
>> In that case trying to read the duty from the pwm wouldn't make sense.
>> ...but I guess you could add a property to the PWM driver to say that
>> it stays enabled at boot if the FW left it enabled (and keep the same
>> duty cycle / clocks?).  That would at least solve the problem where
>> the firmware configured the PWM and left it in a specific state even
>> if it doesn't solve the above problem...
>>
>>
>> -Doug
>>
> If we want pwm stay enabled at boot(FW left it), needn't to modify anything,
> only need to init pwm duty in FW.
> And now reading the duty from pwm would make sense.

Maybe I'll understand better if you send up some patches.  I would
have thought that when the PWM initializes it would start out disabled
and there wouldn't be an easy way to convince the PWM subsystem to
keep it enabled.  ...I also would have thought that the default
behavior of a PWM on Linux would be to disable it in the driver probe
if firmware happened to have left it on.

I could be wrong on both counts, though.

-Doug
--
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] [media] videobuf-dma-contig: replace vm_iomap_memory() with remap_pfn_range().

[chen.f...@freescale.com]

Thanks a lot, Hans.
 
I know the reason that you use vm_iomap_memory() instead of remap_pfn_range(). 
But
according to my analysis, the sanity check is not suitable for v4l2 buffers 
mapping. You can check the
code logic to see this. 

Migration to vb2 is not a quick job and it is not on our schedule yet.
I just need you to check the code logic and make a decision for this.

Best regards,
Fancy Fang


-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl] 
Sent: Tuesday, September 23, 2014 2:10 PM
To: Fang Chen-B47543; m.che...@samsung.com; v...@zeniv.linux.org.uk
Cc: Guo Shawn-R65073; linux-me...@vger.kernel.org; 
linux-kernel@vger.kernel.org; Marek Szyprowski
Subject: Re: [PATCH] [media] videobuf-dma-contig: replace vm_iomap_memory() 
with remap_pfn_range().

Hi Fancy Fang,

I do have a few comments:

1) One reason why the switch to vm_iomap_memory() was made originally was that 
that function did a bunch of sanity checks. Since this patch moves back to
remap_pfn_range() those sanity checks are lost and should be reinstated.

2) You need Marek's Ack as well since he understands the memory code much 
better than I do.

3) There are efforts underway to make a modern i.mx6 video driver based on
vb2 and all the other modern V4L2 APIs, wouldn't it be much better if freescale 
jumps on board and starts working on that code as well? See e.g. this mail
thread: http://www.spinics.net/lists/linux-media/msg79078.html

I assume this refers to the same hardware. The official freescale driver for 
that hardware is horrendous.

If you are writing code for unrelated hardware, then you should move over to
vb2 yourself. videobuf should not be used anymore for new drivers.

4) I still do not entirely understand the control flow and I will have to take 
another look. I'll see if I can do that tomorrow.

Regards,

Hans

On 09/23/2014 05:11 AM, chen.f...@freescale.com wrote:
> Hans,
> Do you have any more comment on this patch?
> 
> Best regards,
> Fancy Fang
> 
> -Original Message-
> From: Fang Chen-B47543
> Sent: Wednesday, September 10, 2014 3:29 PM
> To: 'Hans Verkuil'; m.che...@samsung.com; v...@zeniv.linux.org.uk
> Cc: Guo Shawn-R65073; linux-me...@vger.kernel.org; 
> linux-kernel@vger.kernel.org; Marek Szyprowski
> Subject: RE: [PATCH] [media] videobuf-dma-contig: replace vm_iomap_memory() 
> with remap_pfn_range().
> 
> On the Freescale imx6 platform which belongs to ARM architecture. The driver 
> is our local v4l2 output driver which is not upstream yet unfortunately.
> 
> Best regards,
> Fancy Fang
> 
> -Original Message-
> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
> Sent: Wednesday, September 10, 2014 3:21 PM
> To: Fang Chen-B47543; m.che...@samsung.com; v...@zeniv.linux.org.uk
> Cc: Guo Shawn-R65073; linux-me...@vger.kernel.org; 
> linux-kernel@vger.kernel.org; Marek Szyprowski
> Subject: Re: [PATCH] [media] videobuf-dma-contig: replace vm_iomap_memory() 
> with remap_pfn_range().
> 
> On 09/10/14 09:14, chen.f...@freescale.com wrote:
>> It is not a theoretically issue, it is a real case that the mapping failed 
>> issue happens in 3.14.y kernel but not happens in previous 3.10.y kernel.
>> So I need your confirmation on it.
> 
> With which driver does this happen? On which architecture?
> 
> Regards,
> 
>   Hans
> 
>>
>> Thanks.
>>
>> Best regards,
>> Fancy Fang
>>
>> -Original Message-
>> From: Hans Verkuil [mailto:hverk...@xs4all.nl]
>> Sent: Wednesday, September 10, 2014 3:01 PM
>> To: Fang Chen-B47543; m.che...@samsung.com; v...@zeniv.linux.org.uk
>> Cc: Guo Shawn-R65073; linux-me...@vger.kernel.org; 
>> linux-kernel@vger.kernel.org; Marek Szyprowski
>> Subject: Re: [PATCH] [media] videobuf-dma-contig: replace vm_iomap_memory() 
>> with remap_pfn_range().
>>
>> On 09/10/14 07:28, Fancy Fang wrote:
>>> When user requests V4L2_MEMORY_MMAP type buffers, the videobuf-core 
>>> will assign the corresponding offset to the 'boff' field of the 
>>> videobuf_buffer for each requested buffer sequentially. Later, user 
>>> may call mmap() to map one or all of the buffers with the 'offset'
>>> parameter which is equal to its 'boff' value. Obviously, the 'offset'
>>> value is only used to find the matched buffer instead of to be the 
>>> real offset from the buffer's physical start address as used by 
>>> vm_iomap_memory(). So, in some case that if the offset is not zero,
>>> vm_iomap_memory() will fail.
>>
>> Is this just a fix for something that can fail theoretically, or do you 
>> actually have a case where this happens? I am very reluctant to make any 
>> changes to videobuf. Drivers should all migrate to vb2.
>>
>> I have CC-ed Marek as well since he knows a lot more about this stuff than I 
>> do.
>>
>> Regards,
>>
>>  Hans
>>
>>>
>>> Signed-off-by: Fancy Fang 
>>> ---
>>>  drivers/media/v4l2-core/videobuf-dma-contig.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
>>> 

Re: [PATCH v2 1/2] cap1106: Add support for various cap11xx devices

[Matt Ranostay]

On Mon, Sep 22, 2014 at 11:46 PM, Daniel Mack  wrote:
> On 09/23/2014 06:04 AM, Matt Ranostay wrote:
>> diff --git a/drivers/input/keyboard/cap1106.c 
>> b/drivers/input/keyboard/cap1106.c
>> index d70b65a..07f9e88 100644
>> --- a/drivers/input/keyboard/cap1106.c
>> +++ b/drivers/input/keyboard/cap1106.c
>> @@ -55,8 +55,6 @@
>>  #define CAP1106_REG_MANUFACTURER_ID  0xfe
>>  #define CAP1106_REG_REVISION 0xff
>>
>> -#define CAP1106_NUM_CHN 6
>> -#define CAP1106_PRODUCT_ID   0x55
>>  #define CAP1106_MANUFACTURER_ID  0x5d
>>
>>  struct cap1106_priv {
>> @@ -64,7 +62,25 @@ struct cap1106_priv {
>>   struct input_dev *idev;
>>
>>   /* config */
>> - unsigned short keycodes[CAP1106_NUM_CHN];
>> + u32 *keycodes;
>> + unsigned int num_channels;
>> +};
>> +
>> +struct cap11xx_hw_model {
>> + uint8_t product_id;
>> + unsigned int num_channels;
>> +};
>> +
>> +enum {
>> + CAP1106,
>> + CAP1126,
>> + CAP1188,
>> +};
>> +
>> +struct cap11xx_hw_model cap11xx_devices[] = {
>
> This can be static const.
>
D'oh how did I miss that?

> And, as I said, there should be a 3rd patch that renames the file and
> its functions, structs, defines etc to the more generic "11xx" variants.
>

Ok will do and resubmit.

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

Re: FIX Me in pgtable.h

[Laura Abbott]

On 9/23/2014 6:04 AM, nick wrote:

Greetings Arm Maintainers,
I am wondering about the fix me in pgtable.h for define kern_addr_valid and how 
to set it to a correct
value as you state that this needs to be fixed as the defined macro is still 1. 
This is probably incorrect
and should be changed.
Thanks,
Nick



It's not clear to me how valuable fixing kern_addr_valid would actually
be for arm. It seems to be used in exactly one place, fs/proc/kcore.c
and the associated Kconfig is explicitly marked if !ARM. Nearly all
other archs minus x86, arm64 and sparc are in the same boat as well.

Thanks,
Laura

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

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

Re: [PATCH v3 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should be atomic flags

[Zefan Li]

于 2014/9/24 6:10, David Rientjes wrote:
> On Tue, 23 Sep 2014, Zefan Li wrote:
> 
>> When we change cpuset.memory_spread_{page,slab}, cpuset will flip
>> PF_SPREAD_{PAGE,SLAB} bit of tsk->flags for each task in that cpuset.
>> This should be done using atomic bitops, but currently we don't,
>> which is broken.
>>
>> Tetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happend
>> when one thread tried to clear PF_USED_MATH while at the same time another
>> thread tried to flip PF_SPREAD_PAGE/PF_SPREAD_SLAB. They both operate on
>> the same task.
>>
>> Here's the full report:
>> https://lkml.org/lkml/2014/9/19/230
>>
>> To fix this, we make PF_SPREAD_PAGE and PF_SPARED_SLAB atomic flags.
>>
> 
> s/SPARED/SPREAD/
> 
>> Cc: Peter Zijlstra 
>> Cc: Ingo Molnar 
>> Cc: Miao Xie 
>> Cc: Kees Cook 
>> Fixes: 950592f7b991 ("cpusets: update tasks' page/slab spread flags in time")
>> Cc:  # 2.6.31+
>> Reported-by: Tetsuo Handa 
>> Signed-off-by: Zefan Li 
>> ---
>>  include/linux/cpuset.h |  4 ++--
>>  include/linux/sched.h  | 13 +++--
>>  kernel/cpuset.c|  9 +
>>  3 files changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
>> index 0d4e067..2f073db 100644
>> --- a/include/linux/cpuset.h
>> +++ b/include/linux/cpuset.h
>> @@ -94,12 +94,12 @@ extern int cpuset_slab_spread_node(void);
>>  
>>  static inline int cpuset_do_page_mem_spread(void)
>>  {
>> -return current->flags & PF_SPREAD_PAGE;
>> +return task_spread_page(current);
>>  }
>>  
>>  static inline int cpuset_do_slab_mem_spread(void)
>>  {
>> -return current->flags & PF_SPREAD_SLAB;
>> +return task_spread_slab(current);
>>  }
>>  
>>  extern int current_cpuset_is_being_rebound(void);
>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>> index 5630763..7b1cafe 100644
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1903,8 +1903,6 @@ extern void thread_group_cputime_adjusted(struct 
>> task_struct *p, cputime_t *ut,
>>  #define PF_KTHREAD  0x0020  /* I am a kernel thread */
>>  #define PF_RANDOMIZE0x0040  /* randomize virtual address 
>> space */
>>  #define PF_SWAPWRITE0x0080  /* Allowed to write to swap */
>> -#define PF_SPREAD_PAGE  0x0100  /* Spread page cache over 
>> cpuset */
>> -#define PF_SPREAD_SLAB  0x0200  /* Spread some slab caches over 
>> cpuset */
>>  #define PF_NO_SETAFFINITY 0x0400/* Userland is not allowed to 
>> meddle with cpus_allowed */
>>  #define PF_MCE_EARLY0x0800  /* Early kill for mce process 
>> policy */
>>  #define PF_MUTEX_TESTER 0x2000  /* Thread belongs to the rt 
>> mutex tester */
>> @@ -1958,6 +1956,9 @@ static inline void memalloc_noio_restore(unsigned int 
>> flags)
>>  
>>  /* Per-process atomic flags. */
>>  #define PFA_NO_NEW_PRIVS 0  /* May not gain new privileges. */
>> +#define PFA_SPREAD_PAGE  1  /* Spread page cache over cpuset */
>> +#define PFA_SPREAD_SLAB  2  /* Spread some slab caches over cpuset */
>> +
>>  
>>  #define TASK_PFA_TEST(name, func)   \
>>  static inline bool task_##func(struct task_struct *p)   \
>> @@ -1972,6 +1973,14 @@ static inline void memalloc_noio_restore(unsigned int 
>> flags)
>>  TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
>>  TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)
>>  
>> +TASK_PFA_TEST(SPREAD_PAGE, spread_page)
>> +TASK_PFA_SET(SPREAD_PAGE, spread_page)
>> +TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)
>> +
>> +TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
>> +TASK_PFA_SET(SPREAD_SLAB, spread_slab)
>> +TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)
>> +
>>  /*
>>   * task->jobctl flags
>>   */
>> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
>> index a37f4ed..1f107c7 100644
>> --- a/kernel/cpuset.c
>> +++ b/kernel/cpuset.c
>> @@ -365,13 +365,14 @@ static void cpuset_update_task_spread_flag(struct 
>> cpuset *cs,
>>  struct task_struct *tsk)
>>  {
>>  if (is_spread_page(cs))
>> -tsk->flags |= PF_SPREAD_PAGE;
>> +task_set_spread_page(tsk);
>>  else
>> -tsk->flags &= ~PF_SPREAD_PAGE;
>> +task_clear_spread_page(tsk);
>> +
>>  if (is_spread_slab(cs))
>> -tsk->flags |= PF_SPREAD_SLAB;
>> +task_set_spread_slab(tsk);
>>  else
>> -tsk->flags &= ~PF_SPREAD_SLAB;
>> +task_clear_spread_slab(tsk);
>>  }
>>  
>>  /*
> 
> This most certainly needs commentary to specify why these have to be 
> atomic ops.
> .

It won't hurt to add more comment, but I don't think it's necessary, because
the reason to use atomic bitops seems obvious to me. Besides there's no such
comment for no_new_privs, which was tsk->atomic_flags introduced for.


--
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  

RE: linux-next: build failure after merge of the samsung tree

[Kukjin Kim]

Stephen Rothwell wrote:
> 
> Hi Kukjin,
> 
Hi Stephen,

> After merging the samsung tree, today's linux-next build (arm 
> multi_v7_defconfig)
> failed like this:
> 
> arch/arm/boot/dts/exynos5250-snow.dts:13:46: fatal error: 
> dt-bindings/clock/maxim,max77686.h: No such
> file or directory
>  #include 
>   ^
> 
+ Mike

Hmm... I think, inclusion of the header file should be included in Mike's clk
tree...What's wrong?

> Caused by commit c04c92ed5614 ("ARM: dts: Add rtc_src clk for s3c-rtc on 
> exynos5250-snow").
> 
> In file included from arch/arm/mach-tegra/cpuidle-tegra114.c:17:0:
> arch/arm/mach-tegra/cpuidle-tegra114.c: In function 
> 'tegra114_idle_power_down':
> arch/arm/include/asm/firmware.h:64:24: error: too few arguments to function 
> 'firmware_ops->do_idle'
>   ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
> ^
> arch/arm/mach-tegra/cpuidle-tegra114.c:52:6: note: in expansion of macro 
> 'call_firmware_op'
>   if (call_firmware_op(do_idle) == -ENOSYS)
>   ^
> 
> Caused by commit f5217f3b9332 ("ARM: EXYNOS: add AFTR mode support to
> firmware do_idle method").

OK, I'll revert it firstly. Thanks.

> 
> I have used the samsung tree from next-20140923 for today.

OK.

- Kukjin

--
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 3/3] cpuset: PF_SPREAD_PAGE and PF_SPREAD_SLAB should beatomic flags

[Zefan Li]

On 2014/9/23 18:55, Tetsuo Handa wrote:
> Zefan Li wrote:
>> Tetsuo reported a hard-to-reproduce kernel crash on RHEL6, which happend
> 
> s/happend/happened/
> 
>> @@ -1972,6 +1973,14 @@ static inline void memalloc_noio_restore(unsigned int 
>> flags)
>>  TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
>>  TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)
>>  
>> +TASK_PFA_TEST(SPREAD_PAGE, spread_page)
>> +TASK_PFA_SET(SPREAD_PAGE, spread_page)
>> +TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)
>> +
>> +TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
>> +TASK_PFA_SET(SPREAD_SLAB, spread_slab)
>> +TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)
>> +
> 
> I wonder how adding 3 macro lines differs from 3 inlined functions.
> Personally, from LXR (source code browser) point of view, inlined functions
> are more friendly than macros. Also, I wonder about the cost of extracting
> macros in a file which is likely included by every file but referenced
> by few files. Speak of SPREAD_PAGE and SPREAD_SLAB, they should be defined
> as inlined functions in include/linux/cpuset.h rather than as macros in
> include/linux/sched.h ?
> .

Though tsk->atomic_flags were newly introduced in 3.17 merge window, we
already have 3 flags, and we may see more flags added.

Those macros make the code easier to read, and emacs and cscope can also
understand them.

I'd vote for this:

TASK_PFA_TEST(NO_NEW_PRIVS, no_new_privs)
TASK_PFA_SET(NO_NEW_PRIVS, no_new_privs)

TASK_PFA_TEST(SPREAD_PAGE, spread_page)
TASK_PFA_SET(SPREAD_PAGE, spread_page)
TASK_PFA_CLEAR(SPREAD_PAGE, spread_page)

TASK_PFA_TEST(SPREAD_SLAB, spread_slab)
TASK_PFA_SET(SPREAD_SLAB, spread_slab)
TASK_PFA_CLEAR(SPREAD_SLAB, spread_slab)

over this:

static inline bool task_no_new_privs(struct task_struct *p)
{
return test_bit(PFA_NO_NEW_PRIVS, >atomic_flags);
}
static inline void task_set_new_privs(struct task_struct *p)
{
set_bit(PFA_NO_NEW_PRIVS, >atomic_flags);
}

static inline bool task_spread_page(struct task_struct *p)
{
return test_bit(PFA_SPREAD_PAGE, >atomic_flags);
}
static inline void task_set_spread_page(struct task_struct *p)
{
set_bit(PFA_SPREAD_PAGE, >atomic_flags);
}
static inline void task_clear_spread_page(struct task_struct *p)
{
clear_bit(PFA_SPREAD_PAGE, >atomic_flags);
}

static inline bool task_spread_slab(struct task_struct *p)
{
return test_bit(PFA_SPREAD_SLAB, >atomic_flags);
}
static inline void task_set_spread_slab(struct task_struct *p)
{
set_bit(PFA_SPREAD_SLAB, >atomic_flags);
}
static inline void task_clear_spread_slab(struct task_struct *p)
{
clear_bit(PFA_SPREAD_SLAB, >atomic_flags);
}


--
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] ftracetest: Add a couple of ftrace test cases

[Masami Hiramatsu]

(2014/09/24 6:38), Steven Rostedt wrote:
> 
> [
>   Masami, I took two of my test scripts and added some basic comments

Thanks!

>   to them and copied them pretty much unchanged into a ftrace directory
>   under test.d. Is this fine, or is there more massaging I need to do
>   to them?

Yeah, ftrace has a double meaning :), so test.d/ftrace is fine to me.

> 
>   I know the echos don't show up, but I kept them anyway. What should
>   happen with them?

I think you'd better use exit_unsupported/exit_xfail to notify
that the test target is not configured, or expected to fail.
Then the user can reconfigure that. Maybe we should keep the
detailed log of such results. (you can do it with --keep option)

> ]
> 
> Added two test cases to get the feel of adding tests to ftracetest.
> The two cases are:
> 
>   function profiling test, to make sure function profiling still works
>with function tracing (was a regression)
> 
>   function graph filter test to make sure that the function graph filter
>does filter and also continues to filter when another function tracer
>is running (like the stack tracer)
> 
> Signed-off-by: Steven Rostedt 
> ---
>  .../ftrace/test.d/ftrace/fgraph-filter.tc  | 111 
> +
>  .../ftrace/test.d/ftrace/func_profiler.tc  |  78 +++
>  2 files changed, 189 insertions(+)
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc
> 
> diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc 
> b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
> new file mode 100644
> index ..42f764d1f8d2
> --- /dev/null
> +++ b/tools/testing/selftests/ftrace/test.d/ftrace/fgraph-filter.tc
> @@ -0,0 +1,111 @@
> +#!/bin/sh
> +# description: ftrace - function graph filters
> +
> +# Make sure that function graph filtering works, and is not
> +# affected by other tracers enabled (like stack tracer)
> +
> +if ! grep -q function_graph available_tracers; then
> +echo "no function graph tracer configured"
> +exit 0;

This should call exit_unsupported, because the test is not passed.

> +fi
> +
> +if [ ! -f set_ftrace_filter ]; then
> +echo "set_ftrace_filter not found? Is dynamic ftrace not set?"
> +exit 0

Ditto.

> +fi
> +
> +do_reset() {
> +echo nop > current_tracer
> +echo 0 > /proc/sys/kernel/stack_tracer_enabled
> +echo 1 > tracing_on
> +echo > trace
> +echo > set_ftrace_filter
> +}
> +
> +echo 0 > tracing_on
> +# clear trace
> +echo > trace
> +# filter something, schedule is always good
> +if ! echo "schedule" > set_ftrace_filter; then
> +# test for powerpc 64
> +if ! echo ".schedule" > set_ftrace_filter; then
> + echo "can not enable schedule filter"
> + exit -1
> +fi
> +fi
> +
> +echo function_graph > current_tracer
> +echo 1 > tracing_on
> +sleep 1
> +# search for functions (has "()" on the line), and make sure
> +# that only the schedule function was found
> +count=`cat trace | grep '()' | grep -v schedule | wc -l`
> +if [ $count -ne 0 ]; then
> +echo "Graph filtering not working by itself?"
> +exit -1;
> +fi
> +
> +# Make sure we did find something
> +count=`cat trace | grep 'schedule()' | wc -l` 
> +if [ $count -eq 0 ]; then
> +echo "No schedule traces found?"
> +exit -1
> +fi
> +
> +echo "Graph filtering works by itself"
> +

I think the following part should be a separated test for
stack trace.

> +if [ ! -f stack_trace ]; then
> +echo "Stack tracer not configured, can't continue test"
> +# stack tracer not configured in this kernel? pass test anyway
> +do_reset
> +exit 0;

Here should call exit_unsupported.

> +fi
> +
> +echo "Now testing with stack tracer"
> +
> +echo 1 > /proc/sys/kernel/stack_tracer_enabled
> +
> +echo 0 > tracing_on
> +echo > trace
> +echo 1 > tracing_on
> +sleep 1
> +
> +count=`cat trace | grep '()' | grep -v schedule | wc -l`
> +
> +if [ $count -ne 0 ]; then
> +echo "Graph filtering not working with stack tracer?"
> +exit -1
> +fi
> +
> +count=`cat trace | grep 'schedule()' | wc -l` 
> +if [ $count -eq 0 ]; then
> +echo "No schedule traces found?"
> +exit -1
> +fi
> +
> +echo "Graph filtering works with stack tracer"
> +
> +echo "Now testing if filtering still works without stack tracer"
> +
> +echo 0 > /proc/sys/kernel/stack_tracer_enabled
> +echo > trace
> +sleep 1
> +
> +
> +count=`cat trace | grep '()' | grep -v schedule | wc -l`
> +
> +if [ $count -ne 0 ]; then
> +echo "Graph filtering not working after stack tracer disabled?"
> +exit -1
> +fi
> +
> +count=`cat trace | grep 'schedule()' | wc -l` 
> +if [ $count -eq 0 ]; then
> +echo "No schedule traces found?"
> +exit -1
> +fi
> +
> +do_reset
> +
> +echo "SUCCESS!"
> +exit 0
> diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc 
> 

Re: [PATCH v1 2/5] mm: add full variable in swap_info_struct

[Dan Streetman]

On Sun, Sep 21, 2014 at 8:03 PM, Minchan Kim  wrote:
> Now, swap leans on !p->highest_bit to indicate a swap is full.
> It works well for normal swap because every slot on swap device
> is used up when the swap is full but in case of zram, swap sees
> still many empty slot although backed device(ie, zram) is full
> since zram's limit is over so that it could make trouble when
> swap use highest_bit to select new slot via free_cluster.
>
> This patch introduces full varaiable in swap_info_struct
> to solve the problem.
>
> Suggested-by: Dan Streetman 
> Signed-off-by: Minchan Kim 
> ---
>  include/linux/swap.h |  1 +
>  mm/swapfile.c| 33 +++--
>  2 files changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index ea4f926e6b9b..a3c11c051495 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -224,6 +224,7 @@ struct swap_info_struct {
> struct swap_cluster_info free_cluster_tail; /* free cluster list tail 
> */
> unsigned int lowest_bit;/* index of first free in swap_map */
> unsigned int highest_bit;   /* index of last free in swap_map */
> +   boolfull;   /* whether swap is full or not */
> unsigned int pages; /* total of usable pages of swap */
> unsigned int inuse_pages;   /* number of those currently in use */
> unsigned int cluster_next;  /* likely index for next allocation */
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index c07f7f4912e9..209112cf8b83 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -558,7 +558,7 @@ checks:
> }
> if (!(si->flags & SWP_WRITEOK))
> goto no_page;
> -   if (!si->highest_bit)
> +   if (si->full)
> goto no_page;
> if (offset > si->highest_bit)
> scan_base = offset = si->lowest_bit;
> @@ -589,6 +589,7 @@ checks:
> spin_lock(_avail_lock);
> plist_del(>avail_list, _avail_head);
> spin_unlock(_avail_lock);
> +   si->full = true;
> }
> si->swap_map[offset] = usage;
> inc_cluster_info_page(si, si->cluster_info, offset);
> @@ -653,14 +654,14 @@ start_over:
> plist_requeue(>avail_list, _avail_head);
> spin_unlock(_avail_lock);
> spin_lock(>lock);
> -   if (!si->highest_bit || !(si->flags & SWP_WRITEOK)) {
> +   if (si->full || !(si->flags & SWP_WRITEOK)) {
> spin_lock(_avail_lock);
> if (plist_node_empty(>avail_list)) {
> spin_unlock(>lock);
> goto nextsi;
> }
> -   WARN(!si->highest_bit,
> -"swap_info %d in list but !highest_bit\n",
> +   WARN(si->full,
> +"swap_info %d in list but swap is full\n",
>  si->type);
> WARN(!(si->flags & SWP_WRITEOK),
>  "swap_info %d in list but !SWP_WRITEOK\n",
> @@ -796,21 +797,25 @@ static unsigned char swap_entry_free(struct 
> swap_info_struct *p,
>
> /* free if no reference */
> if (!usage) {
> +   bool was_full;
> +
> dec_cluster_info_page(p, p->cluster_info, offset);
> if (offset < p->lowest_bit)
> p->lowest_bit = offset;
> -   if (offset > p->highest_bit) {
> -   bool was_full = !p->highest_bit;
> +   if (offset > p->highest_bit)
> p->highest_bit = offset;
> -   if (was_full && (p->flags & SWP_WRITEOK)) {
> -   spin_lock(_avail_lock);
> -   WARN_ON(!plist_node_empty(>avail_list));
> -   if (plist_node_empty(>avail_list))
> -   plist_add(>avail_list,
> - _avail_head);
> -   spin_unlock(_avail_lock);
> -   }
> +   was_full = p->full;
> +
> +   if (was_full && (p->flags & SWP_WRITEOK)) {

was_full was only needed because highest_bit was reset to offset right
before checking for fullness, so now that ->full is used instead of
!highest_bit, was_full isn't needed anymore, you can just check
p->full.


> +   spin_lock(_avail_lock);
> +   WARN_ON(!plist_node_empty(>avail_list));
> +   if (plist_node_empty(>avail_list))
> +   plist_add(>avail_list,
> + _avail_head);
> +   spin_unlock(_avail_lock);
> +   p->full = false;
> 

Re: [PATCH v6 1/2] regulator: st-pwm: get voltage and duty table from dts

[Chris Zhong]

On 09/24/2014 10:13 AM, Doug Anderson wrote:

Chris,

On Tue, Sep 23, 2014 at 6:47 PM, Chris Zhong  wrote:

On 09/24/2014 07:43 AM, Doug Anderson wrote:

Chris,

On Tue, Sep 23, 2014 at 8:53 AM, Chris Zhong  wrote:

Get voltage & duty table from device tree might be better, other
platforms can also use this
driver without any modify.

Signed-off-by: Chris Zhong 
Reviewed-by: Doug Anderson 

I finally managed to get everything setup and I've now tested this
myself on an rk3288-based board.

Tested-by: Doug Anderson 

I'd imagine the next step is for Lee to comment on the patch and when
he's happy with it Mark Brown will land it?


One thing that's still a bit odd (though no different than the
behavior of the driver from before you touched it, so it shouldn't
block landing IMHO) is that at boot time this regulator will report
that it's at the highest voltage but the voltage won't actually change
until the first client sets the voltage.

Yes, I knew this problem, since the default of duty cycle is 0, not a true
value.
If we can get duty from pwm, this regulator will report a correct voltage.

I don't think it's possible in all cases to figure out what the
voltage was before this regulator was probed.

* pin might have been input w/ pullup, pulldown, or no pull
* pin might have been driven high or driven low

In that case trying to read the duty from the pwm wouldn't make sense.
...but I guess you could add a property to the PWM driver to say that
it stays enabled at boot if the FW left it enabled (and keep the same
duty cycle / clocks?).  That would at least solve the problem where
the firmware configured the PWM and left it in a specific state even
if it doesn't solve the above problem...


-Doug

If we want pwm stay enabled at boot(FW left it), needn't to modify 
anything, only need to init pwm duty in FW.

And now reading the duty from pwm would make sense.



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

Re: [PATCH] perf: Use ACCESS_ONCE() instead of volatile cast

[Namhyung Kim]

Hi Pranith,

On Tue, 23 Sep 2014 10:55:08 -0400, Pranith Kumar wrote:
> Use ACCESS_ONCE() instead of the cast to volatile and read. This is just a 
> style
> change which is reader friendly.
>
> Signed-off-by: Pranith Kumar 

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/util/session.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
> index 8dd41ca..ffb4404 100644
> --- a/tools/perf/util/session.h
> +++ b/tools/perf/util/session.h
> @@ -126,5 +126,5 @@ int __perf_session__set_tracepoints_handlers(struct 
> perf_session *session,
>  
>  extern volatile int session_done;
>  
> -#define session_done()   (*(volatile int *)(_done))
> +#define session_done()   ACCESS_ONCE(session_done)
>  #endif /* __PERF_SESSION_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: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx

[Peter Chen]

On Tue, Sep 23, 2014 at 07:37:25PM +0200, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 11:55:15 Felipe Balbi wrote:
> > On Tue, Sep 23, 2014 at 06:44:40PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 23 September 2014 15:36:45 Antoine Tenart wrote:
> > > > On Tue, Sep 23, 2014 at 12:39:04PM +0200, Arnd Bergmann wrote:
> > > > > On Tuesday 23 September 2014 12:28:03 Antoine Tenart wrote:
> > > > > > +   if (dev->of_node) {
> > > > > > +   ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
> > > > > > +   if (ret)
> > > > > > +   goto clk_err;
> > > > > > +   } else {
> > > > > > +   ret = dma_set_mask_and_coherent(>dev, 
> > > > > > DMA_BIT_MASK(32));
> > > > > > +   if (ret)
> > > > > > +   goto clk_err;
> > > > > > +   }
> > > > > > 
> > > > > 
> > > > > Why do you care about the non-DT case here? I think it would be nicer 
> > > > > to
> > > > > open-code the ci_hdrc_usb2_dt_probe() function in here and remove
> > > > > the dma_set_mask_and_coherent(), which should not even be necessary 
> > > > > for
> > > > > the case where you have a hardwired platform device.
> > > > > 
> > > > 
> > > > I thought we agreed to call dma_set_mask_and_coherent():
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/273335.html
> > > > 
> > > > I do not have a strong opinion on this as I only use the dt case for my
> > > > usage.
> > > 
> > > The question is more about who actually wants the non-DT case.
> > > 
> > > Since this is a new driver, I suspect that the answer is "nobody",
> > > as the existing board files are all for legacy platforms that we
> > > are not going to adapt for this driver.
> > 
> > wait a minute... will the legacy platforms be adapted to DT and, thus,
> > to this driver in the future ? I really don't want to keep several
> > copies of chipidea driver just because there are still some legacy
> > platforms still using them. I have said in the past and will say again,
> > everybody should move to the generic chipidea driver at the earliest
> > opportunity so we avoid duplication of work.
> > 
> 
> Sorry, my mistake. The intention that this new driver is meant to
> replace the existing ones wasn't clear to me from the changelog,
> and if I'd been involved in the discussion before, then I've forgotten
> about it.
> 
> It absolutely makes sense to migrate to a common driver, and in that
> case we should keep the platform_data handling and dma_set_mask_and_coherent()
> call in there, so we can do the two conversions (migrating from platform
> specific frontends to the generic one, and migrating from platform_data
> to DT) on independent schedules. Eventually I'd like all of the existing
> users of the platform_data path to move to DT, but that should not
> hold up the other cleanup if it takes longer.
> 
> There is however still my point that we shouldn't have an extra platform
> device that is not attached to the device node. I think the generic driver
> should just be part of the common code, without an extra framework.
> Something like the (entirely untested) patch below.
> 
>   Arnd

Thanks, Arnd.

Antoine is adding a generic chipdea glue layer driver, which like ehci generic
platform driver: drivers/usb/host/ehci-platform.c, since other architectures
like MIPS (Someone submitted mips chipidea driver before) may not have device
tree support, I think non-dt support is also needed.

It is a good suggestion for adding DT support for core driver, Since we did
not do it at the first, it is a little embarrass at current situation.

- For the new chipidea glue drivers, it is ok we can have a child node
for core device at glue device node, and some common entries can be there
like: phy, vbus, dr_mode, etc. We need to add support for getting
these common things for both through device tree and platform data
(parent is DT support and parent is non-DT support) at core driver.

- For the existing glue drivers, since we can't change existed dts, we can
only do it from future SoC support. Then, in this kinds of glue drivers,
we need to support for both create core driver by node and by current
calling platform_device_add way.

Peter

> 
> ---
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 9563cb56d564..a2b20c1342f1 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -207,6 +207,7 @@ struct ci_hdrc {
>   boolid_event;
>   boolb_sess_valid_event;
>   boolimx28_write_fix;
> + struct clk  *clk;
>  };
>  
>  static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
> diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
> b/drivers/usb/chipidea/ci_hdrc_usb2.c
> index 6eae1de587f2..03ef35997dd8 100644
> --- a/drivers/usb/chipidea/ci_hdrc_usb2.c
> +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
> @@ -70,6 +70,7 @@ static int 

Re: [PATCH v4] kvm: Fix page ageing bugs

[Wanpeng Li]

Hi Andres,
On Mon, Sep 22, 2014 at 02:54:42PM -0700, Andres Lagar-Cavilla wrote:
>1. We were calling clear_flush_young_notify in unmap_one, but we are
>within an mmu notifier invalidate range scope. The spte exists no more
>(due to range_start) and the accessed bit info has already been
>propagated (due to kvm_pfn_set_accessed). Simply call
>clear_flush_young.
>
>2. We clear_flush_young on a primary MMU PMD, but this may be mapped
>as a collection of PTEs by the secondary MMU (e.g. during log-dirty).
>This required expanding the interface of the clear_flush_young mmu
>notifier, so a lot of code has been trivially touched.
>
>3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we emulate
>the access bit by blowing the spte. This requires proper synchronizing
>with MMU notifier consumers, like every other removal of spte's does.
>
[...]
>---
>+  BUG_ON(!shadow_accessed_mask);
> 
>   for (sptep = rmap_get_first(*rmapp, ); sptep;
>sptep = rmap_get_next()) {
>+  struct kvm_mmu_page *sp;
>+  gfn_t gfn;
>   BUG_ON(!is_shadow_present_pte(*sptep));
>+  /* From spte to gfn. */
>+  sp = page_header(__pa(sptep));
>+  gfn = kvm_mmu_page_get_gfn(sp, sptep - sp->spt);
> 
>   if (*sptep & shadow_accessed_mask) {
>   young = 1;
>   clear_bit((ffs(shadow_accessed_mask) - 1),
>(unsigned long *)sptep);
>   }
>+  trace_kvm_age_page(gfn, slot, young);

IIUC, all the rmapps in this for loop are against the same gfn which
results in the above trace point dump the message duplicated.

Regards,
Wanpeng Li 

--
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] watchdog: imx2_wdt: Add power management support.

[li.xi...@freescale.com]

Hi,


[...]
> > +#ifdef CONFIG_PM_SLEEP
> > +/* Disable watchdog if it is active or non-active but still running */
> > +static int imx2_wdt_suspend(struct device *dev)
> > +{
> > +   struct watchdog_device *wdog = dev_get_drvdata(dev);
> > +   struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
> > +
> > +   imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
> > +   imx2_wdt_ping(wdog);
> 
> I am a bit concerned about this one. Why ping the watchdog if it is
> not running ? Shouldn't this only be done if the watchdog is running ?
>

Since the IMX2 watchdog will be always alive once started until power down
it.

Even not running, these code doesn't make any sense actually, and When probe,
the clock has been enabled, so we can feel safe of doing this.


> > +
> > +   /* Watchdog has been stopped but IP block is still running */
> > +   if (!watchdog_active(wdog) && imx2_wdt_is_running(wdev))
> > +   del_timer_sync(>timer);
> > +
> > +   /* If PM will be supported using imx2_wdt, please
> > +* make sure that the wdev->clk could disable the
> > +* watchdog's counter input clock source or can mask
> > +* watchdog's reset request to the core.
> > +*/
> 
> As far as I know, the watchdog subsystem uses standard multi-line comments.
> 
Okay, I will revise this.

> I am not sure if such a comment in the code will help. People don't usually
> read code to find out why the watchdog resets the board in suspend even
> if it should not.
> 
> Can you detect this condition programmatically (presumably that the clock
> was stopped if I understand correctly) to ensure that it is met ?
> 

IMO, all the SoCs using this watchdog didn't support PM for now through the
watchdog reference manual document and the current driver, because once started,
we couldn't stop the counter decreasing down to zero without disabling the 
counter
clock. 

What we actually care about is disabling the input clock source for counter, if
We cannot disable this, the watchdog will reset the core when sleeping. Or if we
can gate the reset signal to the cores is also one good choice.
But these cannot be programmatically to be ensured using one common way for all
SoCs.


> > +   clk_disable_unprepare(wdev->clk);
> > +
> > +   return 0;
> > +}
> > +
> > +/* Enable watchdog and configure it if necessary */
> > +static int imx2_wdt_resume(struct device *dev)
> > +{
> > +   struct watchdog_device *wdog = dev_get_drvdata(dev);
> > +   struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
> > +
> > +   clk_prepare_enable(wdev->clk);
> > +
> > +   if (watchdog_active(wdog) && !imx2_wdt_is_running(wdev)) {
> > +   /* If watchdog is still used by consumers and
> > +* resumes from deep sleep state, need to
> > +* restart the watchdog again.
> > +*/
> > +   imx2_wdt_setup(wdog);
> > +   imx2_wdt_set_timeout(wdog, wdog->timeout);
> > +   imx2_wdt_ping(wdog);
> > +   } else if (imx2_wdt_is_running(wdev)) {
> > +   imx2_wdt_set_timeout(wdog, wdog->timeout);
> > +   imx2_wdt_ping(wdog);
> > +   /* If watchdog has started --> stopped by the
> > +* consumers and resumes from non-deep sleep state,
> > +* then start the timer again.
> > +*/
> > +   if (!watchdog_active(wdog))
> > +   mod_timer(>timer,
> > + jiffies + wdog->timeout * HZ / 2);
> > +   } else {
> > +   /* If watchdog has been started --> stopped by
> > +* the consumers and resumes from deep sleep state,
> > +* will do nothing. The watchdog will be restarted
> > +* by consumers next time to be used.
> > +*/
> 
> I really dislike the notion of an else case just for a comment.
> It should be obvious that nothing needs to be done here if the watchdog
> is not running.
> 
Yes, I will remove this.


Thanks,

BRs
Xiubo


> > +   }
> > +
> > +   return 0;
> > +}
> > +#endif
> > +
> > +static SIMPLE_DEV_PM_OPS(imx2_wdt_pm_ops, imx2_wdt_suspend,
> > +imx2_wdt_resume);
> > +
> >  static const struct of_device_id imx2_wdt_dt_ids[] = {
> > { .compatible = "fsl,imx21-wdt", },
> > { /* sentinel */ }
> > @@ -307,6 +372,7 @@ static struct platform_driver imx2_wdt_driver = {
> > .driver = {
> > .name   = DRIVER_NAME,
> > .owner  = THIS_MODULE,
> > +   .pm = _wdt_pm_ops,
> > .of_match_table = imx2_wdt_dt_ids,
> > },
> >  };
> > --
> > 2.1.0.27.g96db324
> >
--
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] perf callchain: Use global caching provided by libunwind

[Namhyung Kim]

Hi Arun,

On Tue, 23 Sep 2014 14:01:22 +, Arun Sharma wrote:
> On 9/23/14, 12:00 PM, Namhyung Kim wrote:
>
>> +unw_set_caching_policy(addr_space, UNW_CACHE_GLOBAL);
>
> The result is a bit surprising for me. In micro benchmarking (eg:
> Lperf-simple), the per-thread policy is generally faster because it
> doesn't involve locking.
>
> libunwind/tests/Lperf-simple
> unw_getcontext : cold avg=  109.673 nsec, warm avg=   28.610 nsec
> unw_init_local : cold avg=  259.876 nsec, warm avg=9.537 nsec
> no cache: unw_step : 1st= 3258.387 min= 2922.331 avg= 3002.384 nsec
> global cache: unw_step : 1st= 1192.093 min=  960.486 avg=  982.208 nsec
> per-thread cache: unw_step : 1st=  429.153 min=  113.533 avg=  121.762 nsec

Yes, per-thread policy is faster than global caching policy.  Below is my
test result.  Note that I already run this several times before to
remove an effect that file contents loaded in page cache.

 Performance counter stats for
   'perf report -i /home/namhyung/tmp/perf-testing/perf.data.kbuild.dwarf 
--stdio' (3 runs):

 UNW_CACHE_NONE UNW_CACHE_GLOBAL 
UNW_CACHE_PER_THREAD
  
---
  task-clock (msec)14298.911947  7112.171928
  6913.244797  
  context-switches1,507  762
  742  
  cpu-migrations  12
1  
  page-faults 2,924,8891,101,380
1,101,380  
  cycles 53,895,784,665   26,798,627,423
   26,070,728,349  
  stalled-cycles-frontend24,472,506,687   12,577,760,746
   12,435,320,081  
  stalled-cycles-backend 17,550,483,7269,075,054,009
9,035,478,957  
  instructions   73,544,039,490   34,352,889,707
   33,283,120,736  
  branches   14,969,890,3717,139,469,848
6,926,994,151  
  branch-misses 193,852,116  100,455,431
   99,757,213  
  time elapsed 14.905719730  7.455597356
  7.242275972  


>
> I can see how the global policy would involve less memory allocation
> because of shared data structures. Curious about the reason for the
> speedup (specifically if libunwind should change the defaults for the
> non-local unwinding case).

I don't see much difference between global and per-thread caching for
remote unwind (besides rs_cache->lock you mentioned).  Also I'm curious
that how rs_new() is protected from concurrent accesses in per-thread
caching.  That's why I chose the global caching - yeah, it probably
doesn't matter to a single thread, but... :)

Thanks
Namhyung
--
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 REQUEST] late md/raid1 bug fixes for 3.17

[NeilBrown]

Hi Linus,
 it is amazing how much easier it is to find bugs when you know one is there.
Two bug reports resulted in finding 7 bugs!!

All are tagged for -stable.  Those that can't cause (rare) data corruption,
cause lockups.

Thanks,
NeilBrown


The following changes since commit d030671f3f261e528dc6e396a13f10859a74ae7c:

  Merge branch 'for-3.17-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup (2014-09-07 20:20:16 
-0700)

are available in the git repository at:

  git://git.neil.brown.name/md/ tags/md/3.17-more-fixes

for you to fetch changes up to b8cb6b4c121e1bf1963c16ed69e7adcb1bc301cd:

  md/raid1: fix_read_error should act on all non-faulty devices. (2014-09-22 
11:26:01 +1000)


Bugfixes for md/raid1

particularly, but not only, fixing new "resync" code.


NeilBrown (8):
  md/raid1: intialise start_next_window for READ case to avoid hang
  md/raid1:  be more cautious where we read-balance during resync.
  md/raid1: clean up request counts properly in close_sync()
  md/raid1: make sure resync waits for conflicting writes to complete.
  md/raid1: Don't use next_resync to determine how far resync has progressed
  md/raid1: update next_resync under resync_lock.
  md/raid1: count resync requests in nr_pending.
  md/raid1: fix_read_error should act on all non-faulty devices.

 drivers/md/raid1.c | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)


signature.asc
Description: PGP signature

[PATCH v5 3/3] dt-bindings: video: Add documentation for rockchip vop

[Mark yao]

This adds binding documentation for Rockchip SoC VOP driver.

Signed-off-by: Mark Yao 
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem

Changes in v3: None

Changes in v4: None

Changes in v5: None

 .../devicetree/bindings/video/rockchip-vop.txt |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt 
b/Documentation/devicetree/bindings/video/rockchip-vop.txt
new file mode 100644
index 000..d15351f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt
@@ -0,0 +1,58 @@
+device-tree bindings for rockchip soc display controller (vop)
+
+VOP (Visual Output Processor) is the Display Controller for the Rockchip
+series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-vop";
+
+- interrupts: should contain a list of all VOP IP block interrupts in the
+order: VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: Must contain
+   aclk_vop: for ddr buffer transfer.
+   hclk_vop: for ahb bus to R/W the phy regs.
+   dclk_vop: pixel clock.
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - axi
+  - ahb
+  - dclk
+
+- iommus: required a iommu node
+
+- port: A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+SoC specific DT entry:
+   vopb: vopb@ff93 {
+   compatible = "rockchip,rk3288-vop";
+   reg = <0xff93 0x19c>;
+   interrupts = ;
+   clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_LCDC1_AXI>, < SRST_LCDC1_AHB>, < 
SRST_LCDC1_DCLK>;
+   reset-names = "axi", "ahb", "dclk";
+   iommus = <_mmu>;
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vopb_out_edp: endpoint@0 {
+   reg = <0>;
+   remote-endpoint=<_in_vopb>;
+   };
+   vopb_out_hdmi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint=<_in_vopb>;
+   };
+   };
+   };
-- 
1.7.9.5


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

[PATCH v5 2/3] dt-bindings: video: Add for rockchip display subsytem

[Mark yao]

This add a display subsystem comprise the all display interface nodes.

Signed-off-by: Mark Yao 
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.

Changes in v3: None

Changes in v4: None

Changes in v5: None

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt 
b/Documentation/devicetree/bindings/video/rockchip-drm.txt
new file mode 100644
index 000..7fff582
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt
@@ -0,0 +1,19 @@
+Rockchip DRM master device
+
+
+The Rockchip DRM master device is a virtual device needed to list all
+vop devices or other display interface nodes that comprise the
+graphics subsystem.
+
+Required properties:
+- compatible: Should be "rockchip,display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface port
+  of vop devices. vop definitions as defined in
+  Documentation/devicetree/bindings/video/rockchip-vop.txt
+
+example:
+
+display-subsystem {
+   compatible = "rockchip,display-subsystem";
+   ports = <_out>, <_out>;
+};
-- 
1.7.9.5

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

[PATCH v5 1/3] drm/rockchip: Add basic drm driver

[Mark yao]

This patch adds the basic structure of a DRM Driver for Rockchip Socs.

Signed-off-by: Mark yao 
---
Changes in v2:
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- use vop reset at first init
- reference framebuffer when used and unreference when swap out vop

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  509 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  120 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  230 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  341 ++
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1373 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  187 
 14 files changed, 3092 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b066bb3..7c4c3c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -171,6 +171,8 @@ config DRM_SAVAGE
 
 source "drivers/gpu/drm/exynos/Kconfig"
 
+source "drivers/gpu/drm/rockchip/Kconfig"
+
 source "drivers/gpu/drm/vmwgfx/Kconfig"
 
 source "drivers/gpu/drm/gma500/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..d03387a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
+obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
new file mode 100644
index 000..87255f7
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -0,0 +1,17 @@
+config DRM_ROCKCHIP
+   tristate "DRM Support for Rockchip"
+   depends on DRM && ROCKCHIP_IOMMU && ARM_DMA_USE_IOMMU && IOMMU_API
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_PANEL
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
+   select VIDEOMODE_HELPERS
+   help
+ Choose this option if you have a Rockchip soc chipset.
+ This driver provides kernel mode setting and buffer
+ management to userspace. This driver does not provides
+ 2D or 3D acceleration; acceleration is performed by other
+ IP found on the SoC.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
new file mode 100644
index 000..b3a5193
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -0,0 +1,8 @@
+#
+# Makefile for the drm device driver.  This 

Re: [PATCH v6 1/2] regulator: st-pwm: get voltage and duty table from dts

[Doug Anderson]

Chris,

On Tue, Sep 23, 2014 at 6:47 PM, Chris Zhong  wrote:
>
> On 09/24/2014 07:43 AM, Doug Anderson wrote:
>>
>> Chris,
>>
>> On Tue, Sep 23, 2014 at 8:53 AM, Chris Zhong  wrote:
>>>
>>> Get voltage & duty table from device tree might be better, other
>>> platforms can also use this
>>> driver without any modify.
>>>
>>> Signed-off-by: Chris Zhong 
>>> Reviewed-by: Doug Anderson 
>>
>> I finally managed to get everything setup and I've now tested this
>> myself on an rk3288-based board.
>>
>> Tested-by: Doug Anderson 
>>
>> I'd imagine the next step is for Lee to comment on the patch and when
>> he's happy with it Mark Brown will land it?
>>
>>
>> One thing that's still a bit odd (though no different than the
>> behavior of the driver from before you touched it, so it shouldn't
>> block landing IMHO) is that at boot time this regulator will report
>> that it's at the highest voltage but the voltage won't actually change
>> until the first client sets the voltage.
>
> Yes, I knew this problem, since the default of duty cycle is 0, not a true
> value.
> If we can get duty from pwm, this regulator will report a correct voltage.

I don't think it's possible in all cases to figure out what the
voltage was before this regulator was probed.

* pin might have been input w/ pullup, pulldown, or no pull
* pin might have been driven high or driven low

In that case trying to read the duty from the pwm wouldn't make sense.
...but I guess you could add a property to the PWM driver to say that
it stays enabled at boot if the FW left it enabled (and keep the same
duty cycle / clocks?).  That would at least solve the problem where
the firmware configured the PWM and left it in a specific state even
if it doesn't solve the above problem...


-Doug
--
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 v5 0/3] Add drm driver for Rockchip Socs

[Mark yao]

This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.

The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar
Vop devices. Vop devices support iommu mapping, we use dma-mapping API with
ARM_DMA_USE_IOMMU.

Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- add vop reset.

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Mark yao (3):
  drm/rockchip: Add basic drm driver
  dt-bindings: video: Add for rockchip display subsytem
  dt-bindings: video: Add documentation for rockchip vop

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +
 .../devicetree/bindings/video/rockchip-vop.txt |   58 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/rockchip/Kconfig   |   17 +
 drivers/gpu/drm/rockchip/Makefile  |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  509 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|  120 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  201 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  230 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  341 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1373 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  187 +++
 16 files changed, 3169 insertions(+)

-- 
1.7.9.5

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

Re: [PATCH v3] power: reset: use restart_notifier mechanism for msm-poweroff

[Pramod Gurav]

Hi Kumar,

On 23-09-2014 11:18 PM, Kumar Gala wrote:
> 
> On Sep 23, 2014, at 1:28 AM, Pramod Gurav  
> wrote:
> 
>> +linux-arm-msm
>> On Tuesday 23 September 2014 11:38 AM, Pramod Gurav wrote:
>>> This change replaces use of arm_pm_restart with recently introduced
>>> reset mechanism in Linux kernel called restart_notifier.
> 
> Can you update the commit message to include details about the priority level 
> we are setting it to.
> 
> Probably something like Josh had:
> 
> Choose priority 128, as according to documentation, this mechanism "is
> sufficient to restart the entire system”.
Will update the commit message.
> 
> Hmm, what happens if we have ps_hold restart and msm-poweroff enabled.  Which 
> one should have priority?
In case of A-family/apq8064, the ps_hold register region is owned by
pinctrl hence the reset is implemented in pinctrl driver as the region
is already mapped there.
I have had a discussion with Stephen Boyd and was informed that ps_hold
register region in apq8074/B-family are moved to its own region and we
need to reset it through pinctrl.

So, for b family there is no need for ps_hold to be configured/muxed in
pinctrl and Josh's changes wont execute. Hence msm-poweroff wil be the
default reset as 128 in the default priority.

Hope I was able to put it well to answer your comment.
> 
>>>
>>> Reviewed-by: Guenter Roeck 
>>> Cc: Guenter Roeck 
>>> Cc: Josh Cartwright 
>>> Cc: Sebastian Reichel 
>>> Cc: Dmitry Eremin-Solenikov 
>>> Cc: David Woodhouse 
>>> Cc: Stephen Boyd 
>>> Cc: linux...@vger.kernel.org
>>>
>>> Signed-off-by: Pramod Gurav 
>>> ---
>>> Tested on Dragonboard APQ8074
>>>
>>> Changes since v2:
>>> - Removed unwanted header file and added linux/pm.h
>>>
>>> Changes since v1:
>>> - Initialized restart_nb with its declaration
>>> - Removed return check for register_restart_handler as it always
>>>  returns 0 as per Guenter's suggestion to Josh's similar patch.
>>>  This takes care of Guenter's comments on error logs and NULL
>>>  initialization of restart_nb.notifier_call.
>>> ---
>>> drivers/power/reset/msm-poweroff.c |   20 ++--
>>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/power/reset/msm-poweroff.c 
>>> b/drivers/power/reset/msm-poweroff.c
>>> index 774f9a3..4702efd 100644
>>> --- a/drivers/power/reset/msm-poweroff.c
>>> +++ b/drivers/power/reset/msm-poweroff.c
>>> @@ -20,21 +20,27 @@
>>> #include 
>>> #include 
>>> #include 
>>> -
>>> -#include 
>>> +#include 
>>>
>>> static void __iomem *msm_ps_hold;
>>> -
>>> -static void do_msm_restart(enum reboot_mode reboot_mode, const char *cmd)
>>> +static int do_msm_restart(struct notifier_block *nb, unsigned long action,
>>> +  void *data)
>>> {
>>> writel(0, msm_ps_hold);
>>> mdelay(1);
>>> +
>>> +   return NOTIFY_DONE;
>>> }
>>>
>>> +static struct notifier_block restart_nb = {
>>> +   .notifier_call = do_msm_restart,
>>> +   .priority = 128,
>>> +};
>>> +
>>> static void do_msm_poweroff(void)
>>> {
>>> /* TODO: Add poweroff capability */
>>> -   do_msm_restart(REBOOT_HARD, NULL);
>>> +   do_msm_restart(_nb, 0, NULL);
>>> }
>>>
>>> static int msm_restart_probe(struct platform_device *pdev)
>>> @@ -47,8 +53,10 @@ static int msm_restart_probe(struct platform_device 
>>> *pdev)
>>> if (IS_ERR(msm_ps_hold))
>>> return PTR_ERR(msm_ps_hold);
>>>
>>> +   register_restart_handler(_nb);
>>> +
>>> pm_power_off = do_msm_poweroff;
>>> -   arm_pm_restart = do_msm_restart;
>>> +
>>> return 0;
>>> }
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] kvm, mem-hotplug: Add arch specific mmu notifier to handle apic access migration.

[Tang Chen]

Hi Paolo, 

I'm not sure if this patch is following your comment. Please review.
And all the other comments are followed. If this patch is OK, I'll 
send v8 soon.

Thanks.

We are handling "L1 and L2 share one apic access page" situation when migrating
apic access page. We should do some handling when migration happens in the
following situations:

   1) when L0 is running: Update L1's vmcs in the next L0->L1 entry and L2's
  vmcs in the next L1->L2 entry.

   2) when L1 is running: Force a L1->L0 exit, update L1's vmcs in the next
  L0->L1 entry and L2's vmcs in the next L1->L2 entry.

   3) when L2 is running: Force a L2->L0 exit, update L2's vmcs in the next
  L0->L2 entry and L1's vmcs in the next L2->L1 exit.

This patch force a L1->L0 exit or L2->L0 exit when shared apic access page is
migrated using mmu notifier. Since apic access page is only used on intel x86,
this is arch specific code.
---
 arch/arm/include/asm/kvm_host.h |  6 ++
 arch/arm64/include/asm/kvm_host.h   |  6 ++
 arch/ia64/include/asm/kvm_host.h|  8 
 arch/mips/include/asm/kvm_host.h|  7 +++
 arch/powerpc/include/asm/kvm_host.h |  6 ++
 arch/s390/include/asm/kvm_host.h|  9 +
 arch/x86/include/asm/kvm_host.h |  2 ++
 arch/x86/kvm/x86.c  | 11 +++
 virt/kvm/kvm_main.c |  3 +++
 9 files changed, 58 insertions(+)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 6dfb404..79bbf7d 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -182,6 +182,12 @@ static inline int kvm_test_age_hva(struct kvm *kvm, 
unsigned long hva)
return 0;
 }
 
+static inline void kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
+unsigned long address)
+{
+   return;
+}
+
 struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
 struct kvm_vcpu __percpu **kvm_get_running_vcpus(void);
 
diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index e10c45a..ee89fad 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -192,6 +192,12 @@ static inline int kvm_test_age_hva(struct kvm *kvm, 
unsigned long hva)
return 0;
 }
 
+static inline void kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
+unsigned long address)
+{
+   return;
+}
+
 struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
 struct kvm_vcpu __percpu **kvm_get_running_vcpus(void);
 
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index db95f57..326ac55 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -574,6 +574,14 @@ static inline struct kvm_pt_regs *vcpu_regs(struct 
kvm_vcpu *v)
return (struct kvm_pt_regs *) ((unsigned long) v + KVM_STK_OFFSET) - 1;
 }
 
+#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
+static inline void kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
+unsigned long address)
+{
+   return;
+}
+#endif /* KVM_ARCH_WANT_MMU_NOTIFIER */
+
 typedef int kvm_vmm_entry(void);
 typedef void kvm_tramp_entry(union context *host, union context *guest);
 
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 7a3fc67..c392705 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -767,5 +767,12 @@ extern int kvm_mips_trans_mtc0(uint32_t inst, uint32_t 
*opc,
 extern void kvm_mips_dump_stats(struct kvm_vcpu *vcpu);
 extern unsigned long kvm_mips_get_ramsize(struct kvm *kvm);
 
+#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
+static inline void kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
+unsigned long address)
+{
+   return;
+}
+#endif /* KVM_ARCH_WANT_MMU_NOTIFIER */
 
 #endif /* __MIPS_KVM_HOST_H__ */
diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 98d9dd5..c16a573 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -61,6 +61,12 @@ extern int kvm_age_hva(struct kvm *kvm, unsigned long hva);
 extern int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
 extern void kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
 
+static inline void kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
+unsigned long address)
+{
+   return;
+}
+
 #define HPTEG_CACHE_NUM(1 << 15)
 #define HPTEG_HASH_BITS_PTE13
 #define HPTEG_HASH_BITS_PTE_LONG   12
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
index 773bef7..693290f 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -450,4 +450,13 @@ void 

Re: [PATCH 0/5] Remove possible deadlocks in nfs_release_page() - V3

[Trond Myklebust]

On Tue, Sep 23, 2014 at 9:28 PM, NeilBrown  wrote:
> This set includes acked-by's from Andrew and Peter so it should be
> OK for all five patches to go upstream through the NFS tree.
>
> I split the congestion tracking patch out from the wait-for-PG_private
> patch as they are conceptually separate.
>
> This set continues to perform well in my tests and addresses all
> issues that have been raised.
>
> Thanks a lot,
> NeilBrown
>

Thanks Neil! I'll give them a final review tomorrow, and then queue
them up for the 3.18 merge window.

-- 
Trond Myklebust

Linux NFS client maintainer, PrimaryData

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

[PATCH 3/5] NFS: avoid deadlocks with loop-back mounted NFS filesystems.

[NeilBrown]

Support for loop-back mounted NFS filesystems is useful when NFS is
used to access shared storage in a high-availability cluster.

If the node running the NFS server fails, some other node can mount the
filesystem and start providing NFS service.  If that node already had
the filesystem NFS mounted, it will now have it loop-back mounted.

nfsd can suffer a deadlock when allocating memory and entering direct
reclaim.
While direct reclaim does not write to the NFS filesystem it can send
and wait for a COMMIT through nfs_release_page().

This patch modifies nfs_release_page() to wait a limited time for the
commit to complete - one second.  If the commit doesn't complete
in this time, nfs_release_page() will fail.  This means it might now
fail in some cases where it wouldn't before.  These cases are only
when 'gfp' includes '__GFP_WAIT'.

nfs_release_page() is only called by try_to_release_page(), and that
can only be called on an NFS page with required 'gfp' flags from
 - page_cache_pipe_buf_steal() in splice.c
 - shrink_page_list() in vmscan.c
 - invalidate_inode_pages2_range() in truncate.c

The first two handle failure quite safely.  The last is only called
after ->launder_page() has been called, and that will have waited
for the commit to finish already.

So aborting if the commit takes longer than 1 second is perfectly safe.

Signed-off-by: NeilBrown 
---
 fs/nfs/file.c  |   26 --
 fs/nfs/write.c |2 ++
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 524dd80d1898..ef5513322cf6 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -468,17 +468,23 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
 
dfprintk(PAGECACHE, "NFS: release_page(%p)\n", page);
 
-   /* Only do I/O if gfp is a superset of GFP_KERNEL, and we're not
-* doing this memory reclaim for a fs-related allocation.
+   /* Always try to initiate a 'commit' if relevant, but only
+* wait for it if __GFP_WAIT is set and the calling process is
+* allowed to block.  Even then, only wait 1 second.
+* Waiting indefinitely can cause deadlocks when the NFS
+* server is on this machine, and there is no particular need
+* to wait extensively here.  A short wait has the benefit
+* that someone else can worry about the freezer.
 */
-   if (mapping && (gfp & GFP_KERNEL) == GFP_KERNEL &&
-   !(current->flags & PF_FSTRANS)) {
-   int how = FLUSH_SYNC;
-
-   /* Don't let kswapd deadlock waiting for OOM RPC calls */
-   if (current_is_kswapd())
-   how = 0;
-   nfs_commit_inode(mapping->host, how);
+   if (mapping) {
+   struct nfs_server *nfss = NFS_SERVER(mapping->host);
+   nfs_commit_inode(mapping->host, 0);
+   if ((gfp & __GFP_WAIT) &&
+   !current_is_kswapd() &&
+   !(current->flags & PF_FSTRANS)) {
+   wait_on_page_bit_killable_timeout(page, PG_private,
+ HZ);
+   }
}
/* If PagePrivate() is set, then the page is not freeable */
if (PagePrivate(page))
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 175d5d073ccf..b5d83c7545d4 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -731,6 +731,8 @@ static void nfs_inode_remove_request(struct nfs_page *req)
if (likely(!PageSwapCache(head->wb_page))) {
set_page_private(head->wb_page, 0);
ClearPagePrivate(head->wb_page);
+   smp_mb__after_atomic();
+   wake_up_page(head->wb_page, PG_private);
clear_bit(PG_MAPPED, >wb_flags);
}
nfsi->npages--;


--
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 5/5] NFS/SUNRPC: Remove other deadlock-avoidance mechanisms in nfs_release_page()

[NeilBrown]

Now that nfs_release_page() doesn't block indefinitely, other deadlock
avoidance mechanisms aren't needed.
 - it doesn't hurt for kswapd to block occasionally.  If it doesn't
   want to block it would clear __GFP_WAIT.  The current_is_kswapd()
   was only added to avoid deadlocks and we have a new approach for
   that.
 - memory allocation in the SUNRPC layer can very rarely try to
   ->releasepage() a page it is trying to handle.  The deadlock
   is removed as nfs_release_page() doesn't block indefinitely.

So we don't need to set PF_FSTRANS for sunrpc network operations any
more.

Signed-off-by: NeilBrown 
---
 fs/nfs/file.c   |   14 ++
 net/sunrpc/sched.c  |2 --
 net/sunrpc/xprtrdma/transport.c |2 --
 net/sunrpc/xprtsock.c   |   10 --
 4 files changed, 6 insertions(+), 22 deletions(-)

diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index 1243a15438d0..de322d3f4a29 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -469,20 +469,18 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
dfprintk(PAGECACHE, "NFS: release_page(%p)\n", page);
 
/* Always try to initiate a 'commit' if relevant, but only
-* wait for it if __GFP_WAIT is set and the calling process is
-* allowed to block.  Even then, only wait 1 second and only
-* if the 'bdi' is not congested.
+* wait for it if __GFP_WAIT is set.  Even then, only wait 1
+* second and only if the 'bdi' is not congested.
 * Waiting indefinitely can cause deadlocks when the NFS
-* server is on this machine, and there is no particular need
-* to wait extensively here.  A short wait has the benefit
-* that someone else can worry about the freezer.
+* server is on this machine, when a new TCP connection is
+* needed and in other rare cases.  There is no particular
+* need to wait extensively here.  A short wait has the
+* benefit that someone else can worry about the freezer.
 */
if (mapping) {
struct nfs_server *nfss = NFS_SERVER(mapping->host);
nfs_commit_inode(mapping->host, 0);
if ((gfp & __GFP_WAIT) &&
-   !current_is_kswapd() &&
-   !(current->flags & PF_FSTRANS) &&
!bdi_write_congested(>backing_dev_info)) {
wait_on_page_bit_killable_timeout(page, PG_private,
  HZ);
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 9358c79fd589..fe3441abdbe5 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -821,9 +821,7 @@ void rpc_execute(struct rpc_task *task)
 
 static void rpc_async_schedule(struct work_struct *work)
 {
-   current->flags |= PF_FSTRANS;
__rpc_execute(container_of(work, struct rpc_task, u.tk_work));
-   current->flags &= ~PF_FSTRANS;
 }
 
 /**
diff --git a/net/sunrpc/xprtrdma/transport.c b/net/sunrpc/xprtrdma/transport.c
index 2faac4940563..6a4615dd0261 100644
--- a/net/sunrpc/xprtrdma/transport.c
+++ b/net/sunrpc/xprtrdma/transport.c
@@ -205,7 +205,6 @@ xprt_rdma_connect_worker(struct work_struct *work)
struct rpc_xprt *xprt = _xprt->xprt;
int rc = 0;
 
-   current->flags |= PF_FSTRANS;
xprt_clear_connected(xprt);
 
dprintk("RPC:   %s: %sconnect\n", __func__,
@@ -216,7 +215,6 @@ xprt_rdma_connect_worker(struct work_struct *work)
 
dprintk("RPC:   %s: exit\n", __func__);
xprt_clear_connecting(xprt);
-   current->flags &= ~PF_FSTRANS;
 }
 
 /*
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 43cd89eacfab..4707c0c8568b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1927,8 +1927,6 @@ static int xs_local_setup_socket(struct sock_xprt 
*transport)
struct socket *sock;
int status = -EIO;
 
-   current->flags |= PF_FSTRANS;
-
clear_bit(XPRT_CONNECTION_ABORT, >state);
status = __sock_create(xprt->xprt_net, AF_LOCAL,
SOCK_STREAM, 0, , 1);
@@ -1968,7 +1966,6 @@ static int xs_local_setup_socket(struct sock_xprt 
*transport)
 out:
xprt_clear_connecting(xprt);
xprt_wake_pending_tasks(xprt, status);
-   current->flags &= ~PF_FSTRANS;
return status;
 }
 
@@ -2071,8 +2068,6 @@ static void xs_udp_setup_socket(struct work_struct *work)
struct socket *sock = transport->sock;
int status = -EIO;
 
-   current->flags |= PF_FSTRANS;
-
/* Start by resetting any existing state */
xs_reset_transport(transport);
sock = xs_create_sock(xprt, transport,
@@ -2092,7 +2087,6 @@ static void xs_udp_setup_socket(struct work_struct *work)
 out:
xprt_clear_connecting(xprt);
xprt_wake_pending_tasks(xprt, status);
-   current->flags &= ~PF_FSTRANS;
 }
 
 /*
@@ -2229,8 +2223,6 @@ static void xs_tcp_setup_socket(struct 

[PATCH 4/5] NFS: avoid waiting at all in nfs_release_page when congested.

[NeilBrown]

If nfs_release_page() is called on a sequence of pages which are all
in the same file which is blocked on COMMIT, each page could
contribute a 1 second delay which could be come excessive.  I have
seen delays of as much as 208 seconds.

To keep the delay to one second, mark the bdi as write-congested
if the commit didn't finished.  Once it does finish, the
write-congested flag will be cleared by nfs_commit_release_pages().

With this, the longest total delay in try_to_free_pages that I have
seen is under 3 seconds.  With no waiting in nfs_release_page at all
I have seen delays of nearly 1.5 seconds.

Signed-off-by: NeilBrown 
---
 fs/nfs/file.c  |9 +++--
 fs/nfs/write.c |5 +
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/file.c b/fs/nfs/file.c
index ef5513322cf6..1243a15438d0 100644
--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -470,7 +470,8 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
 
/* Always try to initiate a 'commit' if relevant, but only
 * wait for it if __GFP_WAIT is set and the calling process is
-* allowed to block.  Even then, only wait 1 second.
+* allowed to block.  Even then, only wait 1 second and only
+* if the 'bdi' is not congested.
 * Waiting indefinitely can cause deadlocks when the NFS
 * server is on this machine, and there is no particular need
 * to wait extensively here.  A short wait has the benefit
@@ -481,9 +482,13 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
nfs_commit_inode(mapping->host, 0);
if ((gfp & __GFP_WAIT) &&
!current_is_kswapd() &&
-   !(current->flags & PF_FSTRANS)) {
+   !(current->flags & PF_FSTRANS) &&
+   !bdi_write_congested(>backing_dev_info)) {
wait_on_page_bit_killable_timeout(page, PG_private,
  HZ);
+   if (PagePrivate(page))
+   set_bdi_congested(>backing_dev_info,
+ BLK_RW_ASYNC);
}
}
/* If PagePrivate() is set, then the page is not freeable */
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index b5d83c7545d4..3066c7fcb565 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1638,6 +1638,7 @@ static void nfs_commit_release_pages(struct 
nfs_commit_data *data)
struct nfs_page *req;
int status = data->task.tk_status;
struct nfs_commit_info cinfo;
+   struct nfs_server *nfss;
 
while (!list_empty(>pages)) {
req = nfs_list_entry(data->pages.next);
@@ -1671,6 +1672,10 @@ static void nfs_commit_release_pages(struct 
nfs_commit_data *data)
next:
nfs_unlock_and_release_request(req);
}
+   nfss = NFS_SERVER(data->inode);
+   if (atomic_long_read(>writeback) < NFS_CONGESTION_OFF_THRESH)
+   clear_bdi_congested(>backing_dev_info, BLK_RW_ASYNC);
+
nfs_init_cinfo(, data->inode, data->dreq);
if (atomic_dec_and_test(>rpcs_out))
nfs_commit_clear_lock(NFS_I(data->inode));


--
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/5] MM: export page_wakeup functions

[NeilBrown]

This will allow NFS to wait for PG_private to be cleared and,
particularly, to send a wake-up when it is.

Signed-off-by: NeilBrown 
Acked-by: Andrew Morton 
---
 include/linux/pagemap.h |   10 --
 mm/filemap.c|8 ++--
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 87f9e4230d3a..2dca0cef3506 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -496,8 +496,8 @@ static inline int lock_page_or_retry(struct page *page, 
struct mm_struct *mm,
 }
 
 /*
- * This is exported only for wait_on_page_locked/wait_on_page_writeback.
- * Never use this directly!
+ * This is exported only for wait_on_page_locked/wait_on_page_writeback,
+ * and for filesystems which need to wait on PG_private.
  */
 extern void wait_on_page_bit(struct page *page, int bit_nr);
 
@@ -512,6 +512,12 @@ static inline int wait_on_page_locked_killable(struct page 
*page)
return 0;
 }
 
+extern wait_queue_head_t *page_waitqueue(struct page *page);
+static inline void wake_up_page(struct page *page, int bit)
+{
+   __wake_up_bit(page_waitqueue(page), >flags, bit);
+}
+
 /* 
  * Wait for a page to be unlocked.
  *
diff --git a/mm/filemap.c b/mm/filemap.c
index 4a19c084bdb1..c9ba09f2ad3c 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -670,17 +670,13 @@ EXPORT_SYMBOL(__page_cache_alloc);
  * at a cost of "thundering herd" phenomena during rare hash
  * collisions.
  */
-static wait_queue_head_t *page_waitqueue(struct page *page)
+wait_queue_head_t *page_waitqueue(struct page *page)
 {
const struct zone *zone = page_zone(page);
 
return >wait_table[hash_ptr(page, zone->wait_table_bits)];
 }
-
-static inline void wake_up_page(struct page *page, int bit)
-{
-   __wake_up_bit(page_waitqueue(page), >flags, bit);
-}
+EXPORT_SYMBOL(page_waitqueue);
 
 void wait_on_page_bit(struct page *page, int bit_nr)
 {


--
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/5] Remove possible deadlocks in nfs_release_page() - V3

[NeilBrown]

This set includes acked-by's from Andrew and Peter so it should be
OK for all five patches to go upstream through the NFS tree.

I split the congestion tracking patch out from the wait-for-PG_private
patch as they are conceptually separate.

This set continues to perform well in my tests and addresses all
issues that have been raised.

Thanks a lot,
NeilBrown


---

NeilBrown (5):
  SCHED: add some "wait..on_bit...timeout()" interfaces.
  MM: export page_wakeup functions
  NFS: avoid deadlocks with loop-back mounted NFS filesystems.
  NFS: avoid waiting at all in nfs_release_page when congested.
  NFS/SUNRPC: Remove other deadlock-avoidance mechanisms in 
nfs_release_page()


 fs/nfs/file.c   |   29 +++--
 fs/nfs/write.c  |7 +++
 include/linux/pagemap.h |   12 ++--
 include/linux/wait.h|5 -
 kernel/sched/wait.c |   36 
 mm/filemap.c|   21 +++--
 net/sunrpc/sched.c  |2 --
 net/sunrpc/xprtrdma/transport.c |2 --
 net/sunrpc/xprtsock.c   |   10 --
 9 files changed, 91 insertions(+), 33 deletions(-)

-- 
Signature

--
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/5] SCHED: add some "wait..on_bit...timeout()" interfaces.

[NeilBrown]

In commit c1221321b7c25b53204447cff9949a6d5a7c
   sched: Allow wait_on_bit_action() functions to support a timeout

I suggested that a "wait_on_bit_timeout()" interface would not meet my
need.  This isn't true - I was just over-engineering.

Including a 'private' field in wait_bit_key instead of a focused
"timeout" field was just premature generalization.  If some other
use is ever found, it can be generalized or added later.

So this patch renames "private" to "timeout" with a meaning "stop
waiting when "jiffies" reaches or passes "timeout",
and adds two of the many possible wait..bit..timeout() interfaces:

wait_on_page_bit_killable_timeout(), which is the one I want to use,
and out_of_line_wait_on_bit_timeout() which is a reasonably general
example.  Others can be added as needed.

Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: NeilBrown 
---
 include/linux/pagemap.h |2 ++
 include/linux/wait.h|5 -
 kernel/sched/wait.c |   36 
 mm/filemap.c|   13 +
 4 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 3df8c7db7a4e..87f9e4230d3a 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -502,6 +502,8 @@ static inline int lock_page_or_retry(struct page *page, 
struct mm_struct *mm,
 extern void wait_on_page_bit(struct page *page, int bit_nr);
 
 extern int wait_on_page_bit_killable(struct page *page, int bit_nr);
+extern int wait_on_page_bit_killable_timeout(struct page *page,
+int bit_nr, unsigned long timeout);
 
 static inline int wait_on_page_locked_killable(struct page *page)
 {
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 6fb1ba5f9b2f..80115bf88671 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -25,7 +25,7 @@ struct wait_bit_key {
void*flags;
int bit_nr;
 #define WAIT_ATOMIC_T_BIT_NR   -1
-   unsigned long   private;
+   unsigned long   timeout;
 };
 
 struct wait_bit_queue {
@@ -154,6 +154,7 @@ int __wait_on_bit_lock(wait_queue_head_t *, struct 
wait_bit_queue *, wait_bit_ac
 void wake_up_bit(void *, int);
 void wake_up_atomic_t(atomic_t *);
 int out_of_line_wait_on_bit(void *, int, wait_bit_action_f *, unsigned);
+int out_of_line_wait_on_bit_timeout(void *, int, wait_bit_action_f *, 
unsigned, unsigned long);
 int out_of_line_wait_on_bit_lock(void *, int, wait_bit_action_f *, unsigned);
 int out_of_line_wait_on_atomic_t(atomic_t *, int (*)(atomic_t *), unsigned);
 wait_queue_head_t *bit_waitqueue(void *, int);
@@ -859,6 +860,8 @@ int wake_bit_function(wait_queue_t *wait, unsigned mode, 
int sync, void *key);
 
 extern int bit_wait(struct wait_bit_key *);
 extern int bit_wait_io(struct wait_bit_key *);
+extern int bit_wait_timeout(struct wait_bit_key *);
+extern int bit_wait_io_timeout(struct wait_bit_key *);
 
 /**
  * wait_on_bit - wait for a bit to be cleared
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index 15cab1a4f84e..380678b3cba4 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -343,6 +343,18 @@ int __sched out_of_line_wait_on_bit(void *word, int bit,
 }
 EXPORT_SYMBOL(out_of_line_wait_on_bit);
 
+int __sched out_of_line_wait_on_bit_timeout(
+   void *word, int bit, wait_bit_action_f *action,
+   unsigned mode, unsigned long timeout)
+{
+   wait_queue_head_t *wq = bit_waitqueue(word, bit);
+   DEFINE_WAIT_BIT(wait, word, bit);
+
+   wait.key.timeout = jiffies + timeout;
+   return __wait_on_bit(wq, , action, mode);
+}
+EXPORT_SYMBOL(out_of_line_wait_on_bit_timeout);
+
 int __sched
 __wait_on_bit_lock(wait_queue_head_t *wq, struct wait_bit_queue *q,
wait_bit_action_f *action, unsigned mode)
@@ -520,3 +532,27 @@ __sched int bit_wait_io(struct wait_bit_key *word)
return 0;
 }
 EXPORT_SYMBOL(bit_wait_io);
+
+__sched int bit_wait_timeout(struct wait_bit_key *word)
+{
+   unsigned long now = ACCESS_ONCE(jiffies);
+   if (signal_pending_state(current->state, current))
+   return 1;
+   if (time_after_eq(now, word->timeout))
+   return -EAGAIN;
+   schedule_timeout(word->timeout - now);
+   return 0;
+}
+EXPORT_SYMBOL(bit_wait_timeout);
+
+__sched int bit_wait_io_timeout(struct wait_bit_key *word)
+{
+   unsigned long now = ACCESS_ONCE(jiffies);
+   if (signal_pending_state(current->state, current))
+   return 1;
+   if (time_after_eq(now, word->timeout))
+   return -EAGAIN;
+   io_schedule_timeout(word->timeout - now);
+   return 0;
+}
+EXPORT_SYMBOL(bit_wait_io_timeout);
diff --git a/mm/filemap.c b/mm/filemap.c
index 90effcdf948d..4a19c084bdb1 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -703,6 +703,19 @@ int wait_on_page_bit_killable(struct page *page, int 
bit_nr)
 bit_wait_io, 

Re: linux-next: build warning after merge of the net tree

[David Miller]

From: Stephen Rothwell 
Date: Wed, 24 Sep 2014 07:23:06 +1000

> Dave, this is a bit slack of you since I reported that problem a week
> ago in the net tree and yet it has not been completely fixed before you
> asked Linus to pull your tree :-(

There were build failures I saw due to some misbalanced select/depends
issues which I fixed in:

commit df568d8e5250bf24e38c69ad4374baf0f8d279ba
Author: David S. Miller 
Date:   Mon Sep 22 13:14:33 2014 -0400

scsi: Use 'depends' with LIBFC instead of 'select'.

which went in yesterday.  I thought that would resolve all of your
problems.

Believe me, it is a tragic surprise that several defconfigs absolutely
depended upon this broken usage of select in the scsi layer, to of all
things make CONFIG_NET=y implicit.

I'll do my best to sort this out, but I hope that this short term pain
is worth it in the end.

Thanks for your understanding.
--
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: Stupid NVIDIA 3D vgaarb.c patch

[Alex Deucher]

On Mon, Sep 22, 2014 at 5:20 PM, C Bergström  wrote:
> For clarity - My testing and the patch is required when the Intel driver
> isn't being used at all. After I finish some other testing I can see if
> bumblebee and intel driver + this patch will play nicely.
>
> How is a laptop with dual VGA controllers any different than if one
> identifies itself as a "3D controller"?
>

I'm not familiar with nvidia hw, but some newer AMD asics don't have
any vga hw at all so they would have no need to have vga routed to
them ever.

Alex

> On Tue, Sep 23, 2014 at 4:15 AM, Alex Williamson
>  wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> > Adding proper people and mailing lists..
>> >
>> > The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> > BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> > appropriate, but hopefully somebody does. The fact that it makes
>> > things work certainly argues fairly convincingly for it, but I want
>> > some backup here.
>> >
>> > Dave, BenH?
>>
>> TBH, it seems pretty dubious to me.  There's nothing in the spec that
>> would give us reason to believe that a device with a 3D controller class
>> code requires VGA arbitration.  Also, if this controller starts
>> participating in arbitration then this same laptop will likely disable
>> DRI when Intel is the primary graphics due to Xorg wanting to mmap VGA
>> MMIO space.  I'm not sure what the solution is, but unfortunately it's
>> likely to be much more complicated than this patch.  Thanks,
>>
>> Alex
>>
>> > Christopher(?), can you please also specify which laptop etc. And the
>> > patch itself seems to have come from somebody else, unless you're
>> > Lekensteyn. So we'd want to get the provenance of that too.
>> >
>> > Linus
>> >
>> > On Mon, Sep 22, 2014 at 1:28 PM, C Bergström 
>> > wrote:
>> > > Hi Linus,
>> > >
>> > > I don't know who the original author is and I can have one of the
>> > > distro
>> > > graphics friends review it, but I need this patch below to get NVIDIA
>> > > drivers to work (without using any Intel graphics) on my laptop
>> > > http://pastebin.com/wpmFi38k
>> > >
>> > > Sorry - I know this is not the proper way to submit a patch, but it's
>> > > trivial and I'm not a kernel dev.
>> > >
>> > > Thanks
>> > >
>> > > ./C
>>
>>
>>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i2c: 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
- Fast-mode plus:
  the minimum HIGH period of the scl clock is 0.26us
  the minimum LOW period of the scl clock is 0.5us
- HS-mode(<1.7MHz):
  the minimum HIGH period of the scl clock is 0.12us
  the minimum LOW period of the scl clock is 0.32us
- HS-mode(<3.4MHz):
  the minimum HIGH period of the scl clock is 0.06us
  the minimum LOW period of the scl clock is 0.16us

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 formula.

Signed-off-by: Addy Ke 
---
 drivers/i2c/busses/i2c-rk3x.c | 79 +++
 1 file changed, 72 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 93cfc83..49d67b7 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -428,18 +428,83 @@ out:
return IRQ_HANDLED;
 }
 
+static void rk3x_i2c_get_ratios(unsigned long scl_rate,
+   unsigned long *high_ratio,
+   unsigned long *low_ratio)
+{
+   /* 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
+* - Fast-mode plus:
+*   the minimum HIGH period of the scl clock is 0.26us
+*   the minimum LOW period of the scl clock is 0.5us
+* - HS-mode(<1.7MHz):
+*   the minimum HIGH period of the scl clock is 0.12us
+*   the minimum LOW period of the scl clock is 0.32us
+* - HS-mode(<3.4MHz):
+*   the minimum HIGH period of the scl clock is 0.06us
+*   the minimum LOW period of the scl clock is 0.16us
+*/
+   if (scl_rate <= 10) {
+   *high_ratio = 40;
+   *low_ratio = 47;
+   } else if (scl_rate <= 40) {
+   *high_ratio = 6;
+   *low_ratio = 13;
+   } else if (scl_rate <= 100) {
+   *high_ratio = 26;
+   *low_ratio = 50;
+   } else if (scl_rate <= 170) {
+   *high_ratio = 12;
+   *low_ratio = 32;
+   } else {
+   *high_ratio = 6;
+   *low_ratio = 16;
+   }
+}
+
+static void rk3x_i2c_calc_divs(unsigned long i2c_rate, unsigned long scl_rate,
+  unsigned long *divh, unsigned long *divl)
+{
+   unsigned long high_ratio, low_ratio;
+   unsigned long ratio_sum;
+
+   rk3x_i2c_get_ratios(scl_rate, _ratio, _ratio);
+   ratio_sum = high_ratio + low_ratio;
+
+   /* T_high = T_clk * (divh + 1) * 8
+* T_low = T_clk * (divl + 1) * 8
+* T_scl = T_high + T_low
+* T_scl = 1 / scl_rate
+* T_clk = 1 / i2c_rate
+* T_high : T_low = high_ratio : low_ratio
+* ratio_sum = high_ratio + low_ratio
+*
+* so:
+* divh = (i2c_rate * high_ratio) / (scl_rate * ratio_sum * 8) - 1
+* divl = (i2c_rate * low_ratio) / (scl_rate * ratio_sum * 8) - 1
+*/
+   *divh = DIV_ROUND_UP(i2c_rate * high_ratio, scl_rate * ratio_sum * 8);
+   if (*divh)
+   *divh = *divh - 1;
+
+   *divl = DIV_ROUND_UP(i2c_rate * low_ratio, scl_rate * ratio_sum * 8);
+   if (*divl)
+   *divl = *divl - 1;
+}
+
 static void rk3x_i2c_set_scl_rate(struct rk3x_i2c *i2c, unsigned long scl_rate)
 {
unsigned long i2c_rate = clk_get_rate(i2c->clk);
-   unsigned int div;
+   unsigned long divh, divl;
 
-   /* set DIV = DIVH = DIVL
-* SCL rate = (clk rate) / (8 * (DIVH + 1 + DIVL + 1))
-*  = (clk rate) / (16 * (DIV + 1))
-*/
-   div = DIV_ROUND_UP(i2c_rate, scl_rate * 16) - 1;
+   rk3x_i2c_calc_divs(i2c_rate, scl_rate, , );
 
-   i2c_writel(i2c, (div << 16) | (div & 0x), REG_CLKDIV);
+   i2c_writel(i2c, (divh << 16) | (divl & 0x), REG_CLKDIV);
 }
 
 /**
-- 
1.8.3.2


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

RE: Boot failure caused by "mm/cma.c: free the reserved memblock when free cma pages"

[Wang, Yalin]

Hi

Very　strange,
I test it on ARM　arch,
It works well.

I think revert it is ok ,
I have a discussion with Russell,
His concern make sense,
Remove this patch is ok.
https://lkml.org/lkml/2014/9/18/171


the crash is interesting,
I will have a look.
Sorry for that ..

-Original Message-
From: Sasha Levin [mailto:sasha.le...@oracle.com] 
Sent: Wednesday, September 24, 2014 7:03 AM
To: Wang, Yalin; Minchan Kim
Cc: Michal Hocko; Hugh Dickins; Joonsoo Kim; Andrew Morton; LKML; 
linux...@kvack.org
Subject: Boot failure caused by "mm/cma.c: free the reserved memblock when free 
cma pages"

Hi Yalin,

I'm seeing the following BUG when booting the latest -next kernel. I've 
bisected it down to "mm/cma.c: free the reserved memblock when free cma pages".

[2.438701] BUG: unable to handle kernel paging request at 880972493000
[2.438701] IP: memblock_isolate_range (mm/memblock.c:624)
[2.438701] PGD 34b51067 PUD 34b54067 PMD 976c56067 PTE 800972493060
[2.438701] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[2.438701] Dumping ftrace buffer:
[2.438701](ftrace buffer empty)
[2.438701] Modules linked in:
[2.438701] CPU: 17 PID: 1 Comm: swapper/0 Not tainted 
3.17.0-rc6-next-20140923-sasha-00037-gc40eca4 #1213
[2.438701] task: 88076d7d ti: 880048d4 task.ti: 
880048d4
[2.438701] RIP: memblock_isolate_range (mm/memblock.c:624)
[2.438701] RSP: :880048d43cf8  EFLAGS: 00010286
[2.438828] RAX: 880972493000 RBX: 00096260 RCX: 880048d43d50
[2.439590] RDX: 0020 RSI: 00096240 RDI: b2fcaa30
[2.44] RBP: 880048d43d38 R08: 880048d43d54 R09: 0001
[2.44] R10:  R11: 0001 R12: 880048d43d54
[2.44] R13: 00096240 R14:  R15: b2fcaa30
[2.44] FS:  () GS:880567c0() 
knlGS:
[2.44] CS:  0010 DS:  ES:  CR0: 8005003b
[2.44] CR2: 880972493000 CR3: 31e2f000 CR4: 06a0
[2.44] Stack:
[2.44]  ad29cda2 880048d43d50 ea002eeb4000 
00096240
[2.44]  b2fcaa30  a000 
ea002eeb4008
[2.44]  880048d43d68 b049e64a 00096240 

[2.44] Call Trace:
[2.44] ? adjust_managed_page_count (mm/page_alloc.c:5430)
[2.44] memblock_remove_range (mm/memblock.c:672)
[2.44] memblock_free (mm/memblock.c:695)
[2.44] init_cma_reserved_pageblock (mm/page_alloc.c:840)
[2.44] cma_init_reserved_areas (mm/cma.c:118 mm/cma.c:133)
[2.44] ? kfree (mm/slub.c:2674 mm/slub.c:3339)
[2.44] ? early_memunmap (mm/cma.c:129)
[2.44] do_one_initcall (init/main.c:792)
[2.44] kernel_init_freeable (init/main.c:857 init/main.c:865 
init/main.c:884 init/main.c:1005)
[2.44] ? rest_init (init/main.c:932)
[2.44] kernel_init (init/main.c:937)
[2.44] ret_from_fork (arch/x86/kernel/entry_64.S:348)
[2.44] ? rest_init (init/main.c:932)
[ 2.44] Code: 89 ff e8 ec fa ff ff 85 c0 79 e1 b8 f4 ff ff ff e9 c0 00 00 
00 4c 01 eb 45 31 f6 49 63 c6 49 3b 07 73 b9 48 c1 e0 05 49 03 47 18 <48> 8b 10 
48 8b 48 08 48 8d 34 11 48 39 d3 76 a1 49 39 f5 0f 83 All code 
   0:   89 ff   mov%edi,%edi
   2:   e8 ec fa ff ff  callq  0xfaf3
   7:   85 c0   test   %eax,%eax
   9:   79 e1   jns0xffec
   b:   b8 f4 ff ff ff  mov$0xfff4,%eax
  10:   e9 c0 00 00 00  jmpq   0xd5
  15:   4c 01 ebadd%r13,%rbx
  18:   45 31 f6xor%r14d,%r14d
  1b:   49 63 c6movslq %r14d,%rax
  1e:   49 3b 07cmp(%r15),%rax
  21:   73 b9   jae0xffdc
  23:   48 c1 e0 05 shl$0x5,%rax
  27:   49 03 47 18 add0x18(%r15),%rax
  2b:*  48 8b 10mov(%rax),%rdx  <-- trapping 
instruction
  2e:   48 8b 48 08 mov0x8(%rax),%rcx
  32:   48 8d 34 11 lea(%rcx,%rdx,1),%rsi
  36:   48 39 d3cmp%rdx,%rbx
  39:   76 a1   jbe0xffdc
  3b:   49 39 f5cmp%rsi,%r13
  3e:   0f  .byte 0xf
  3f:   83  .byte 0x83
...

Code starting with the faulting instruction 
===
   0:   48 8b 10mov(%rax),%rdx
   3:   48 8b 48 08 mov0x8(%rax),%rcx
   7:   48 8d 34 11 lea(%rcx,%rdx,1),%rsi
   b:   48 39 d3cmp%rdx,%rbx
   e:   76 a1   jbe0xffb1
  10:   49 39 f5cmp%rsi,%r13
  13:   0f   

[PATCH] parisc:Remove unnecessary FIXMES in init.c

[Nicholas Krause]

This removes the two fixmes in the file, init.c for compiler hints
for comments related to compiler hints in linux_gateway_page_addr
and map_hpux_gateway_page to change from FIXME to HINT in order
for people reading this code to understand that these are compiler
hints.

Signed-off-by: Nicholas Krause 
---
 arch/parisc/mm/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index 0bef864..668102e 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -733,7 +733,7 @@ static void __init pagetable_init(void)
 static void __init gateway_init(void)
 {
unsigned long linux_gateway_page_addr;
-   /* FIXME: This is 'const' in order to trick the compiler
+   /* HINT: This is 'const' in order to trick the compiler
   into not treating it as DP-relative data. */
extern void * const linux_gateway_page;
 
@@ -761,7 +761,7 @@ map_hpux_gateway_page(struct task_struct *tsk, struct 
mm_struct *mm)
unsigned long start_pte;
unsigned long address;
unsigned long hpux_gw_page_addr;
-   /* FIXME: This is 'const' in order to trick the compiler
+   /* HINT: This is 'const' in order to trick the compiler
   into not treating it as DP-relative data. */
extern void * const hpux_gateway_page;
 
-- 
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 v12 10/12] PCI: Assign unassigned bus resources in pci_scan_root_bus()

[Liviu Dudau]

On Tue, Sep 23, 2014 at 07:41:35PM -0600, Bjorn Helgaas wrote:
> On Tue, Sep 23, 2014 at 7:18 PM, Liviu Dudau  wrote:
> > On Tue, Sep 23, 2014 at 08:01:12PM +0100, Liviu Dudau wrote:
> >> If the firmware has not assigned all the bus resources and
> >> we are not just probing the PCIe busses, it makes sense to
> >> assign the unassigned resources in pci_scan_root_bus().
> >>
> >> Cc: Bjorn Helgaas 
> >> Cc: Arnd Bergmann 
> >> Cc: Jason Gunthorpe 
> >> Cc: Rob Herring 
> >> Signed-off-by: Liviu Dudau 
> >> ---
> >>  drivers/pci/probe.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> >> index ef891d2..508cf61 100644
> >> --- a/drivers/pci/probe.c
> >> +++ b/drivers/pci/probe.c
> >> @@ -1953,6 +1953,9 @@ struct pci_bus *pci_scan_root_bus(struct device 
> >> *parent, int bus,
> >>   if (!found)
> >>   pci_bus_update_busn_res_end(b, max);
> >>
> >> + if (!pci_has_flag(PCI_PROBE_ONLY))
> >> + pci_assign_unassigned_bus_resources(b);
> >> +
> >>   pci_bus_add_devices(b);
> >>   return b;
> >>  }
> >> --
> >> 2.1.0
> >>
> >
> > Bjorn,
> >
> > If you are OK with this patch, can you let me know how do you feel about
> > making pci_scan_root_bus() set up the bus->msi pointer as well?
> 
> I'm not opposed to it, but I have the same question as for setting up
> the domain: how does pci_scan_root_bus() learn what to assign to
> bus->msi?  It currently only gets a "void *sysdata" so there's no
> obvious place to put it there.  You could add a pcibios interface to
> retrieve it, I suppose, but I'm starting to get uncomfortable with
> adding more of those because we have such a mess of them already.

My long term view is that the creation of the pci_host_bridge structure
needs to be separated from the creation and scanning of the root bus.
Then we can add host bridge ops or some other API to the structure
that should allow for less friction in passing information to the bridge.

Best regards,
Liviu

> 
> Bjorn
> 
> > Side note: I don't know exactly how to do it now, but setting bus->msi is
> > needed by platforms that are based on my patches and want to use MSI,
> > otherwise they have to open code pci_scan_root_bus() to set it. I haven't
> > made any attempts to do it in this series as the GICv2m patches are not
> > ready yet, but I can see the need arriving soon.
> >
> > Best regards,
> > Liviu
> >
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>

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

Re: [PATCH v6 1/2] regulator: st-pwm: get voltage and duty table from dts

[Chris Zhong]

On 09/24/2014 07:43 AM, Doug Anderson wrote:

Chris,

On Tue, Sep 23, 2014 at 8:53 AM, Chris Zhong  wrote:

Get voltage & duty table from device tree might be better, other platforms can 
also use this
driver without any modify.

Signed-off-by: Chris Zhong 
Reviewed-by: Doug Anderson 

I finally managed to get everything setup and I've now tested this
myself on an rk3288-based board.

Tested-by: Doug Anderson 

I'd imagine the next step is for Lee to comment on the patch and when
he's happy with it Mark Brown will land it?


One thing that's still a bit odd (though no different than the
behavior of the driver from before you touched it, so it shouldn't
block landing IMHO) is that at boot time this regulator will report
that it's at the highest voltage but the voltage won't actually change
until the first client sets the voltage.
Yes, I knew this problem, since the default of duty cycle is 0, not a 
true value.

If we can get duty from pwm, this regulator will report a correct voltage.


Also: if anyone reading is interested in this patch, it's possible
you'll also be interested in my patch at
 to make sue that your
voltage doesn't twiddle around at probe time.


-Doug





--
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 v12 10/12] PCI: Assign unassigned bus resources in pci_scan_root_bus()

[Bjorn Helgaas]

On Tue, Sep 23, 2014 at 7:18 PM, Liviu Dudau  wrote:
> On Tue, Sep 23, 2014 at 08:01:12PM +0100, Liviu Dudau wrote:
>> If the firmware has not assigned all the bus resources and
>> we are not just probing the PCIe busses, it makes sense to
>> assign the unassigned resources in pci_scan_root_bus().
>>
>> Cc: Bjorn Helgaas 
>> Cc: Arnd Bergmann 
>> Cc: Jason Gunthorpe 
>> Cc: Rob Herring 
>> Signed-off-by: Liviu Dudau 
>> ---
>>  drivers/pci/probe.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index ef891d2..508cf61 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1953,6 +1953,9 @@ struct pci_bus *pci_scan_root_bus(struct device 
>> *parent, int bus,
>>   if (!found)
>>   pci_bus_update_busn_res_end(b, max);
>>
>> + if (!pci_has_flag(PCI_PROBE_ONLY))
>> + pci_assign_unassigned_bus_resources(b);
>> +
>>   pci_bus_add_devices(b);
>>   return b;
>>  }
>> --
>> 2.1.0
>>
>
> Bjorn,
>
> If you are OK with this patch, can you let me know how do you feel about
> making pci_scan_root_bus() set up the bus->msi pointer as well?

I'm not opposed to it, but I have the same question as for setting up
the domain: how does pci_scan_root_bus() learn what to assign to
bus->msi?  It currently only gets a "void *sysdata" so there's no
obvious place to put it there.  You could add a pcibios interface to
retrieve it, I suppose, but I'm starting to get uncomfortable with
adding more of those because we have such a mess of them already.

Bjorn

> Side note: I don't know exactly how to do it now, but setting bus->msi is
> needed by platforms that are based on my patches and want to use MSI,
> otherwise they have to open code pci_scan_root_bus() to set it. I haven't
> made any attempts to do it in this series as the GICv2m patches are not
> ready yet, but I can see the need arriving soon.
>
> Best regards,
> Liviu
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> ---
>.oooO
>(   )
> \ (  Oooo.
>  \_) (   )
>   ) /
>  (_/
>
>  One small step
>for me ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] watchdog: dw_wdt: add restart handler support

[Guenter Roeck]

On 09/23/2014 06:11 PM, Jisheng Zhang wrote:
[ ... ]

+   dw_wdt.restart_handler.notifier_call = dw_wdt_restart_handle;
+   dw_wdt.restart_handler.priority = 128;
+   ret = register_restart_handler(_wdt.restart_handler);
+   if (ret)
+   pr_warn("cannot register restart handler\n");


Please use dev_warn(>dev, ...).


Yep, that's what I thought when patching the code. But the original source is
using pr_*(), so I use pr_warn() to keep unification. Is there any better
solution?



Good point. Makes sense, then, to leave that as cleanup.

Reviewed-by: Guenter Roeck 

--
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] perf tools: modify error code when perf_session__new() fail.

[Taeung Song]

Because perf_session__new() could fail for more reasons than just ENOMEM,
I modified error code(ENOMEM or EINVAL) into -1.

Signed-off-by: Taeung Song 
---
 tools/perf/builtin-annotate.c  | 2 +-
 tools/perf/builtin-diff.c  | 2 +-
 tools/perf/builtin-evlist.c| 2 +-
 tools/perf/builtin-inject.c| 2 +-
 tools/perf/builtin-kmem.c  | 2 +-
 tools/perf/builtin-kvm.c   | 4 ++--
 tools/perf/builtin-lock.c  | 2 +-
 tools/perf/builtin-mem.c   | 2 +-
 tools/perf/builtin-report.c| 2 +-
 tools/perf/builtin-script.c| 2 +-
 tools/perf/builtin-timechart.c | 2 +-
 tools/perf/builtin-top.c   | 2 +-
 tools/perf/builtin-trace.c | 2 +-
 13 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index d4da692..be59394 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -340,7 +340,7 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
annotate.session = perf_session__new(, false, );
if (annotate.session == NULL)
-   return -ENOMEM;
+   return -1;
 
symbol_conf.priv_size = sizeof(struct annotation);
symbol_conf.try_vmlinux_path = true;
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 190d0b6..a3ce19f 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -683,7 +683,7 @@ static int __cmd_diff(void)
d->session = perf_session__new(>file, false, );
if (!d->session) {
pr_err("Failed to open %s\n", d->file.path);
-   ret = -ENOMEM;
+   ret = -1;
goto out_delete;
}
 
diff --git a/tools/perf/builtin-evlist.c b/tools/perf/builtin-evlist.c
index 66e12f5..0f93f85 100644
--- a/tools/perf/builtin-evlist.c
+++ b/tools/perf/builtin-evlist.c
@@ -28,7 +28,7 @@ static int __cmd_evlist(const char *file_name, struct 
perf_attr_details *details
 
session = perf_session__new(, 0, NULL);
if (session == NULL)
-   return -ENOMEM;
+   return -1;
 
evlist__for_each(session->evlist, pos)
perf_evsel__fprintf(pos, details, stdout);
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 3a62b6b..de99ca1 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -460,7 +460,7 @@ int cmd_inject(int argc, const char **argv, const char 
*prefix __maybe_unused)
file.path = inject.input_name;
inject.session = perf_session__new(, true, );
if (inject.session == NULL)
-   return -ENOMEM;
+   return -1;
 
if (symbol__init(>header.env) < 0)
return -1;
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 2376218..f295141 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -698,7 +698,7 @@ int cmd_kmem(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
session = perf_session__new(, false, _kmem);
if (session == NULL)
-   return -ENOMEM;
+   return -1;
 
symbol__init(>header.env);
 
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index f5d3ae4..fd84d47 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1062,7 +1062,7 @@ static int read_events(struct perf_kvm_stat *kvm)
kvm->session = perf_session__new(, false, >tool);
if (!kvm->session) {
pr_err("Initializing perf session failed\n");
-   return -EINVAL;
+   return -1;
}
 
symbol__init(>session->header.env);
@@ -1365,7 +1365,7 @@ static int kvm_events_live(struct perf_kvm_stat *kvm,
 */
kvm->session = perf_session__new(, false, >tool);
if (kvm->session == NULL) {
-   err = -ENOMEM;
+   err = -1;
goto out;
}
kvm->session->evlist = kvm->evlist;
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 92790ed..e7ec715 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -862,7 +862,7 @@ static int __cmd_report(bool display_info)
session = perf_session__new(, false, );
if (!session) {
pr_err("Initializing perf session failed\n");
-   return -ENOMEM;
+   return -1;
}
 
symbol__init(>header.env);
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index 8b4a87f..24db6ff 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -124,7 +124,7 @@ static int report_raw_events(struct perf_mem *mem)
 >tool);
 
if (session == NULL)
-   return -ENOMEM;
+   return -1;
 
if (mem->cpu_list) {
ret = 

Re: [PATCH] lib: string.c: Added a funktion function strzcpy

[Andi Kleen]

On Wed, Sep 24, 2014 at 12:13:36AM +0200, Rickard Strandqvist wrote:
> Added a function strzcpy which works the same as strncpy,
> but guaranteed to produce the trailing null character.

Do we really need the bizarre strncpy padding semantics for anything? 
Why not just use strlcpy?

-Andi
--
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] virtio_pci: fix virtio spec compliance on restore

[Ben Hutchings]

On Tue, 2014-09-23 at 13:32 +0300, Michael S. Tsirkin wrote:
> On restore, virtio pci does the following:
> + set features
> + init vqs etc - device can be used at this point!
> + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits
> 
> This is in violation of the virtio spec, which
> requires the following order:
> - ACKNOWLEDGE
> - DRIVER
> - init vqs
> - DRIVER_OK
>
> Cc: sta...@vger.kernel.org
> Cc: Amit Shah 
> Signed-off-by: Michael S. Tsirkin 
[...]

What concrete problem does this fix, such that it should be applied to
stable branches?

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part

Re: [PATCH v12 10/12] PCI: Assign unassigned bus resources in pci_scan_root_bus()

[Liviu Dudau]

On Tue, Sep 23, 2014 at 08:01:12PM +0100, Liviu Dudau wrote:
> If the firmware has not assigned all the bus resources and
> we are not just probing the PCIe busses, it makes sense to
> assign the unassigned resources in pci_scan_root_bus().
> 
> Cc: Bjorn Helgaas 
> Cc: Arnd Bergmann 
> Cc: Jason Gunthorpe 
> Cc: Rob Herring 
> Signed-off-by: Liviu Dudau 
> ---
>  drivers/pci/probe.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ef891d2..508cf61 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1953,6 +1953,9 @@ struct pci_bus *pci_scan_root_bus(struct device 
> *parent, int bus,
>   if (!found)
>   pci_bus_update_busn_res_end(b, max);
>  
> + if (!pci_has_flag(PCI_PROBE_ONLY))
> + pci_assign_unassigned_bus_resources(b);
> +
>   pci_bus_add_devices(b);
>   return b;
>  }
> -- 
> 2.1.0
> 

Bjorn,

If you are OK with this patch, can you let me know how do you feel about
making pci_scan_root_bus() set up the bus->msi pointer as well?

Side note: I don't know exactly how to do it now, but setting bus->msi is
needed by platforms that are based on my patches and want to use MSI,
otherwise they have to open code pci_scan_root_bus() to set it. I haven't
made any attempts to do it in this series as the GICv2m patches are not
ready yet, but I can see the need arriving soon.

Best regards,
Liviu

> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
---
   .oooO
   (   )
\ (  Oooo.
 \_) (   )
  ) /
 (_/

 One small step
   for me ...

--
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 1/4] ftracetest: Initial commit for ftracetest

[Masami Hiramatsu]

(2014/09/23 22:36), Steven Rostedt wrote:
> For future reference:
> 
> On Mon, 22 Sep 2014 23:42:50 +
> Masami Hiramatsu  wrote:
> 
>> ftracetest is a collection of testcase shell-scripts for ftrace.
>> To avoid regressions of ftrace, these testcases check correct
>> ftrace behaviors. If someone would like to add any features on
>> ftrace, the patch series should have at least one testcase for
>> checking the new behavior.
>>
>> Changes in v5:
>>  - Fix a TODO item, since this already integrated to kselftest.
>>  - Print the test name at the first line.
>>
>> Changes in v4:
>>  - Move this under selftests. :)
>>  - Add a copyright and note of GPLv2.
>>  - Fix documents acconding to Steven's comments.
>>  - Fix a small bug pointed by Namhyng.
>>
>> Changes in v3:
>>  - Use "." instead of "source".
>>  - Don't use -e option for echo since dash doesn't support it.
>>
>> Changes in v2:
>>  - Remove unneeded 'function' keyword.
>>  - Add abspath and find_testcases.
>>  - Make OPT_TEST_CASES a local var.
>>  - Ensure given testcase ended with .tc.
>>  - Accept a directory option which has multiple testcases.
>>  - Change [PASSED]/[FAILED] to [PASS]/[FAIL]
>>  - Change the basic shell to sh (dash).
> 
> Place the version changes after the '---'. They are great for patch
> series, but we prefer not to have them in the git logs. The "Link:" tag
> should allow people to find the version history of patches if they are
> interested. By placing the version updates after the '---', git will
> ignore them when pulling them in.

Ah, I see :)
For the next series, I'll do that.

> 
>>
>> Signed-off-by: Masami Hiramatsu 
>> Acked-by: Shuah Khan 
>> ---
> 
> Also, please have the Signed-off-by be the last tag, otherwise it
> screws up my scripts ;-)

OK.

Thank you!

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH v12 05/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Bjorn Helgaas]

On Tue, Sep 23, 2014 at 7:12 PM, Liviu Dudau  wrote:
> On Tue, Sep 23, 2014 at 06:22:53PM -0600, Bjorn Helgaas wrote:
>> [+cc Andrew]
>>
>> On Tue, Sep 23, 2014 at 08:01:07PM +0100, Liviu Dudau wrote:
>> > The ranges property for a host bridge controller in DT describes
>> > the mapping between the PCI bus address and the CPU physical address.
>> > The resources framework however expects that the IO resources start
>> > at a pseudo "port" address 0 (zero) and have a maximum size of 
>> > IO_SPACE_LIMIT.
>> > The conversion from pci ranges to resources failed to take that into 
>> > account,
>> > returning a CPU physical address instead of a port number.
>> >
>> > Also fix all the drivers that depend on the old behaviour by fetching
>> > the CPU physical address based on the port number where it is being needed.
>> >
>> > Cc: Grant Likely 
>> > Cc: Rob Herring 
>> > Cc: Arnd Bergmann 
>> > Acked-by: Linus Walleij 
>> > Cc: Thierry Reding 
>> > Cc: Simon Horman 
>> > Cc: Catalin Marinas 
>> > Signed-off-by: Liviu Dudau 
>> > ---
>> >  arch/arm/mach-integrator/pci_v3.c | 23 ++--
>> >  drivers/of/address.c  | 44 
>> > +++
>> >  drivers/pci/host/pci-tegra.c  | 10 ++---
>> >  drivers/pci/host/pcie-rcar.c  | 21 +--
>> >  include/linux/of_address.h| 15 ++---
>> >  5 files changed, 82 insertions(+), 31 deletions(-)
>> > ...
>>
>> The of_pci_range_to_resource() implementation in drivers/of/address.c is
>> always compiled when CONFIG_OF_ADDRESS=y, but when CONFIG_OF_ADDRESS=y and
>> CONFIG_PCI is not set, we get the static inline version from
>> include/linux/of_address.h as well, causing a redefinition error.
>>
>> > diff --git a/drivers/of/address.c b/drivers/of/address.c
>> > @@ -957,12 +957,48 @@ bool of_dma_is_coherent(struct device_node *np)
>> > ...
>> > +int of_pci_range_to_resource(struct of_pci_range *range,
>> > +   struct device_node *np, struct resource *res)
>>
>> > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
>> > ...
>> >  #else /* CONFIG_OF_ADDRESS && CONFIG_PCI */
>> >  static inline int of_pci_address_to_resource(struct device_node *dev, int 
>> > bar,
>> >  struct resource *r)
>> > @@ -144,6 +139,12 @@ static inline int of_pci_address_to_resource(struct 
>> > device_node *dev, int bar,
>> > return -ENOSYS;
>> >  }
>> >
>> > +static inline int of_pci_range_to_resource(struct of_pci_range *range,
>> > +   struct device_node *np, struct resource *res)
>> > +{
>> > +   return -ENOSYS;
>> > +}
>>
>> My proposal to fix it is the following three patches.  The first moves the
>> inline version of of_pci_range_to_resource() into the existing "#if
>> defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)" block.
>>
>> Andrew added it (and some other PCI-related things) with 29b635c00f3e
>> ("of/pci: Provide support for parsing PCI DT ranges property") to
>> of_address.h outside of any ifdefs, so it's always available.  Maybe
>> there's a reason that's needed in the non-CONFIG_PCI case, but I didn't see
>> it with a quick look.
>>
>> The second moves of_pci_range_to_resource() to address.c, still inside the
>> "#ifdef CONFIG_PCI" block.
>
> Hi Bjorn,
>
> Looks good to me. Sorry for messing this up, I've tested a combination of
> CONFIG_PCI=y and CONFIG_PCI=n but it looks like I've only tested
> CONFIG_OF_ADDRESS=CONFIG_PCI (both enabled or both disabled).

You probably saw the subsequent [pci:pci/host-generic 10/13]
drivers/of/of_pci.c:202:3: error: implicit declaration of function
'of_pci_range_to_resource' error.

I looked at that a bit, but gave up.  Apparently drivers/of/of_pci.c
can be compiled with CONFIG_PCI=y but CONFIG_OF_ADDRESS not set..

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

Re: [PATCH v2 2/2] watchdog: dw_wdt: add restart handler support

[Jisheng Zhang]

Dear Guenter,

On Tue, 23 Sep 2014 11:31:59 -0700
Guenter Roeck  wrote:

> On Tue, Sep 23, 2014 at 03:42:12PM +0800, Jisheng Zhang wrote:
> > The kernel core now provides an API to trigger a system restart.
> > Register with it to support restarting the system via. watchdog.
> > 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  drivers/watchdog/dw_wdt.c | 32 
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
> > index 449c885..9e577a6 100644
> > --- a/drivers/watchdog/dw_wdt.c
> > +++ b/drivers/watchdog/dw_wdt.c
> > @@ -21,6 +21,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -29,9 +30,11 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -63,6 +66,7 @@ static struct {
> > unsigned long   next_heartbeat;
> > struct timer_list   timer;
> > int expect_close;
> > +   struct notifier_block   restart_handler;
> >  } dw_wdt;
> >  
> >  static inline int dw_wdt_is_enabled(void)
> > @@ -121,6 +125,26 @@ static void dw_wdt_keepalive(void)
> >WDOG_COUNTER_RESTART_REG_OFFSET);
> >  }
> >  
> > +static int dw_wdt_restart_handle(struct notifier_block *this,
> > +   unsigned long mode, void *cmd)
> > +{
> > +   u32 val;
> > +
> > +   writel(0, dw_wdt.regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
> > +   val = readl(dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
> > +   if (val & WDOG_CONTROL_REG_WDT_EN_MASK)
> > +   writel(WDOG_COUNTER_RESTART_KICK_VALUE, dw_wdt.regs +
> > +   WDOG_COUNTER_RESTART_REG_OFFSET);
> > +   else
> > +   writel(WDOG_CONTROL_REG_WDT_EN_MASK,
> > +  dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
> > +
> > +   /* wait for reset to assert... */
> > +   mdelay(500);
> > +
> > +   return NOTIFY_DONE;
> > +}
> > +
> >  static void dw_wdt_ping(unsigned long data)
> >  {
> > if (time_before(jiffies, dw_wdt.next_heartbeat) ||
> > @@ -316,6 +340,12 @@ static int dw_wdt_drv_probe(struct platform_device
> > *pdev) if (ret)
> > goto out_disable_clk;
> >  
> > +   dw_wdt.restart_handler.notifier_call = dw_wdt_restart_handle;
> > +   dw_wdt.restart_handler.priority = 128;
> > +   ret = register_restart_handler(_wdt.restart_handler);
> > +   if (ret)
> > +   pr_warn("cannot register restart handler\n");
> 
> Please use dev_warn(>dev, ...).

Yep, that's what I thought when patching the code. But the original source is
using pr_*(), so I use pr_warn() to keep unification. Is there any better
solution?

Thanks for your review,
Jisheng

> 
> Thanks,
> Guenter
> 
> > +
> > dw_wdt_set_next_heartbeat();
> > setup_timer(_wdt.timer, dw_wdt_ping, 0);
> > mod_timer(_wdt.timer, jiffies + WDT_TIMEOUT);
> > @@ -330,6 +360,8 @@ out_disable_clk:
> >  
> >  static int dw_wdt_drv_remove(struct platform_device *pdev)
> >  {
> > +   unregister_restart_handler(_wdt.restart_handler);
> > +
> > misc_deregister(_wdt_miscdev);
> >  
> > clk_disable_unprepare(dw_wdt.clk);
> > -- 
> > 2.1.0
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-watchdog"
> > in the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH v12 05/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Liviu Dudau]

On Tue, Sep 23, 2014 at 06:22:53PM -0600, Bjorn Helgaas wrote:
> [+cc Andrew]
> 
> On Tue, Sep 23, 2014 at 08:01:07PM +0100, Liviu Dudau wrote:
> > The ranges property for a host bridge controller in DT describes
> > the mapping between the PCI bus address and the CPU physical address.
> > The resources framework however expects that the IO resources start
> > at a pseudo "port" address 0 (zero) and have a maximum size of 
> > IO_SPACE_LIMIT.
> > The conversion from pci ranges to resources failed to take that into 
> > account,
> > returning a CPU physical address instead of a port number.
> > 
> > Also fix all the drivers that depend on the old behaviour by fetching
> > the CPU physical address based on the port number where it is being needed.
> > 
> > Cc: Grant Likely 
> > Cc: Rob Herring 
> > Cc: Arnd Bergmann 
> > Acked-by: Linus Walleij 
> > Cc: Thierry Reding 
> > Cc: Simon Horman 
> > Cc: Catalin Marinas 
> > Signed-off-by: Liviu Dudau 
> > ---
> >  arch/arm/mach-integrator/pci_v3.c | 23 ++--
> >  drivers/of/address.c  | 44 
> > +++
> >  drivers/pci/host/pci-tegra.c  | 10 ++---
> >  drivers/pci/host/pcie-rcar.c  | 21 +--
> >  include/linux/of_address.h| 15 ++---
> >  5 files changed, 82 insertions(+), 31 deletions(-)
> > ...
> 
> The of_pci_range_to_resource() implementation in drivers/of/address.c is
> always compiled when CONFIG_OF_ADDRESS=y, but when CONFIG_OF_ADDRESS=y and
> CONFIG_PCI is not set, we get the static inline version from
> include/linux/of_address.h as well, causing a redefinition error.
> 
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > @@ -957,12 +957,48 @@ bool of_dma_is_coherent(struct device_node *np)
> > ...
> > +int of_pci_range_to_resource(struct of_pci_range *range,
> > +   struct device_node *np, struct resource *res)
> 
> > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> > ...
> >  #else /* CONFIG_OF_ADDRESS && CONFIG_PCI */
> >  static inline int of_pci_address_to_resource(struct device_node *dev, int 
> > bar,
> >  struct resource *r)
> > @@ -144,6 +139,12 @@ static inline int of_pci_address_to_resource(struct 
> > device_node *dev, int bar,
> > return -ENOSYS;
> >  }
> >  
> > +static inline int of_pci_range_to_resource(struct of_pci_range *range,
> > +   struct device_node *np, struct resource *res)
> > +{
> > +   return -ENOSYS;
> > +}
> 
> My proposal to fix it is the following three patches.  The first moves the
> inline version of of_pci_range_to_resource() into the existing "#if
> defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)" block.
> 
> Andrew added it (and some other PCI-related things) with 29b635c00f3e
> ("of/pci: Provide support for parsing PCI DT ranges property") to
> of_address.h outside of any ifdefs, so it's always available.  Maybe
> there's a reason that's needed in the non-CONFIG_PCI case, but I didn't see
> it with a quick look.
> 
> The second moves of_pci_range_to_resource() to address.c, still inside the
> "#ifdef CONFIG_PCI" block.

Hi Bjorn,

Looks good to me. Sorry for messing this up, I've tested a combination of
CONFIG_PCI=y and CONFIG_PCI=n but it looks like I've only tested
CONFIG_OF_ADDRESS=CONFIG_PCI (both enabled or both disabled).

Best regards,
Liviu

> 
> Bjorn
> 
> 
> commit 95a60df1c2d400c676ab1d20271735e2b4735437
> Author: Bjorn Helgaas 
> Date:   Tue Sep 23 17:27:42 2014 -0600
> 
> of/pci: Define of_pci_range_to_resource() only when CONFIG_PCI=y
> 
> of_pci_range_to_resource() was previously defined always, but it's only
> used by PCI code, so move the definition inside the CONFIG_OF_ADDRESS &&
> CONFIG_PCI block.
> 
> Signed-off-by: Bjorn Helgaas 
> 
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index f8cc7daa420c..ecf913cf53b2 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -23,17 +23,6 @@ struct of_pci_range {
>  #define for_each_of_pci_range(parser, range) \
>   for (; of_pci_range_parser_one(parser, range);)
>  
> -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> - struct device_node *np,
> - struct resource *res)
> -{
> - res->flags = range->flags;
> - res->start = range->cpu_addr;
> - res->end = range->cpu_addr + range->size - 1;
> - res->parent = res->child = res->sibling = NULL;
> - res->name = np->full_name;
> -}
> -
>  /* Translate a DMA address from device space to CPU space */
>  extern u64 of_translate_dma_address(struct device_node *dev,
>   const __be32 *in_addr);
> @@ -140,6 +129,18 @@ extern const __be32 *of_get_pci_address(struct 
> device_node *dev, int bar_no,
>  u64 *size, unsigned int *flags);
>  extern int 

linux-next: build failure after merge of the samsung tree

[Stephen Rothwell]

Hi Kukjin,

After merging the samsung tree, today's linux-next build (arm 
multi_v7_defconfig)
failed like this:

arch/arm/boot/dts/exynos5250-snow.dts:13:46: fatal error: 
dt-bindings/clock/maxim,max77686.h: No such file or directory
 #include 
  ^

Caused by commit c04c92ed5614 ("ARM: dts: Add rtc_src clk for s3c-rtc on 
exynos5250-snow").

In file included from arch/arm/mach-tegra/cpuidle-tegra114.c:17:0:
arch/arm/mach-tegra/cpuidle-tegra114.c: In function 'tegra114_idle_power_down':
arch/arm/include/asm/firmware.h:64:24: error: too few arguments to function 
'firmware_ops->do_idle'
  ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
^
arch/arm/mach-tegra/cpuidle-tegra114.c:52:6: note: in expansion of macro 
'call_firmware_op'
  if (call_firmware_op(do_idle) == -ENOSYS)
  ^

Caused by commit f5217f3b9332 ("ARM: EXYNOS: add AFTR mode support to
firmware do_idle method").

I have used the samsung tree from next-20140923 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH 2/2] perf callchain: Use global caching provided by libunwind

[Namhyung Kim]

On Tue, 23 Sep 2014 21:53:43 +0900, Namhyung Kim wrote:
> On Tue, Sep 23, 2014 at 9:28 PM, Jiri Olsa  wrote:
>> On Tue, Sep 23, 2014 at 03:30:28PM +0900, Namhyung Kim wrote:
>>> The libunwind provides two caching policy which are global and
>>> per-thread.  As perf unwinds callchains in a single thread, it'd
>>> sufficient to use global caching.
>>>
>>> This speeds up my perf report from 14s to 7s on a ~260MB data file.
>>> Although the output contains a slight difference (~0.01% in terms of
>>> number of lines printed) on callchains which were not resolved.
>>
>> hum, the speedup is nice, but what was the diff output.. any example?
>> The new version does not print some lines or different ones?
>
> I don't have the result now - will post the diff when I go to the
> office tomorrow.  But IIRC new version only adds new lines..

Okay, this is the result..  But it doesn't always make a difference.  I
can see it produces exactly same output for other (even bigger) data files.


  $ diff -U0 callchain-result.{old,new}
  --- callchain-result.old  2014-09-23 14:52:29.630711402 +0900
  +++ callchain-result.new  2014-09-23 14:52:52.709505500 +0900
  @@ -5322,0 +5323,9 @@
  +  |  |  |  
  +  |  |   --0.00%-- 0x406520
  +  |  | 0x4064f0
  +  |  | |  
  +  |  | |--0.00%-- 
0x1ad52a0
  +  |  | |  
  +  |  | |--0.00%-- 
0x1a0f2e0
  +  |  | |  
  +  |  |  --0.00%-- 
0x1a9e0c0
  @@ -108899,0 +108909,3 @@
  +|  |  0x406520
  +|  |  0x4064f0
  +|  |  0x1a9e0c0
  @@ -180410,0 +180423,9 @@
  +  |  |  
  +  |   --0.00%-- 0x406520
  +  | 0x4064f0
  +  | |  
  +  | |--0.00%-- 0x1ad52a0
  +  | |  
  +  | |--0.00%-- 0x1a0f2e0
  +  | |  
  +  |  --0.00%-- 0x1a9e0c0
  
  $ wc -l callchain-result.{old,new}
191412 callchain-result.old
191433 callchain-result.new
382845 total


Thanks,
Namhyung
--
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 linux-next] Documentation: mic: mpssd: Disable mpssd builds for kernels < 3.13

[Peter Foley]

On Tue, Sep 23, 2014 at 8:51 PM, Andrew Morton
 wrote:
> Can't we just fix the Makefiles?  Cook up a rule which makes
> headers_install (if needed) before building Documentation/?

Currently, the ordering is enforced by
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Makefile#n946
I'll take a look at making Documentation/ depend on headers_install.

Thanks,

Peter
--
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/3] gpio: sch: Consolidate similar algorithms

[Chang, Rebecca Swee Fun]

> -Original Message-
> From: 'Mika Westerberg' [mailto:mika.westerb...@linux.intel.com]
> Sent: 22 September, 2014 5:25 PM
> To: Chang, Rebecca Swee Fun
> Cc: Linus Walleij; linux-g...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/3] gpio: sch: Consolidate similar algorithms
> 
> On Mon, Sep 22, 2014 at 05:43:36AM +, Chang, Rebecca Swee Fun wrote:
> > Replied inline. :)
> >
> > > -Original Message-
> > > From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> > > Sent: 18 September, 2014 7:17 PM
> > > To: Chang, Rebecca Swee Fun
> > > Cc: Linus Walleij; linux-g...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH 1/3] gpio: sch: Consolidate similar algorithms
> > >
> > > On Wed, Sep 17, 2014 at 04:49:03PM +0800, Chang Rebecca Swee Fun
> wrote:
> > > > Consolidating similar algorithms into common functions to make
> > > > GPIO SCH simpler and manageable.
> > > >
> > > > Signed-off-by: Chang Rebecca Swee Fun
> > > > 
> > > > ---
> > > >  drivers/gpio/gpio-sch.c |   95 
> > > > ++---
> -
> > > -
> > > >  1 file changed, 53 insertions(+), 42 deletions(-)
> > > >
> > > > diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
> > > > index
> > > > 99720c8..2189c22 100644
> > > > --- a/drivers/gpio/gpio-sch.c
> > > > +++ b/drivers/gpio/gpio-sch.c
> > > > @@ -43,6 +43,8 @@ struct sch_gpio {
> > > >
> > > >  #define to_sch_gpio(c) container_of(c, struct sch_gpio, chip)
> > > >
> > > > +static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num,
> > > > +int val);
> > > > +
> > >
> > > Is it possible to move the sch_gpio_set() function here instead of
> > > forward declaring it?
> >
> > Yes, it is possible. There is a reason I submitted the code in this
> > structure. By putting the sch_gpio_set() function below will makes the
> > diff patch looks neat and easy for review.  If it doesn't make sense
> > to make the patch for easy reviewing, I can change by moving the
> > function above.
> 
> I think that we are interested in the end result (e.g) the driver and if we 
> can
> avoid forward declarations the better.

Alright. I can move it up to avoid the forward declaration.

> 
> > >
> > > >  static unsigned sch_gpio_offset(struct sch_gpio *sch, unsigned gpio,
> > > > unsigned reg)
> > > >  {
> > > > @@ -63,94 +65,89 @@ static unsigned sch_gpio_bit(struct sch_gpio
> > > > *sch,
> > > unsigned gpio)
> > > > return gpio % 8;
> > > >  }
> > > >
> > > > -static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio)
> > > > +static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio,
> > > > +unsigned reg)
> > >
> > > I don't see much value in doing this.
> > >
> > > To me sch_gpio_enable(sch, gpio) is more intuitive than
> > > sch_gpio_enable(sch, gpio, GEN). Why do I need to pass register to enable
> function in the first place?
> > > It should know better how to enable the GPIO, right?
> > >
> > > Same goes for others.
> >
> > The register values are required when it comes to IRQ handling. By
> > passing in the registers values, we can make full use of the
> > algorithms without introducing extra/similar algorithms to compute
> > other register offset values.
> > For example, we have other offset values to handle such as:-
> > GTPE0x0C
> > GTNE0x10
> > GGPE0x14
> > GSMI0x18
> > GTS 0x1C
> > CGNMIEN 0x40
> > RGNMIEN 0x44
> 
> Well, can we at least call it something else than sch_gpio_enable()?
> Perhaps sch_gpio_set_value() or so?

sch_gpio_set_value() sounds good. After think twice, I intend to merge 
sch_gpio_enable() and sch_gpio_disable() into one functions. Using variable 
"enable" as an indicator, I can control whether to enable or disable when 
calling the function. Here is my draft:

static void sch_gpio_set_value(struct sch_gpio *sch, unsigned gpio, unsigned 
reg, unsigned int enable)
{
unsigned long flags;
unsigned short offset, bit;
u8 set;

spin_lock_irqsave(>lock, flags);
offset = sch_gpio_offset(sch, gpio, reg);
bit = sch_gpio_bit(sch, gpio);

set = inb(sch->iobase + offset); 
if (enable)
outb(set | BIT(bit), sch->iobase + offset);
else
outb(disable & ~BIT(bit), sch->iobase + offset);

spin_unlock_irqrestore(>lock, flags);
}

Do you think this make sense? I am in the progress of implementing and testing.

Rebecca
--
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/3 v2] drivers/bus: Added Freescale Management Complex APIs

[Kim Phillips]

On Fri, 19 Sep 2014 17:49:39 -0500
"J. German Rivera"  wrote:

> +int mc_get_version(struct fsl_mc_io *mc_io, struct mc_version *mc_ver_info)
...
> + err = mc_send_command(mc_io, );
> + if (err)
> + return err;
> +
> + DPMNG_RSP_GET_VERSION(cmd, mc_ver_info);

alignment

> +int dpmng_load_aiop(struct fsl_mc_io *mc_io,
> + int aiop_tile_id, uint8_t *img_addr, int img_size)
> +{
> + struct mc_command cmd = { 0 };
> + uint64_t img_paddr = virt_to_phys(img_addr);

Direct use of virt_to_phys by drivers is deprecated; this code needs
to map the i/o space via the DMA API.  This is in order to handle
situations where e.g., the device sitting behind an IOMMU.  See
Documentation/DMA-API* for more info.

> +/**
> + * Delay in microseconds between polling iterations while
> + * waiting for MC command completion
> + */
> +#define MC_CMD_COMPLETION_POLLING_INTERVAL_USECS500  /* 0.5 ms */
> +
> +int __must_check fsl_create_mc_io(struct device *dev,
> +   phys_addr_t mc_portal_phys_addr,
> +   uint32_t mc_portal_size,
> +   uint32_t flags, struct fsl_mc_io **new_mc_io)
> +{
> + struct fsl_mc_io *mc_io;
> + void __iomem *mc_portal_virt_addr;
> + struct resource *res;
> +
> + mc_io = devm_kzalloc(dev, sizeof(*mc_io), GFP_KERNEL);
> + if (mc_io == NULL)
> + return -ENOMEM;
> +
> + mc_io->dev = dev;
> + mc_io->flags = flags;
> + mc_io->portal_phys_addr = mc_portal_phys_addr;
> + mc_io->portal_size = mc_portal_size;
> + if (mc_io->flags & FSL_MC_PORTAL_SHARED_BY_INT_HANDLERS)
> + spin_lock_init(_io->spinlock);

I'm confused - this patseries doesn't register an interrupt handler,
so this can't be true (or it's premature if it will, in which case
it should be left out for now).

However, if somehow users of this code register an IRQ handler for
the portal (I don't see any users to tell how they get the IRQ line
either?), then it's up to them to establish mutual exclusion rules
for access, among themselves.  Unless you think they will be calling
mc_send_command from h/w IRQ context, in which case I'd reconsider
that assumption because send_command looks like it'd take too long
to get an answer from the h/w - IRQ handlers should just ack the h/w
IRQ, and notify the scheduler that the driver has work to do (in s/w
IRQ context perhaps).

> + else if (mc_io->flags & FSL_MC_PORTAL_SHARED_BY_THREADS)
> + mutex_init(_io->mutex);

I'd assume SHARED_BY_THREADS to always be true in linux.

> + res = devm_request_mem_region(dev,
> +   mc_portal_phys_addr,
> +   mc_portal_size,
> +   "mc_portal");
> + if (res == NULL) {
> + dev_err(dev,
> + "devm_request_mem_region failed for MC portal %#llx\n",
> + mc_portal_phys_addr);
> + return -EBUSY;
> + }
> +
> + mc_portal_virt_addr = devm_ioremap_nocache(dev,
> +mc_portal_phys_addr,
> +mc_portal_size);
> + if (mc_portal_virt_addr == NULL) {
> + dev_err(dev,
> + "devm_ioremap_nocache failed for MC portal %#llx\n",
> + mc_portal_phys_addr);
> + return -ENXIO;
> + }
> +
> + mc_io->portal_virt_addr = mc_portal_virt_addr;
> + *new_mc_io = mc_io;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(fsl_create_mc_io);
> +
> +void fsl_destroy_mc_io(struct fsl_mc_io *mc_io)
> +{
> + if (WARN_ON(mc_io->portal_virt_addr == NULL))
> + return;

this is unnecessary - you'll get the stack trace anyway, and users
calling destroy on a not successfully created mc_io object should
not get the luxury of maybe being able to continue after the stack
trace, after possibly leaking memory.

> + mc_io->portal_virt_addr = NULL;
> + devm_kfree(mc_io->dev, mc_io);

like I said before, there's really no point in clearing something
out right before it's freed.

> +}
> +EXPORT_SYMBOL_GPL(fsl_destroy_mc_io);
> +
> +static int mc_status_to_error(enum mc_cmd_status status)
> +{
> + static const int mc_status_to_error_map[] = {
> + [MC_CMD_STATUS_OK] = 0,
> + [MC_CMD_STATUS_AUTH_ERR] = -EACCES,
> + [MC_CMD_STATUS_NO_PRIVILEGE] = -EPERM,
> + [MC_CMD_STATUS_DMA_ERR] = -EIO,
> + [MC_CMD_STATUS_CONFIG_ERR] = -ENXIO,
> + [MC_CMD_STATUS_TIMEOUT] = -ETIMEDOUT,
> + [MC_CMD_STATUS_NO_RESOURCE] = -ENAVAIL,
> + [MC_CMD_STATUS_NO_MEMORY] = -ENOMEM,
> + [MC_CMD_STATUS_BUSY] = -EBUSY,
> + [MC_CMD_STATUS_UNSUPPORTED_OP] = -ENOTSUPP,
> + [MC_CMD_STATUS_INVALID_STATE] = -ENODEV,
> + };
> +
> + if (WARN_ON(status >= 

Re: [PATCH linux-next] Documentation: mic: mpssd: Disable mpssd builds for kernels < 3.13

[Andrew Morton]

On Tue, 23 Sep 2014 19:47:11 -0400 Peter Foley  wrote:

> On Tue, Sep 23, 2014 at 7:38 PM, Andrew Morton
>  wrote:
> > This build error is caused by compiling mpssd prior to `make
> > headers_install'.
> >
> > There's really no reason to check the kernel version.  If someone
> > transplants mpssd out of its distributed kernel and into some older
> > kernel then a miscompile is their problem - their backport is
> > incomplete.
> 
> I've only noticed this error when running make Documentation/,
> in which case gcc silently uses the headers from the system,
> since the headers_install ones don't exist yet.
> 
> Maybe having the build error out in this case instead of having mysterious
> compile errors would be a better solution?
> 

Can't we just fix the Makefiles?  Cook up a rule which makes
headers_install (if needed) before building Documentation/?
--
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] workqueue: show the pool ID of the default pwq's pool in the pool_ids file

[Lai Jiangshan]

On 09/23/2014 10:38 PM, Tejun Heo wrote:
> On Mon, Sep 22, 2014 at 04:04:37PM +0800, Lai Jiangshan wrote:
>> It seems incomplete if the pool_ids file doesn't include the default
>> pwq's pool.  Add it and the result:
>>
>> # cat pool_ids 
>> 0:9 1:10
>> default:8
> 
> Hmmm?  default pwq is used only as the fallback if pool switching
> fails and the failed nodes will have it assigned to them.  Why would
> userland care about something which isn't being used?

Understood.

> 
> Thanks.
> 

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

Re: [PATCH] zsmalloc: merge size_class to reduce fragmentation

[Joonsoo Kim]

On Tue, Sep 23, 2014 at 03:25:55PM -0700, Andrew Morton wrote:
> On Tue, 23 Sep 2014 17:30:11 +0900 Joonsoo Kim  wrote:
> 
> > zsmalloc has many size_classes to reduce fragmentation and they are
> > in 16 bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096.
> > And, zsmalloc has constraint that each zspage has 4 pages at maximum.
> > 
> > In this situation, we can see interesting aspect.
> > Let's think about size_class for 1488, 1472, ..., 1376.
> > To prevent external fragmentation, they uses 4 pages per zspage and
> > so all they can contain 11 objects at maximum.
> > 
> > 16384 (4096 * 4) = 1488 * 11 + remains
> > 16384 (4096 * 4) = 1472 * 11 + remains
> > 16384 (4096 * 4) = ...
> > 16384 (4096 * 4) = 1376 * 11 + remains
> > 
> > It means that they have same chracteristics and classification between
> > them isn't needed. If we use one size_class for them, we can reduce
> > fragementation and save some memory. Below is result of my simple test.
> > 
> > TEST ENV: EXT4 on zram, mount with discard option
> > WORKLOAD: untar kernel source code, remove directory in descending order
> > in size. (drivers arch fs sound include net Documentation firmware
> > kernel tools)
> > 
> > Each line represents orig_data_size, compr_data_size, mem_used_total,
> > fragmentation overhead (mem_used - compr_data_size) and overhead ratio
> > (overhead to compr_data_size), respectively, after untar and remove
> > operation is executed.
> > 
> > * untar-nomerge.out
> > 
> > orig_size compr_size used_size overhead overhead_ratio
> > 525.88MB 199.16MB 210.23MB  11.08MB 5.56%
> > 288.32MB  97.43MB 105.63MB   8.20MB 8.41%
> > 177.32MB  61.12MB  69.40MB   8.28MB 13.55%
> > 146.47MB  47.32MB  56.10MB   8.78MB 18.55%
> > 124.16MB  38.85MB  48.41MB   9.55MB 24.58%
> > 103.93MB  31.68MB  40.93MB   9.25MB 29.21%
> >  84.34MB  22.86MB  32.72MB   9.86MB 43.13%
> >  66.87MB  14.83MB  23.83MB   9.00MB 60.70%
> >  60.67MB  11.11MB  18.60MB   7.49MB 67.48%
> >  55.86MB   8.83MB  16.61MB   7.77MB 88.03%
> >  53.32MB   8.01MB  15.32MB   7.31MB 91.24%
> > 
> > * untar-merge.out
> > 
> > orig_size compr_size used_size overhead overhead_ratio
> > 526.23MB 199.18MB 209.81MB  10.64MB 5.34%
> > 288.68MB  97.45MB 104.08MB   6.63MB 6.80%
> > 177.68MB  61.14MB  66.93MB   5.79MB 9.47%
> > 146.83MB  47.34MB  52.79MB   5.45MB 11.51%
> > 124.52MB  38.87MB  44.30MB   5.43MB 13.96%
> > 104.29MB  31.70MB  36.83MB   5.13MB 16.19%
> >  84.70MB  22.88MB  27.92MB   5.04MB 22.04%
> >  67.11MB  14.83MB  19.26MB   4.43MB 29.86%
> >  60.82MB  11.10MB  14.90MB   3.79MB 34.17%
> >  55.90MB   8.82MB  12.61MB   3.79MB 42.97%
> >  53.32MB   8.01MB  11.73MB   3.73MB 46.53%
> > 
> > As you can see above result, merged one has better utilization (overhead
> > ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
> > 
> 
> The above is great, but it provided no description of the implementation,
> and there are no code comments describing what's going on either.

Okay. I will add it.

> 
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -193,6 +193,7 @@ struct size_class {
> >  */
> > int size;
> > unsigned int index;
> > +   unsigned int nr_obj;
> 
> Documenting the data structures is critical.  If the roles and
> relationships and interactions between the data structures are
> skilfully described, the implementation tends to become relatively
> obvious.

Okay.

> 
> > /* Number of PAGE_SIZE sized pages to combine to form a 'zspage' */
> > int pages_per_zspage;
> > @@ -214,7 +215,8 @@ struct link_free {
> >  };
> >  
> >  struct zs_pool {
> > -   struct size_class size_class[ZS_SIZE_CLASSES];
> > +   struct size_class *size_class[ZS_SIZE_CLASSES];
> > +   struct size_class __size_class[ZS_SIZE_CLASSES];
> 
> Are these the best possible names?
> 
> I assume the entries in size_class[] point into entries in
> __size_class[].  Some description of how (and why!) this is arranged
> would go a long way.

Okay.

> 
> > @@ -949,20 +961,28 @@ struct zs_pool *zs_create_pool(gfp_t flags)
> > if (!pool)
> > return NULL;
> >  
> > -   for (i = 0; i < ZS_SIZE_CLASSES; i++) {
> > +   for (i = ZS_SIZE_CLASSES - 1; i >= 0; i--) {
> > int size;
> > struct size_class *class;
> > +   struct size_class *prev_class;
> >  
> > size = ZS_MIN_ALLOC_SIZE + i * ZS_SIZE_CLASS_DELTA;
> > if (size > ZS_MAX_ALLOC_SIZE)
> > size = ZS_MAX_ALLOC_SIZE;
> >  
> > -   class = >size_class[i];
> > +   class = >__size_class[i];
> > class->size = size;
> > class->index = i;
> > spin_lock_init(>lock);
> > class->pages_per_zspage = get_pages_per_zspage(size);
> > +   class->nr_obj = class->pages_per_zspage * PAGE_SIZE / size;
> >  
> > +   pool->size_class[i] = class;
> > +   if (i < ZS_SIZE_CLASSES - 1) {
> > +   prev_class = pool->size_class[i + 1];
> > +

Re: [PATCH] ARM: shmobile: Remove ARCH_HAS_OPP completely

[Simon Horman]

On Tue, Sep 23, 2014 at 10:27:37AM +0200, Geert Uytterhoeven wrote:
> On Tue, Sep 23, 2014 at 10:08 AM, Paul Bolle  wrote:
> > The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit
> > 049d595a4db3 ("PM / OPP: Make OPP invisible to users in Kconfig")
> > removed the only dependency that used it. Setting it had no effect
> > anymore.
> >
> > So commit 78c5e0bb145d ("PM / OPP: Remove ARCH_HAS_OPP") removed it. For
> > some reason that commit did not remove all select statements for that
> > symbol. These statements are now useless. Remove one from shmobile too.
> 
> The explanation for "some reason" is very simple: new selects were introduced
> in parallel with the removal of the existing ones.
> 
> > Signed-off-by: Paul Bolle 
> 
> Acked-by: Geert Uytterhoeven 

Thanks, I have queued this up for v3.19.
I will push it to a branch that will be included in linux-next
once v3.18-rc1 has been released.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build warning after merge of the net tree

[Stephen Rothwell]

Hi all,

On Wed, 24 Sep 2014 07:23:06 +1000 Stephen Rothwell  
wrote:
>
> On Tue, 23 Sep 2014 16:59:59 +0200 Michal Marek  wrote:
> >
> > On 2014-09-18 02:35, Randy Dunlap wrote:
> > > On 09/17/14 17:32, Stephen Rothwell wrote:
> > >> Hi all,
> > >>
> > >> After merging the net tree, today's linux-next build (powerpc
> > >> ppc64_defconfig) produced these warnings:
> > >>
> > >> warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && 
> > >> EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects 
> > >> IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && 
> > >> ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX 
> > >> && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII 
> > >> which has unmet direct dependencies (NETDEVICES && ETHERNET && 
> > >> NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) 
> > >> selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && 
> > >> ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 
> > >> 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 
> > >> which has unmet direct dependencies (NETDEVICES && ETHERNET && 
> > >> NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX 
> > >> && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII 
> > >> which has unmet direct dependencies (NETDEVICES && ETHERNET && 
> > >> NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && 
> > >> EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects 
> > >> IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && 
> > >> ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) 
> > >> selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && 
> > >> ETHERNET && NET_VENDOR_IBM)
> > >> warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 
> > >> 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 
> > >> which has unmet direct dependencies (NETDEVICES && ETHERNET && 
> > >> NET_VENDOR_IBM)
> > >>
> > > 
> > > I have looked into these and don't see why there is a problem.
> > > Any help would be appreciated.
> > 
> > This is a side effect of 5d6be6a5 ("scsi_netlink : Make SCSI_NETLINK
> > dependent on NET instead of selecting NET"). Previously, SCSI_FC_ATTRS
> > would select SCSI_NETLINK which would select CONFIG_NET. The above
> > warnings are just a tip of the iceberg, the more serious issue is that
> > ppc64_defconfig is lacking networking support. This is the downside of
> > savedefconfig, because the 'select' implications can disappear over
> > time. Looks like more defconfigs are affected by this:
> 
> And since 5d6be6a5 is now in Linus' tree, we need Michal's 5 patches
> (at least) to be sent to Linus ASAP ...

I have put those 5 patches in my fixes tree for today ...

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

[PATCH 0/4] toshiba_acpi: Return codes cleanup

[Azael Avalos]

Up for review.

This series of patches are a cleanup thee Toshiba
configuration interface return codes (unification),
as well as changing the returned type of the HCI/SCI
read/write functions from acpi_status to u32, since
the "status" was never checked on most of the functions.

I would like these to be queued for 3.18 if possible.

Azael Avalos (4):
  toshiba_acpi: Rename hci_raw to tci_raw
  toshiba_acpi: Unify return codes prefix to from HCI/SCI to TOS
  toshiba_acpi: Change HCI/SCI functions return code type
  toshiba_acpi: Adapt functions to the changes made to HCI/SCI

 drivers/platform/x86/toshiba_acpi.c | 289 ++--
 1 file changed, 142 insertions(+), 147 deletions(-)

-- 
2.0.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/

[PATCH 4/4] toshiba_acpi: Adapt functions to the changes made to HCI/SCI

[Azael Avalos]

The previous patch changed the return type for the HCI/SCI
read/write functions.

This patch adapts the code for that change, as now the
"result" parameter is returned by those functions, instead
of the ACPI status call.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 77 -
 1 file changed, 34 insertions(+), 43 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 43385f7..582563d 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -459,7 +459,6 @@ static void toshiba_illumination_set(struct led_classdev 
*cdev,
struct toshiba_acpi_dev *dev = container_of(cdev,
struct toshiba_acpi_dev, led_dev);
u32 state, result;
-   acpi_status status;
 
/* First request : initialize communication. */
if (!sci_open(dev))
@@ -467,9 +466,9 @@ static void toshiba_illumination_set(struct led_classdev 
*cdev,
 
/* Switch the illumination on/off */
state = brightness ? 1 : 0;
-   status = sci_write(dev, SCI_ILLUMINATION, state, );
+   result = sci_write(dev, SCI_ILLUMINATION, state);
sci_close(dev);
-   if (ACPI_FAILURE(status)) {
+   if (result == TOS_FAILURE) {
pr_err("ACPI call for illumination failed\n");
return;
} else if (result == TOS_NOT_SUPPORTED) {
@@ -483,16 +482,15 @@ static enum led_brightness 
toshiba_illumination_get(struct led_classdev *cdev)
struct toshiba_acpi_dev *dev = container_of(cdev,
struct toshiba_acpi_dev, led_dev);
u32 state, result;
-   acpi_status status;
 
/* First request : initialize communication. */
if (!sci_open(dev))
return LED_OFF;
 
/* Check the illumination */
-   status = sci_read(dev, SCI_ILLUMINATION, , );
+   result = sci_read(dev, SCI_ILLUMINATION, );
sci_close(dev);
-   if (ACPI_FAILURE(status) || result == TOS_INPUT_DATA_ERROR) {
+   if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
pr_err("ACPI call for illumination failed\n");
return LED_OFF;
} else if (result == TOS_NOT_SUPPORTED) {
@@ -543,14 +541,13 @@ static int toshiba_kbd_illum_available(struct 
toshiba_acpi_dev *dev)
 static int toshiba_kbd_illum_status_set(struct toshiba_acpi_dev *dev, u32 time)
 {
u32 result;
-   acpi_status status;
 
if (!sci_open(dev))
return -EIO;
 
-   status = sci_write(dev, SCI_KBD_ILLUM_STATUS, time, );
+   result = sci_write(dev, SCI_KBD_ILLUM_STATUS, time);
sci_close(dev);
-   if (ACPI_FAILURE(status) || result == TOS_INPUT_DATA_ERROR) {
+   if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
pr_err("ACPI call to set KBD backlight status failed\n");
return -EIO;
} else if (result == TOS_NOT_SUPPORTED) {
@@ -564,14 +561,13 @@ static int toshiba_kbd_illum_status_set(struct 
toshiba_acpi_dev *dev, u32 time)
 static int toshiba_kbd_illum_status_get(struct toshiba_acpi_dev *dev, u32 
*time)
 {
u32 result;
-   acpi_status status;
 
if (!sci_open(dev))
return -EIO;
 
-   status = sci_read(dev, SCI_KBD_ILLUM_STATUS, time, );
+   result = sci_read(dev, SCI_KBD_ILLUM_STATUS, time);
sci_close(dev);
-   if (ACPI_FAILURE(status) || result == TOS_INPUT_DATA_ERROR) {
+   if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
pr_err("ACPI call to get KBD backlight status failed\n");
return -EIO;
} else if (result == TOS_NOT_SUPPORTED) {
@@ -587,11 +583,10 @@ static enum led_brightness 
toshiba_kbd_backlight_get(struct led_classdev *cdev)
struct toshiba_acpi_dev *dev = container_of(cdev,
struct toshiba_acpi_dev, kbd_led);
u32 state, result;
-   acpi_status status;
 
/* Check the keyboard backlight state */
-   status = hci_read1(dev, HCI_KBD_ILLUMINATION, , );
-   if (ACPI_FAILURE(status) || result == TOS_INPUT_DATA_ERROR) {
+   result = hci_read1(dev, HCI_KBD_ILLUMINATION, );
+   if (result == TOS_FAILURE || result == TOS_INPUT_DATA_ERROR) {
pr_err("ACPI call to get the keyboard backlight failed\n");
return LED_OFF;
} else if (result == TOS_NOT_SUPPORTED) {
@@ -608,12 +603,11 @@ static void toshiba_kbd_backlight_set(struct led_classdev 
*cdev,
struct toshiba_acpi_dev *dev = container_of(cdev,
struct toshiba_acpi_dev, kbd_led);
u32 state, result;
-   acpi_status status;
 
/* Set the keyboard backlight state */
state = brightness ? 1 : 0;
-   status = hci_write1(dev, HCI_KBD_ILLUMINATION, state, );
-   if (ACPI_FAILURE(status) || result == TOS_INPUT_DATA_ERROR) {
+   

[PATCH 1/4] toshiba_acpi: Rename hci_raw to tci_raw

[Azael Avalos]

The function name hci_raw was used before to reflect
a raw (read/write) call to the Toshiba's Hardware
Configuration Interface (HCI), however, since the
introduction of the System Configuration Interface
(SCI), that "name" no longer applies.

This patch changes the name of that function to
tci_raw (for Toshiba Configuration Interface), and
change the comments about it.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 40 ++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index edd8f3d..b7030dc 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -71,7 +71,7 @@ MODULE_LICENSE("GPL");
 /* Toshiba ACPI method paths */
 #define METHOD_VIDEO_OUT   "\\_SB_.VALX.DSSX"
 
-/* Toshiba HCI interface definitions
+/* Toshiba configuration interface definitions
  *
  * HCI is Toshiba's "Hardware Control Interface" which is supposed to
  * be uniform across all their models.  Ideally we would just call
@@ -274,10 +274,10 @@ static int write_acpi_int(const char *methodName, int val)
return (status == AE_OK) ? 0 : -EIO;
 }
 
-/* Perform a raw HCI call.  Here we don't care about input or output buffer
- * format.
+/* Perform a raw configuration call.  Here we don't care about input or output
+ * buffer format.
  */
-static acpi_status hci_raw(struct toshiba_acpi_dev *dev,
+static acpi_status tci_raw(struct toshiba_acpi_dev *dev,
   const u32 in[HCI_WORDS], u32 out[HCI_WORDS])
 {
struct acpi_object_list params;
@@ -320,7 +320,7 @@ static acpi_status hci_write1(struct toshiba_acpi_dev *dev, 
u32 reg,
 {
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
u32 out[HCI_WORDS];
-   acpi_status status = hci_raw(dev, in, out);
+   acpi_status status = tci_raw(dev, in, out);
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
return status;
 }
@@ -330,7 +330,7 @@ static acpi_status hci_read1(struct toshiba_acpi_dev *dev, 
u32 reg,
 {
u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
-   acpi_status status = hci_raw(dev, in, out);
+   acpi_status status = tci_raw(dev, in, out);
*out1 = out[2];
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
return status;
@@ -341,7 +341,7 @@ static acpi_status hci_write2(struct toshiba_acpi_dev *dev, 
u32 reg,
 {
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[HCI_WORDS];
-   acpi_status status = hci_raw(dev, in, out);
+   acpi_status status = tci_raw(dev, in, out);
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
return status;
 }
@@ -351,7 +351,7 @@ static acpi_status hci_read2(struct toshiba_acpi_dev *dev, 
u32 reg,
 {
u32 in[HCI_WORDS] = { HCI_GET, reg, *out1, *out2, 0, 0 };
u32 out[HCI_WORDS];
-   acpi_status status = hci_raw(dev, in, out);
+   acpi_status status = tci_raw(dev, in, out);
*out1 = out[2];
*out2 = out[3];
*result = (status == AE_OK) ? out[0] : HCI_FAILURE;
@@ -367,7 +367,7 @@ static int sci_open(struct toshiba_acpi_dev *dev)
u32 out[HCI_WORDS];
acpi_status status;
 
-   status = hci_raw(dev, in, out);
+   status = tci_raw(dev, in, out);
if  (ACPI_FAILURE(status) || out[0] == HCI_FAILURE) {
pr_err("ACPI call to open SCI failed\n");
return 0;
@@ -391,7 +391,7 @@ static void sci_close(struct toshiba_acpi_dev *dev)
u32 out[HCI_WORDS];
acpi_status status;
 
-   status = hci_raw(dev, in, out);
+   status = tci_raw(dev, in, out);
if (ACPI_FAILURE(status) || out[0] == HCI_FAILURE) {
pr_err("ACPI call to close SCI failed\n");
return;
@@ -410,7 +410,7 @@ static acpi_status sci_read(struct toshiba_acpi_dev *dev, 
u32 reg,
 {
u32 in[HCI_WORDS] = { SCI_GET, reg, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
-   acpi_status status = hci_raw(dev, in, out);
+   acpi_status status = tci_raw(dev, in, out);
*out1 = out[2];
*result = (ACPI_SUCCESS(status)) ? out[0] : HCI_FAILURE;
return status;
@@ -421,7 +421,7 @@ static acpi_status sci_write(struct toshiba_acpi_dev *dev, 
u32 reg,
 {
u32 in[HCI_WORDS] = { SCI_SET, reg, in1, 0, 0, 0 };
u32 out[HCI_WORDS];
-   acpi_status status = hci_raw(dev, in, out);
+   acpi_status status = tci_raw(dev, in, out);
*result = (ACPI_SUCCESS(status)) ? out[0] : HCI_FAILURE;
return status;
 }
@@ -436,7 +436,7 @@ static int toshiba_illumination_available(struct 
toshiba_acpi_dev *dev)
if (!sci_open(dev))
return 0;
 
-   status = hci_raw(dev, in, out);
+   status = tci_raw(dev, in, out);
sci_close(dev);
if (ACPI_FAILURE(status) || out[0] == HCI_FAILURE) {

[PATCH 3/4] toshiba_acpi: Change HCI/SCI functions return code type

[Azael Avalos]

Currently the HCI/SCI read/write functions are returning
the status of the ACPI call and also assigning the
returned value of the HCI/SCI function.

This patch changes such functions, returning the value
of the HCI/SCI function instead of the ACPI call status.

The next patch will change all the HCI/SCI functions
to reflect the change made in this patch.

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 51 -
 1 file changed, 27 insertions(+), 24 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index 5b16d11..43385f7 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -316,47 +316,49 @@ static acpi_status tci_raw(struct toshiba_acpi_dev *dev,
  * may be useful (such as "not supported").
  */
 
-static acpi_status hci_write1(struct toshiba_acpi_dev *dev, u32 reg,
- u32 in1, u32 *result)
+static u32 hci_write1(struct toshiba_acpi_dev *dev, u32 reg, u32 in1)
 {
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
-   *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
-   return status;
+
+   return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
 }
 
-static acpi_status hci_read1(struct toshiba_acpi_dev *dev, u32 reg,
-u32 *out1, u32 *result)
+static u32 hci_read1(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1)
 {
u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status))
+   return TOS_FAILURE;
+
*out1 = out[2];
-   *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
-   return status;
+
+   return out[0];
 }
 
-static acpi_status hci_write2(struct toshiba_acpi_dev *dev, u32 reg,
- u32 in1, u32 in2, u32 *result)
+static u32 hci_write2(struct toshiba_acpi_dev *dev, u32 reg, u32 in1, u32 in2)
 {
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
-   *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
-   return status;
+
+   return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
 }
 
-static acpi_status hci_read2(struct toshiba_acpi_dev *dev, u32 reg,
-u32 *out1, u32 *out2, u32 *result)
+static u32 hci_read2(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1, u32 
*out2)
 {
u32 in[HCI_WORDS] = { HCI_GET, reg, *out1, *out2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status))
+   return TOS_FAILURE;
+
*out1 = out[2];
*out2 = out[3];
-   *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
-   return status;
+
+   return out[0];
 }
 
 /* common sci tasks
@@ -406,25 +408,26 @@ static void sci_close(struct toshiba_acpi_dev *dev)
pr_info("Toshiba SCI is not present\n");
 }
 
-static acpi_status sci_read(struct toshiba_acpi_dev *dev, u32 reg,
-   u32 *out1, u32 *result)
+static u32 sci_read(struct toshiba_acpi_dev *dev, u32 reg, u32 *out1)
 {
u32 in[HCI_WORDS] = { SCI_GET, reg, 0, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
+   if (ACPI_FAILURE(status))
+   return TOS_FAILURE;
+
*out1 = out[2];
-   *result = (ACPI_SUCCESS(status)) ? out[0] : TOS_FAILURE;
-   return status;
+
+   return out[0];
 }
 
-static acpi_status sci_write(struct toshiba_acpi_dev *dev, u32 reg,
-u32 in1, u32 *result)
+static u32 sci_write(struct toshiba_acpi_dev *dev, u32 reg, u32 in1)
 {
u32 in[HCI_WORDS] = { SCI_SET, reg, in1, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
-   *result = (ACPI_SUCCESS(status)) ? out[0] : TOS_FAILURE;
-   return status;
+
+   return ACPI_SUCCESS(status) ? out[0] : TOS_FAILURE;
 }
 
 /* Illumination support */
-- 
2.0.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/

[PATCH 2/4] toshiba_acpi: Unify return codes prefix to from HCI/SCI to TOS

[Azael Avalos]

The return codes are split in between HCI/SCI prefixes,
but they are shared (used) by both interfaces, mixing
hci_read/write calls with SCI_* return codes, and
sci_read/write calls with HCI_* ones.

This patch changes the prefix of the return codes
definitions, dropping the HCI/SCI naming and instead
replacing it with TOS (for TOShiba).

Signed-off-by: Azael Avalos 
---
 drivers/platform/x86/toshiba_acpi.c | 143 ++--
 1 file changed, 72 insertions(+), 71 deletions(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index b7030dc..5b16d11 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -95,17 +95,18 @@ MODULE_LICENSE("GPL");
 #define SCI_SET0xf400
 
 /* return codes */
-#define HCI_SUCCESS0x
-#define HCI_FAILURE0x1000
-#define HCI_NOT_SUPPORTED  0x8000
-#define HCI_EMPTY  0x8c00
-#define HCI_DATA_NOT_AVAILABLE 0x8d20
-#define HCI_NOT_INITIALIZED0x8d50
-#define SCI_OPEN_CLOSE_OK  0x0044
-#define SCI_ALREADY_OPEN   0x8100
-#define SCI_NOT_OPENED 0x8200
-#define SCI_INPUT_DATA_ERROR   0x8300
-#define SCI_NOT_PRESENT0x8600
+#define TOS_SUCCESS0x
+#define TOS_OPEN_CLOSE_OK  0x0044
+#define TOS_FAILURE0x1000
+#define TOS_NOT_SUPPORTED  0x8000
+#define TOS_ALREADY_OPEN   0x8100
+#define TOS_NOT_OPENED 0x8200
+#define TOS_INPUT_DATA_ERROR   0x8300
+#define TOS_WRITE_PROTECTED0x8400
+#define TOS_NOT_PRESENT0x8600
+#define TOS_FIFO_EMPTY 0x8c00
+#define TOS_DATA_NOT_AVAILABLE 0x8d20
+#define TOS_NOT_INITIALIZED0x8d50
 
 /* registers */
 #define HCI_FAN0x0004
@@ -321,7 +322,7 @@ static acpi_status hci_write1(struct toshiba_acpi_dev *dev, 
u32 reg,
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
-   *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+   *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
return status;
 }
 
@@ -332,7 +333,7 @@ static acpi_status hci_read1(struct toshiba_acpi_dev *dev, 
u32 reg,
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
*out1 = out[2];
-   *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+   *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
return status;
 }
 
@@ -342,7 +343,7 @@ static acpi_status hci_write2(struct toshiba_acpi_dev *dev, 
u32 reg,
u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 };
u32 out[HCI_WORDS];
acpi_status status = tci_raw(dev, in, out);
-   *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+   *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
return status;
 }
 
@@ -354,7 +355,7 @@ static acpi_status hci_read2(struct toshiba_acpi_dev *dev, 
u32 reg,
acpi_status status = tci_raw(dev, in, out);
*out1 = out[2];
*out2 = out[3];
-   *result = (status == AE_OK) ? out[0] : HCI_FAILURE;
+   *result = (status == AE_OK) ? out[0] : TOS_FAILURE;
return status;
 }
 
@@ -368,17 +369,17 @@ static int sci_open(struct toshiba_acpi_dev *dev)
acpi_status status;
 
status = tci_raw(dev, in, out);
-   if  (ACPI_FAILURE(status) || out[0] == HCI_FAILURE) {
+   if  (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
pr_err("ACPI call to open SCI failed\n");
return 0;
}
 
-   if (out[0] == SCI_OPEN_CLOSE_OK) {
+   if (out[0] == TOS_OPEN_CLOSE_OK) {
return 1;
-   } else if (out[0] == SCI_ALREADY_OPEN) {
+   } else if (out[0] == TOS_ALREADY_OPEN) {
pr_info("Toshiba SCI already opened\n");
return 1;
-   } else if (out[0] == SCI_NOT_PRESENT) {
+   } else if (out[0] == TOS_NOT_PRESENT) {
pr_info("Toshiba SCI is not present\n");
}
 
@@ -392,16 +393,16 @@ static void sci_close(struct toshiba_acpi_dev *dev)
acpi_status status;
 
status = tci_raw(dev, in, out);
-   if (ACPI_FAILURE(status) || out[0] == HCI_FAILURE) {
+   if (ACPI_FAILURE(status) || out[0] == TOS_FAILURE) {
pr_err("ACPI call to close SCI failed\n");
return;
}
 
-   if (out[0] == SCI_OPEN_CLOSE_OK)
+   if (out[0] == TOS_OPEN_CLOSE_OK)
return;
-   else if (out[0] == SCI_NOT_OPENED)
+   else if (out[0] == TOS_NOT_OPENED)
pr_info("Toshiba SCI not opened\n");
-   else if (out[0] == SCI_NOT_PRESENT)
+   else if (out[0] == TOS_NOT_PRESENT)
pr_info("Toshiba SCI is not 

Re: [PATCH v12 05/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Bjorn Helgaas]

[+cc Andrew]

On Tue, Sep 23, 2014 at 08:01:07PM +0100, Liviu Dudau wrote:
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
> The conversion from pci ranges to resources failed to take that into account,
> returning a CPU physical address instead of a port number.
> 
> Also fix all the drivers that depend on the old behaviour by fetching
> the CPU physical address based on the port number where it is being needed.
> 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Arnd Bergmann 
> Acked-by: Linus Walleij 
> Cc: Thierry Reding 
> Cc: Simon Horman 
> Cc: Catalin Marinas 
> Signed-off-by: Liviu Dudau 
> ---
>  arch/arm/mach-integrator/pci_v3.c | 23 ++--
>  drivers/of/address.c  | 44 
> +++
>  drivers/pci/host/pci-tegra.c  | 10 ++---
>  drivers/pci/host/pcie-rcar.c  | 21 +--
>  include/linux/of_address.h| 15 ++---
>  5 files changed, 82 insertions(+), 31 deletions(-)
> ...

The of_pci_range_to_resource() implementation in drivers/of/address.c is
always compiled when CONFIG_OF_ADDRESS=y, but when CONFIG_OF_ADDRESS=y and
CONFIG_PCI is not set, we get the static inline version from
include/linux/of_address.h as well, causing a redefinition error.

> diff --git a/drivers/of/address.c b/drivers/of/address.c
> @@ -957,12 +957,48 @@ bool of_dma_is_coherent(struct device_node *np)
> ...
> +int of_pci_range_to_resource(struct of_pci_range *range,
> + struct device_node *np, struct resource *res)

> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> ...
>  #else /* CONFIG_OF_ADDRESS && CONFIG_PCI */
>  static inline int of_pci_address_to_resource(struct device_node *dev, int 
> bar,
>struct resource *r)
> @@ -144,6 +139,12 @@ static inline int of_pci_address_to_resource(struct 
> device_node *dev, int bar,
>   return -ENOSYS;
>  }
>  
> +static inline int of_pci_range_to_resource(struct of_pci_range *range,
> + struct device_node *np, struct resource *res)
> +{
> + return -ENOSYS;
> +}

My proposal to fix it is the following three patches.  The first moves the
inline version of of_pci_range_to_resource() into the existing "#if
defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)" block.

Andrew added it (and some other PCI-related things) with 29b635c00f3e
("of/pci: Provide support for parsing PCI DT ranges property") to
of_address.h outside of any ifdefs, so it's always available.  Maybe
there's a reason that's needed in the non-CONFIG_PCI case, but I didn't see
it with a quick look.

The second moves of_pci_range_to_resource() to address.c, still inside the
"#ifdef CONFIG_PCI" block.

Bjorn


commit 95a60df1c2d400c676ab1d20271735e2b4735437
Author: Bjorn Helgaas 
Date:   Tue Sep 23 17:27:42 2014 -0600

of/pci: Define of_pci_range_to_resource() only when CONFIG_PCI=y

of_pci_range_to_resource() was previously defined always, but it's only
used by PCI code, so move the definition inside the CONFIG_OF_ADDRESS &&
CONFIG_PCI block.

Signed-off-by: Bjorn Helgaas 

diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index f8cc7daa420c..ecf913cf53b2 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -23,17 +23,6 @@ struct of_pci_range {
 #define for_each_of_pci_range(parser, range) \
for (; of_pci_range_parser_one(parser, range);)
 
-static inline void of_pci_range_to_resource(struct of_pci_range *range,
-   struct device_node *np,
-   struct resource *res)
-{
-   res->flags = range->flags;
-   res->start = range->cpu_addr;
-   res->end = range->cpu_addr + range->size - 1;
-   res->parent = res->child = res->sibling = NULL;
-   res->name = np->full_name;
-}
-
 /* Translate a DMA address from device space to CPU space */
 extern u64 of_translate_dma_address(struct device_node *dev,
const __be32 *in_addr);
@@ -140,6 +129,18 @@ extern const __be32 *of_get_pci_address(struct device_node 
*dev, int bar_no,
   u64 *size, unsigned int *flags);
 extern int of_pci_address_to_resource(struct device_node *dev, int bar,
  struct resource *r);
+
+static inline void of_pci_range_to_resource(struct of_pci_range *range,
+   struct device_node *np,
+   struct resource *res)
+{
+   res->flags = range->flags;
+   res->start = range->cpu_addr;
+   res->end = range->cpu_addr + range->size - 1;
+   res->parent = res->child = res->sibling = NULL;
+   

Re: [PATCH] perf tools: Fix line number in the config file error message

[Namhyung Kim]

Hi Jiri,

On Tue, 23 Sep 2014 13:56:56 +0200, Jiri Olsa wrote:
> On Tue, Sep 23, 2014 at 10:01:39AM +0900, Namhyung Kim wrote:
>> Hello,
>> 
>> This is patchset to add new callchain related config options so that
>> users don't need to pass their preference to the cmdline everytime.
>> 
>> Following config options will be added, and users can set appropriate
>> values to ~/.perfconfig file.  Note that the dump-size option is
>> meaningful only if record-mode = dwarf.
>> 
>>   $ cat ~/.perfconfig
>>   [call-graph]
>> record-mode = dwarf
>> dump-size = 4096
>> print-type = graph
>> order = callee
>> threshold = 0.5
>> print-limit = 128
>> sort-key = function
>> 
>>   $ perf record -vg sleep 1
>>   callchain: type DWARF
>>   callchain: stack dump size 4096
>>   mmap size 528384B
>>   [ perf record: Woken up 1 times to write data ]
>>   [ perf record: Captured and wrote 0.054 MB perf.data (~2378 samples) ]
>>   Looking at the vmlinux_path (7 entries long)
>>   Using /lib/modules/3.16.3-1-ARCH/build/vmlinux for symbols
>> 
>> 
>> Jiri and David, I kept your Acked-by and Reviewed-by in this version.
>> Please take a look at the patch 4/5 which splits parser functions that
>> it still looks okay to you.
>
> looks ok to me, ACK for the patchset

Thanks!

>
> During the testing I found wrong line is displayed in the parsing
> error message. It's bug in the config code, attached patch should
> fix it.

Didn't notice that.. thanks for the quick fix. :)

>
>
> ---
> If we fail to parse the config file within the callback function,
> the line number counter 'could be' already on the next line.
>
> This results in wrong line number report like:
>
>   $ cat ~/.perfconfig
>   [call-graph]
>   sort-key = krava
>   $ perf record ls
>   Fatal: bad config file line 3 in /home/jolsa/.perfconfig
>
> Fixing this by saving the current line number for this case.
>
> Cc: Arnaldo Carvalho de Melo 
> Cc: Corey Ashford 
> Cc: David Ahern 
> Cc: Ingo Molnar 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Signed-off-by: Jiri Olsa 

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/util/config.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
> index 953512ed72ba..57ff826f150b 100644
> --- a/tools/perf/util/config.c
> +++ b/tools/perf/util/config.c
> @@ -222,7 +222,8 @@ static int perf_parse_file(config_fn_t fn, void *data)
>   const unsigned char *bomptr = utf8_bom;
>  
>   for (;;) {
> - int c = get_next_char();
> + int line, c = get_next_char();
> +
>   if (bomptr && *bomptr) {
>   /* We are at the file beginning; skip UTF8-encoded BOM
>* if present. Sane editors won't put this in on their
> @@ -261,8 +262,16 @@ static int perf_parse_file(config_fn_t fn, void *data)
>   if (!isalpha(c))
>   break;
>   var[baselen] = tolower(c);
> - if (get_value(fn, data, var, baselen+1) < 0)
> +
> + /*
> +  * The get_value function might or might not reach the '\n',
> +  * so saving the current line number for error reporting.
> +  */
> + line = config_linenr;
> + if (get_value(fn, data, var, baselen+1) < 0) {
> + config_linenr = line;
>   break;
> + }
>   }
>   die("bad config file line %d in %s", config_linenr, config_file_name);
>  }
--
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 v5 2/2] iio/adc: add support for axp288 adc

[Jacob Pan]

Platform driver for X-Powers AXP288 ADC, which is a sub-device of the
customized AXP288 PMIC for Intel Baytrail-CR platforms. GPADC device
enumerates as one of the MFD cell devices. It uses IIO infrastructure
to communicate with userspace and consumer drivers.

Usages of ADC channels include battery charging and thermal sensors.

Based on initial work by:
Ramakrishna Pallala 

Signed-off-by: Jacob Pan 
---
 drivers/iio/adc/Kconfig  |   8 ++
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/axp288_adc.c | 253 +++
 3 files changed, 262 insertions(+)
 create mode 100644 drivers/iio/adc/axp288_adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 11b048a..db2681b 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -127,6 +127,14 @@ config AT91_ADC
help
  Say yes here to build support for Atmel AT91 ADC.
 
+config AXP288_ADC
+   tristate "X-Powers AXP288 ADC driver"
+   depends on MFD_AXP20X
+   help
+ Say yes here to have support for X-Powers power management IC (PMIC) 
ADC
+ device. Depending on platform configuration, this general purpose ADC 
can
+ be used for sampling sensors such as thermal resistors.
+
 config EXYNOS_ADC
tristate "Exynos ADC driver support"
depends on ARCH_EXYNOS || (OF && COMPILE_TEST)
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index ad81b51..19640f9 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_AD7793) += ad7793.o
 obj-$(CONFIG_AD7887) += ad7887.o
 obj-$(CONFIG_AD799X) += ad799x.o
 obj-$(CONFIG_AT91_ADC) += at91_adc.o
+obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
 obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_MAX1027) += max1027.o
diff --git a/drivers/iio/adc/axp288_adc.c b/drivers/iio/adc/axp288_adc.c
new file mode 100644
index 000..664d18f
--- /dev/null
+++ b/drivers/iio/adc/axp288_adc.c
@@ -0,0 +1,253 @@
+/*
+ * axp288_adc.c - X-Powers AXP288 PMIC ADC Driver
+ *
+ * Copyright (C) 2014 Intel Corporation
+ *
+ * ~~
+ *
+ * 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; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define AXP288_ADC_EN_MASK 0xF1
+#define AXP288_ADC_TS_PIN_GPADC0xF2
+#define AXP288_ADC_TS_PIN_ON   0xF3
+
+enum axp288_adc_id {
+   AXP288_ADC_TS,
+   AXP288_ADC_PMIC,
+   AXP288_ADC_GP,
+   AXP288_ADC_BATT_CHRG_I,
+   AXP288_ADC_BATT_DISCHRG_I,
+   AXP288_ADC_BATT_V,
+   AXP288_ADC_NR_CHAN,
+};
+
+struct axp288_adc_info {
+   int irq;
+   struct regmap *regmap;
+};
+
+static const struct iio_chan_spec const axp288_adc_channels[] = {
+   {
+   .indexed = 1,
+   .type = IIO_TEMP,
+   .channel = 0,
+   .address = AXP288_TS_ADC_H,
+   .datasheet_name = "CH0",
+   }, {
+   .indexed = 1,
+   .type = IIO_TEMP,
+   .channel = 1,
+   .address = AXP288_PMIC_ADC_H,
+   .datasheet_name = "CH1",
+   }, {
+   .indexed = 1,
+   .type = IIO_TEMP,
+   .channel = 2,
+   .address = AXP288_GP_ADC_H,
+   .datasheet_name = "CH2",
+   }, {
+   .indexed = 1,
+   .type = IIO_CURRENT,
+   .channel = 3,
+   .address = AXP20X_BATT_CHRG_I_H,
+   .datasheet_name = "CH3",
+   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
+   }, {
+   .indexed = 1,
+   .type = IIO_CURRENT,
+   .channel = 4,
+   .address = AXP20X_BATT_DISCHRG_I_H,
+   .datasheet_name = "CH4",
+   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
+   }, {
+   .indexed = 1,
+   .type = IIO_VOLTAGE,
+   .channel = 5,
+   .address = AXP20X_BATT_V_H,
+   .datasheet_name = "CH5",
+   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
+   },
+};
+
+#define AXP288_ADC_MAP(_adc_channel_label, _consumer_dev_name, \
+   _consumer_channel)  \
+   {   \
+   .adc_channel_label = _adc_channel_label,\
+   

[PATCH v5 1/2] mfd/axp20x: extend axp20x to support axp288 pmic

[Jacob Pan]

X-Powers AXP288 is a customized PMIC for Intel Baytrail-CR platforms. Similar
to AXP202/209, AXP288 comes with USB charger, more LDO and BUCK channels, and
AD converters. It also provides extended status and interrupt reporting
capabilities than the devices currently supported in axp20x.c.

In addition to feature extension, this patch also adds ACPI binding for
enumeration.

This consolidated driver should support more X-Powers' PMICs in both device
tree and ACPI enumerated platforms.

Signed-off-by: Jacob Pan 
---
 drivers/mfd/Kconfig|   3 +-
 drivers/mfd/axp20x.c   | 355 ++---
 include/linux/mfd/axp20x.h |  59 
 3 files changed, 361 insertions(+), 56 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..c183edb 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -74,7 +74,8 @@ config MFD_AXP20X
select REGMAP_IRQ
depends on I2C=y
help
- If you say Y here you get support for the X-Powers AXP202 and AXP209.
+ If you say Y here you get support for the X-Powers AXP202, AXP209 and
+ AXP288 power management IC (PMIC).
  This driver include only the core APIs. You have to select individual
  components like regulators or the PEK (Power Enable Key) under the
  corresponding menus.
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index dee6539..c3252e1 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -1,9 +1,9 @@
 /*
- * axp20x.c - MFD core driver for the X-Powers AXP202 and AXP209
+ * axp20x.c - MFD core driver for the X-Powers' Power Management ICs
  *
- * AXP20x comprises an adaptive USB-Compatible PWM charger, 2 BUCK DC-DC
- * converters, 5 LDOs, multiple 12-bit ADCs of voltage, current and temperature
- * as well as 4 configurable GPIOs.
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK 
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
  *
  * Author: Carlo Caione 
  *
@@ -25,9 +25,16 @@
 #include 
 #include 
 #include 
+#include 
 
 #define AXP20X_OFF 0x80
 
+static const char const *axp20x_model_names[] = {
+   "AXP202",
+   "AXP209",
+   "AXP288",
+};
+
 static const struct regmap_range axp20x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
@@ -47,6 +54,25 @@ static const struct regmap_access_table 
axp20x_volatile_table = {
.n_yes_ranges   = ARRAY_SIZE(axp20x_volatile_ranges),
 };
 
+static const struct regmap_range axp288_writeable_ranges[] = {
+   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
+   regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
+};
+
+static const struct regmap_range axp288_volatile_ranges[] = {
+   regmap_reg_range(AXP20X_IRQ1_EN,  AXP20X_IPSOUT_V_HIGH_L),
+};
+
+static const struct regmap_access_table axp288_writeable_table = {
+   .yes_ranges = axp288_writeable_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(axp288_writeable_ranges),
+};
+
+static const struct regmap_access_table axp288_volatile_table = {
+   .yes_ranges = axp288_volatile_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(axp288_volatile_ranges),
+};
+
 static struct resource axp20x_pek_resources[] = {
{
.name   = "PEK_DBR",
@@ -61,6 +87,39 @@ static struct resource axp20x_pek_resources[] = {
},
 };
 
+static struct resource axp288_battery_resources[] = {
+   {
+   .start = AXP288_IRQ_QWBTU,
+   .end   = AXP288_IRQ_QWBTU,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_WBTU,
+   .end   = AXP288_IRQ_WBTU,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_QWBTO,
+   .end   = AXP288_IRQ_QWBTO,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_WBTO,
+   .end   = AXP288_IRQ_WBTO,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_WL2,
+   .end   = AXP288_IRQ_WL2,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_WL1,
+   .end   = AXP288_IRQ_WL1,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
 static const struct regmap_config axp20x_regmap_config = {
.reg_bits   = 8,
.val_bits   = 8,
@@ -70,47 +129,96 @@ static const struct regmap_config axp20x_regmap_config = {
.cache_type = REGCACHE_RBTREE,
 };
 
-#define AXP20X_IRQ(_irq, _off, _mask) \
-   [AXP20X_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
+static const struct regmap_config axp288_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .wr_table   = _writeable_table,
+   

[PATCH v5 0/2] Initial support for XPowers AXP288 PMIC

[Jacob Pan]

X-Powers AXP288 is a customized PMIC found on some Intel Baytrail-CR platforms.
It comes with sub-functions such as USB charging, fuel gauge, ADC, and many LDO
and BUCK channels.

By extending the existing AXP20x driver, this patchset adds basic support
for AXP288 PMIC with ADC as one MFD cell device driver.

Currently, the PMIC driver in this patchset does not support platform data
enumeration. But when ACPI _DSD and unified device properties become available,
cell devices with platform data will be added.

This patch does not use intel_soc_pmic core for i2c and regmap handling in that
axp288 shares similar programming interface with other X-Power PMICs supported 
in
axp20x.c. Therefore, extending axp20x.c to include axp288 makes more sense.

Changes
 v5:- excluded iio documentation patch, already applied to iio.git
- restructured axp288_adc read_raw code to make it more readable
- renamed adc_enable to adc_set_state and add comment about why adc
  has to be always on and there is no disable function.
- axp20x use const as needed for regmap structures

 v4:- removed rename patch, use Kconfig description to list supported 
devices
- misc clean up in ADC code, use regmap_bulk_read and improve error
  handling, etc.
- remove IIO ADC scale, treat raw data as processed since the unit is
  already in IIO expected milliamps.

 v3:- put all file rename changes in 1/5
- add iio documentation for in_current_raw/scale
- removed global variables in axp2xx
- removed pm callbacks from GPADC
- removed ACPI opregion cell device
- added scales to ADC current and voltage
- removed ADC thermal sensor from sysfs, kernel internal use only

 v2:
- use format -M for 1/4
- minor tweak based on Maxime's review


Jacob Pan (2):
  mfd/axp20x: extend axp20x to support axp288 pmic
  iio/adc: add support for axp288 adc

 drivers/iio/adc/Kconfig  |   8 +
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/axp288_adc.c | 253 ++
 drivers/mfd/Kconfig  |   3 +-
 drivers/mfd/axp20x.c | 355 ---
 include/linux/mfd/axp20x.h   |  59 +++
 6 files changed, 623 insertions(+), 56 deletions(-)
 create mode 100644 drivers/iio/adc/axp288_adc.c

-- 
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 v4 1/14] input: cyapa: re-architecture driver to support multi-trackpads in one driver

[Dmitry Torokhov]

Hi Dudley,

On Fri, Aug 22, 2014 at 04:41:07PM +0800, Dudley Du wrote:
> Dmitry,
> 
> Thanks for your feedback.
> 
> Thanks,
> Dudley
> 
> > -Original Message-
> > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> > Sent: Friday, August 22, 2014 2:21 AM
> > To: Dudley Du
> > Cc: Rafael J. Wysocki; Benson Leung; Patrik Fimml; 
> > linux-in...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Dudley Du
> > Subject: Re: [PATCH v4 1/14] input: cyapa: re-architecture driver to support
> > multi-trackpads in one driver
> > 
> > On Thu, Jul 17, 2014 at 02:47:24PM +0800, Dudley Du wrote:
> > > In order to support two different communication protocol based trackpad
> > > device in one cyapa, the new cyapa driver is re-designed with
> > > one cyapa driver core and two devices' functions component.
> > > The cyapa driver core is contained in this patch, it supplies the basic
> > > function with input and kernel system and also defined the interfaces
> > > that the devices' functions component needs to apply and support.
> > > Also, in order to speed up the system boot time, the device states
> > > detecting and probing process is put into the async thread.
> > > TEST=test on Chromebooks.
> > >
> > > Signed-off-by: Dudley Du 
> > > ---
> > >  drivers/input/mouse/Makefile |4 +-
> > >  drivers/input/mouse/cyapa.c  | 1083 
> > > ++-
> > ---
> > >  drivers/input/mouse/cyapa.h  |  275 +++
> > >  3 files changed, 646 insertions(+), 716 deletions(-)
> > >  create mode 100644 drivers/input/mouse/cyapa.h
> > >
> > > diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
> > > index c25efdb..8608eb7 100644
> > > --- a/drivers/input/mouse/Makefile
> > > +++ b/drivers/input/mouse/Makefile
> > > @@ -8,7 +8,7 @@ obj-$(CONFIG_MOUSE_AMIGA) += amimouse.o
> > >  obj-$(CONFIG_MOUSE_APPLETOUCH)   += appletouch.o
> > >  obj-$(CONFIG_MOUSE_ATARI)+= atarimouse.o
> > >  obj-$(CONFIG_MOUSE_BCM5974)  += bcm5974.o
> > > -obj-$(CONFIG_MOUSE_CYAPA)+= cyapa.o
> > > +obj-$(CONFIG_MOUSE_CYAPA)+= cyapatp.o
> > >  obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o
> > >  obj-$(CONFIG_MOUSE_INPORT)   += inport.o
> > >  obj-$(CONFIG_MOUSE_LOGIBM)   += logibm.o
> > > @@ -34,3 +34,5 @@ psmouse-$(CONFIG_MOUSE_PS2_SENTELIC)+= sentelic.o
> > >  psmouse-$(CONFIG_MOUSE_PS2_TRACKPOINT)   += trackpoint.o
> > >  psmouse-$(CONFIG_MOUSE_PS2_TOUCHKIT) += touchkit_ps2.o
> > >  psmouse-$(CONFIG_MOUSE_PS2_CYPRESS)  += cypress_ps2.o
> > > +
> > > +cyapatp-y := cyapa.o
> > > diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
> > > index b409c3d..5fc8dbe 100644
> > > --- a/drivers/input/mouse/cyapa.c
> > > +++ b/drivers/input/mouse/cyapa.c
> > > @@ -6,7 +6,7 @@
> > >   *   Daniel Kurtz 
> > >   *   Benson Leung 
> > >   *
> > > - * Copyright (C) 2011-2012 Cypress Semiconductor, Inc.
> > > + * Copyright (C) 2011-2014 Cypress Semiconductor, Inc.
> > >   * Copyright (C) 2011-2012 Google, Inc.
> > >   *
> > >   * This file is subject to the terms and conditions of the GNU General
> > Public
> > > @@ -14,731 +14,114 @@
> > >   * more details.
> > >   */
> > >
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include "cyapa.h"
> > >
> > > -/* APA trackpad firmware generation */
> > > -#define CYAPA_GEN3   0x03   /* support MT-protocol B with tracking ID. */
> > > -
> > > -#define CYAPA_NAME   "Cypress APA Trackpad (cyapa)"
> > > -
> > > -/* commands for read/write registers of Cypress trackpad */
> > > -#define CYAPA_CMD_SOFT_RESET   0x00
> > > -#define CYAPA_CMD_POWER_MODE   0x01
> > > -#define CYAPA_CMD_DEV_STATUS   0x02
> > > -#define CYAPA_CMD_GROUP_DATA   0x03
> > > -#define CYAPA_CMD_GROUP_CMD0x04
> > > -#define CYAPA_CMD_GROUP_QUERY  0x05
> > > -#define CYAPA_CMD_BL_STATUS0x06
> > > -#define CYAPA_CMD_BL_HEAD  0x07
> > > -#define CYAPA_CMD_BL_CMD   0x08
> > > -#define CYAPA_CMD_BL_DATA  0x09
> > > -#define CYAPA_CMD_BL_ALL   0x0a
> > > -#define CYAPA_CMD_BLK_PRODUCT_ID   0x0b
> > > -#define CYAPA_CMD_BLK_HEAD 0x0c
> > > -
> > > -/* report data start reg offset address. */
> > > -#define DATA_REG_START_OFFSET  0x
> > > -
> > > -#define BL_HEAD_OFFSET 0x00
> > > -#define BL_DATA_OFFSET 0x10
> > > -
> > > -/*
> > > - * Operational Device Status Register
> > > - *
> > > - * bit 7: Valid interrupt source
> > > - * bit 6 - 4: Reserved
> > > - * bit 3 - 2: Power status
> > > - * bit 1 - 0: Device status
> > > - */
> > > -#define REG_OP_STATUS 0x00
> > > -#define OP_STATUS_SRC 0x80
> > > -#define OP_STATUS_POWER   0x0c
> > > -#define OP_STATUS_DEV 0x03
> > > -#define OP_STATUS_MASK (OP_STATUS_SRC | OP_STATUS_POWER | OP_STATUS_DEV)
> > 

Re: [patch] mm, slab: initialize object alignment on cache creation

[David Rientjes]

On Tue, 23 Sep 2014, Christoph Lameter wrote:

> > The proper alignment defaults to BYTES_PER_WORD and can be overridden by
> > SLAB_RED_ZONE or the alignment specified by the caller.
> 
> Where does it default to BYTES_PER_WORD in __kmem_cache_create?
> 

Previous to commit 4590685546a3 ("mm/sl[aou]b: Common alignment code") 
which introduced this issue.
--
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/