[PATCH] HID: thingm: fix workqueue race on remove

[Jiri Kosina]

thingm_remove_rgb() needs to flush the workqueue after all the LED classes 
have been unregistered, otherwise the removal might race with another LED 
event coming, causing thingm_led_set() to schedule additional work after 
thingm_remove_rgb() has flushed it. This obviously causes oops later, as 
the scheduled work has been freed in the meantime.

In addition to that, move the hid_hw_stop() to an earlier place, so that 
dmesg is not polluted by failure messages about not being able to write 
the LED while the device is being shut down.

Reported-and-tested-by: Dylan Alex Simon 
Signed-off-by: Jiri Kosina 
---

Queued in hid.git#for-3.18/upstream

 drivers/hid/hid-thingm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
index 134be89..f206398 100644
--- a/drivers/hid/hid-thingm.c
+++ b/drivers/hid/hid-thingm.c
@@ -208,10 +208,10 @@ unregister_red:
 
 static void thingm_remove_rgb(struct thingm_rgb *rgb)
 {
-   flush_work(&rgb->work);
led_classdev_unregister(&rgb->red.ldev);
led_classdev_unregister(&rgb->green.ldev);
led_classdev_unregister(&rgb->blue.ldev);
+   flush_work(&rgb->work);
 }
 
 static int thingm_probe(struct hid_device *hdev, const struct hid_device_id 
*id)
@@ -286,10 +286,10 @@ static void thingm_remove(struct hid_device *hdev)
struct thingm_device *tdev = hid_get_drvdata(hdev);
int i;
 
+   hid_hw_stop(hdev);
+
for (i = 0; i < tdev->fwinfo->numrgb; ++i)
thingm_remove_rgb(tdev->rgb + i);
-
-   hid_hw_stop(hdev);
 }
 
 static const struct hid_device_id thingm_table[] = {

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

Re: [PATCH 3/4] KVM: x86: inject nested page faults on emulated instructions

[Gleb Natapov]

On Tue, Sep 02, 2014 at 05:13:49PM +0200, Paolo Bonzini wrote:
> This is required for the following patch to work correctly.  If a nested page
> fault happens during emulation, we must inject a vmexit, not a page fault.
> Luckily we already have the required machinery: it is enough to return
> X86EMUL_INTERCEPTED instead of X86EMUL_PROPAGATE_FAULT.
> 
I wonder why this patch is needed. X86EMUL_PROPAGATE_FAULT causes
ctxt->have_exception to be set to true in x86_emulate_insn().
x86_emulate_instruction() checks ctxt->have_exception and calls
inject_emulated_exception() if it is true. inject_emulated_exception()
calls kvm_propagate_fault() where we check if the fault was nested and
generate vmexit or a page fault accordingly.

> Reported-by: Valentine Sinitsyn 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/x86.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index e4ed85e07a01..9e3b74c044ed 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -416,6 +416,16 @@ void kvm_propagate_fault(struct kvm_vcpu *vcpu, struct 
> x86_exception *fault)
>   vcpu->arch.mmu.inject_page_fault(vcpu, fault);
>  }
>  
> +static inline int kvm_propagate_or_intercept(struct kvm_vcpu *vcpu,
> +  struct x86_exception *exception)
> +{
> + if (likely(!exception->nested_page_fault))
> + return X86EMUL_PROPAGATE_FAULT;
> +
> + vcpu->arch.mmu.inject_page_fault(vcpu, exception);
> + return X86EMUL_INTERCEPTED;
> +}
> +
>  void kvm_inject_nmi(struct kvm_vcpu *vcpu)
>  {
>   atomic_inc(&vcpu->arch.nmi_queued);
> @@ -4122,7 +4132,7 @@ static int kvm_read_guest_virt_helper(gva_t addr, void 
> *val, unsigned int bytes,
>   int ret;
>  
>   if (gpa == UNMAPPED_GVA)
> - return X86EMUL_PROPAGATE_FAULT;
> + return kvm_propagate_or_intercept(vcpu, exception);
>   ret = kvm_read_guest_page(vcpu->kvm, gpa >> PAGE_SHIFT, data,
> offset, toread);
>   if (ret < 0) {
> @@ -4152,7 +4162,7 @@ static int kvm_fetch_guest_virt(struct x86_emulate_ctxt 
> *ctxt,
>   gpa_t gpa = vcpu->arch.walk_mmu->gva_to_gpa(vcpu, addr, 
> access|PFERR_FETCH_MASK,
>   exception);
>   if (unlikely(gpa == UNMAPPED_GVA))
> - return X86EMUL_PROPAGATE_FAULT;
> + return kvm_propagate_or_intercept(vcpu, exception);
>  
>   offset = addr & (PAGE_SIZE-1);
>   if (WARN_ON(offset + bytes > PAGE_SIZE))
> @@ -4203,7 +4213,7 @@ int kvm_write_guest_virt_system(struct x86_emulate_ctxt 
> *ctxt,
>   int ret;
>  
>   if (gpa == UNMAPPED_GVA)
> - return X86EMUL_PROPAGATE_FAULT;
> + return kvm_propagate_or_intercept(vcpu, exception);
>   ret = kvm_write_guest(vcpu->kvm, gpa, data, towrite);
>   if (ret < 0) {
>   r = X86EMUL_IO_NEEDED;
> @@ -4350,7 +4360,7 @@ static int emulator_read_write_onepage(unsigned long 
> addr, void *val,
>   ret = vcpu_mmio_gva_to_gpa(vcpu, addr, &gpa, exception, write);
>  
>   if (ret < 0)
> - return X86EMUL_PROPAGATE_FAULT;
> + return kvm_propagate_or_intercept(vcpu, exception);
>  
>   /* For APIC access vmexit */
>   if (ret)
> -- 
> 1.8.3.1
> 
> 

--
Gleb.
--
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] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

[Sharma, Sanjeev]

-Original Message-
From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] 
Sent: Tuesday, August 19, 2014 3:01 PM
To: Sharma, Sanjeev
Cc: kra...@redhat.com; mdharm-...@one-eyed-alien.net; 
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; 
linux-s...@vger.kernel.org; Hans de Goede
Subject: Re: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote:
> Hi Greg,
> 
> Any feedback on this patch ?

The merge window ended 2 days ago, _and_ I'm at the kernel summit this week, 
_and_ my queue is currently sitting at:
$ mdfrm -c ~/mail/todo/
1317 messages in /home/gregkh/mail/todo/

So please be patient.  I'll get to it in a few weeks.

Please let me know when this is going to be merged ?

Thanks
Sanjeev

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

Re: [PATCH] eeepc-laptop: remove possible use of uninitialized value

[Paul Bolle]

On Thu, 2014-09-04 at 00:53 +0200, Frans Klaver wrote:
> In store_sys_acpi, if count equals zero, or parse_arg()s sscanf call
> fails, 'value' remains possibly uninitialized. In that case 'value'
> shouldn't be used to produce the store_sys_acpi()s return value.
> 
> Only test the return value of set_acpi() if we can actually call it.
> Return rv otherwise.
> 
> Signed-off-by: Frans Klaver 
> ---
>  drivers/platform/x86/eeepc-laptop.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/x86/eeepc-laptop.c 
> b/drivers/platform/x86/eeepc-laptop.c
> index bd533c2..41f12ba 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -279,10 +279,10 @@ static ssize_t store_sys_acpi(struct device *dev, int 
> cm,
>   int rv, value;
>  
>   rv = parse_arg(buf, count, &value);
> - if (rv > 0)
> - value = set_acpi(eeepc, cm, value);
> - if (value < 0)
> - return -EIO;
> + if (rv > 0) {
> + if (set_acpi(eeepc, cm, value) < 0)
> + return -EIO;
> + }
>   return rv;
>  }
>  

The warning that this code (currently) generated triggered me to submit
https://lkml.org/lkml/2014/7/1/150 , which uses a different approach to
get rid of it. I received no reactions so far. Here's that patch again:

>8
From: Paul Bolle 
Subject: [PATCH] eeepc-laptop: simplify parse_arg()

parse_arg() has three possible return values:
-EINVAL if sscanf(), in short, fails;
zero if "count" is zero; and
"count" in all other cases

But "count" will never be zero. See, parse_arg() is called by the
various store functions. And the callchain of these functions starts
with sysfs_kf_write(). And that function checks for a zero "count". So
we can stop checking for a zero "count", drop the "count" argument
entirely, and transform parse_arg() into a function that returns zero on
success or a negative error. That, in turn, allows to make those store
functions just return "count" on success. The net effect is that the
code becomes a bit easier to understand.

A nice side effect is that this GCC warning is silenced too:
drivers/platform/x86/eeepc-laptop.c: In function ‘store_sys_acpi’:
drivers/platform/x86/eeepc-laptop.c:279:10: warning: ‘value’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
  int rv, value;

Which is, of course, the reason to have a look at parse_arg().

Signed-off-by: Paul Bolle 
---
 drivers/platform/x86/eeepc-laptop.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/platform/x86/eeepc-laptop.c 
b/drivers/platform/x86/eeepc-laptop.c
index bd533c22be57..78515b850165 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -263,13 +263,11 @@ static int acpi_setter_handle(struct eeepc_laptop *eeepc, 
int cm,
 /*
  * Sys helpers
  */
-static int parse_arg(const char *buf, unsigned long count, int *val)
+static int parse_arg(const char *buf, int *val)
 {
-   if (!count)
-   return 0;
if (sscanf(buf, "%i", val) != 1)
return -EINVAL;
-   return count;
+   return 0;
 }
 
 static ssize_t store_sys_acpi(struct device *dev, int cm,
@@ -278,12 +276,13 @@ static ssize_t store_sys_acpi(struct device *dev, int cm,
struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
int rv, value;
 
-   rv = parse_arg(buf, count, &value);
-   if (rv > 0)
-   value = set_acpi(eeepc, cm, value);
+   rv = parse_arg(buf, &value);
+   if (rv < 0)
+   return rv;
+   value = set_acpi(eeepc, cm, value);
if (value < 0)
return -EIO;
-   return rv;
+   return count;
 }
 
 static ssize_t show_sys_acpi(struct device *dev, int cm, char *buf)
@@ -377,13 +376,13 @@ static ssize_t store_cpufv(struct device *dev,
return -EPERM;
if (get_cpufv(eeepc, &c))
return -ENODEV;
-   rv = parse_arg(buf, count, &value);
+   rv = parse_arg(buf, &value);
if (rv < 0)
return rv;
-   if (!rv || value < 0 || value >= c.num)
+   if (value < 0 || value >= c.num)
return -EINVAL;
set_acpi(eeepc, CM_ASL_CPUFV, value);
-   return rv;
+   return count;
 }
 
 static ssize_t show_cpufv_disabled(struct device *dev,
@@ -402,7 +401,7 @@ static ssize_t store_cpufv_disabled(struct device *dev,
struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
int rv, value;
 
-   rv = parse_arg(buf, count, &value);
+   rv = parse_arg(buf, &value);
if (rv < 0)
return rv;
 
@@ -412,7 +411,7 @@ static ssize_t store_cpufv_disabled(struct device *dev,
pr_warn("cpufv enabled (not officially supported "
"on this model)\n");
eeepc->cpufv_disabled = f

Re: task_numa_fault() && TASK_DEAD

[Peter Zijlstra]

On Wed, Sep 03, 2014 at 06:08:19PM +0200, Oleg Nesterov wrote:
> On 09/02, Oleg Nesterov wrote:
> >
> > The usage of TASK_DEAD in task_numa_fault() is wrong in any case.
> 
> Rik, I can't understand why task_numa_fault() needs this check at all,
> but "if (p->state == TASK_DEAD)" looks certainly wrong. You could replace
> this check with BUG_ON(p->state == TASK_DEAD). Perhaps you meant PF_EXITING?

Looking at 82727018b it appears the intent was to make sure we don't
re-create ->numa_fault after we free it. But you're right, we should
never get there with TASK_DEAD.

Also, given that task_numa_free() is called from __put_task_struct() I
tihnk we can safely delete this clause.

> And a stupid (really, I don't understand this code) question:
> 
>   /* for example, ksmd faulting in a user's mm */
>   if (!p->mm)
>   return;

In general kernel threads have !->mm, and those cannot do the
accounting. The only way to get here is through get_user_pages() with
tsk != current and/or mm != current->mm.

> OK, but perhaps it make sense to pass "mm" as another argument and do
> 
>   /* ksmd faulting in a user's mm, or debugger, or kthread use_mm() 
> caller */
>   if (p->mm != mm)
>   return;
> 
> ?

I'm still somewhat fuzzy in the brain but that doesn't appear to
actually work, use_mm() explicitly sets ->mm so in that case it would
match just fine.

That said; I don't think we really need to worry about this. The !->mm
case is special in that that cannot ever work, the other cases are
extremely rare and will not skew accounting much if anything.



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

Re: [PATCH resend 2/2] usb: serial: xsens_mt: always bind to interface number 1

[Frans Klaver]

Johan,

I noticed I submitted an error here. Will resend later today.

On Mon, Sep 1, 2014 at 11:39 AM, Frans Klaver  wrote:
> Probe is testing if the current interface provides two bulk endpoints.
> While this achieves the goal of only binding to the correct interface,
> we already know we can find the device on interface number 1. Stop
> checking the endpoints and just return successfully when interface
> number 1 is probed.
>
> Signed-off-by: Frans Klaver 
> ---
>  drivers/usb/serial/xsens_mt.c | 23 ---
>  1 file changed, 4 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/usb/serial/xsens_mt.c b/drivers/usb/serial/xsens_mt.c
> index d500ccd..ea67ed9 100644
> --- a/drivers/usb/serial/xsens_mt.c
> +++ b/drivers/usb/serial/xsens_mt.c
> @@ -41,28 +41,13 @@ static const struct usb_device_id id_table[] = {
>  };
>  MODULE_DEVICE_TABLE(usb, id_table);
>
> -static int has_required_endpoints(const struct usb_host_interface *interface)
> -{
> -   __u8 i;
> -   int has_bulk_in = 0;
> -   int has_bulk_out = 0;
> -
> -   for (i = 0; i < interface->desc.bNumEndpoints; ++i) {
> -   if (usb_endpoint_is_bulk_in(&interface->endpoint[i].desc))
> -   has_bulk_in = 1;
> -   else if 
> (usb_endpoint_is_bulk_out(&interface->endpoint[i].desc))
> -   has_bulk_out = 1;
> -   }
> -
> -   return has_bulk_in && has_bulk_out;
> -}
> -
>  static int xsens_mt_probe(struct usb_serial *serial,
> const struct usb_device_id *id)
>  {
> -   if (!has_required_endpoints(serial->interface->cur_altsetting))
> -   return -ENODEV;
> -   return 0;
> +   if (serial->interface->cur_altsetting.desc.bInterfaceNumber == 1)

This should be

if (serial->interface->cur_altsetting->desc.bInterfaceNumber == 1)


> +   return 0;
> +
> +   return -ENODEV;
>  }
>
>  static struct usb_serial_driver xsens_mt_device = {
> --
> 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 1/1] do_exit(): Solve possibility of BUG() due to race with try_to_wake_up()

[Peter Zijlstra]

On Wed, Sep 03, 2014 at 05:18:48PM +0200, Oleg Nesterov wrote:
> On 09/03, Peter Zijlstra wrote:
> >
> > On Wed, Sep 03, 2014 at 03:36:40PM +0200, Oleg Nesterov wrote:
> > >
> > >   // Ensure that the previous __set_current_state(RUNNING) can't
> > >   // leak after spin_unlock_wait()
> > >   smp_mb();
> > >   spin_unlock_wait();
> > >   // Another mb to ensure this too can't be reordered with unlock_wait
> > >   set_current_state(TASK_DEAD);
> > >
> > > What do you think looks better?
> >
> > spin_unlock_wait() would be a control dependency right? Therefore that
> > store could not creep up anyhow.
> 
> Hmm. indeed, thanks! This probably means that task_work_run() can use
> rmb() instead of mb().
> 
> What I can't understand is do we still need a compiler barrier or not.
> Probably "in theory yes" ?

Yes, this is where I'm forever in doubt as well. The worry is the
compiler reordering things, but I'm not sure how it would do that in
this case, then again, I've been shown to not be creative enough in
these cases many times before.

Paul might know, he's had much more exposure to compiler people.
--
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] PM / sleep: add configurable delay for pm_test

[Pavel Machek]

Hi!

> When CONFIG_PM_DEBUG=y, we provide a sysfs file (/sys/power/pm_test) for
> selecting one of a few suspend test modes, where rather than entering a
> full suspend state, the kernel will perform some subset of suspend
> steps, wait 5 seconds, and then resume back to normal operation.
> 
> This mode is useful for (among other things) observing the state of the
> system just before entering a sleep mode, for debugging or analysis
> purposes. However, a constant 5 second wait is not sufficient for some
> sorts of analysis; for example, on an SoC, one might want to use
> external tools to probe the power states of various on-chip controllers
> or clocks.

When you are doing this kind of analysis, perhaps directly modifying
kernel source is the way to go ...?

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

Re: [PATCH v5 03/12] sched: fix avg_load computation

[Vincent Guittot]

On 4 September 2014 01:43, Tim Chen  wrote:
> On Wed, 2014-09-03 at 13:09 +0200, Vincent Guittot wrote:
>> On 30 August 2014 14:00, Preeti U Murthy  wrote:
>> > Hi Vincent,
>> >
>> > On 08/26/2014 04:36 PM, Vincent Guittot wrote:
>> >> The computation of avg_load and avg_load_per_task should only takes into
>> >> account the number of cfs tasks. The non cfs task are already taken into
>> >> account by decreasing the cpu's capacity and they will be tracked in the
>> >> CPU's utilization (group_utilization) of the next patches
>> >>
>> >> Signed-off-by: Vincent Guittot 
>> >> ---
>> >>  kernel/sched/fair.c | 4 ++--
>> >>  1 file changed, 2 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> >> index 87b9dc7..b85e9f7 100644
>> >> --- a/kernel/sched/fair.c
>> >> +++ b/kernel/sched/fair.c
>> >> @@ -4092,7 +4092,7 @@ static unsigned long capacity_of(int cpu)
>> >>  static unsigned long cpu_avg_load_per_task(int cpu)
>> >>  {
>> >>   struct rq *rq = cpu_rq(cpu);
>> >> - unsigned long nr_running = ACCESS_ONCE(rq->nr_running);
>> >> + unsigned long nr_running = ACCESS_ONCE(rq->cfs.h_nr_running);
>> >>   unsigned long load_avg = rq->cfs.runnable_load_avg;
>> >>
>> >>   if (nr_running)
>> >> @@ -5985,7 +5985,7 @@ static inline void update_sg_lb_stats(struct lb_env 
>> >> *env,
>> >>   load = source_load(i, load_idx);
>> >>
>> >>   sgs->group_load += load;
>> >> - sgs->sum_nr_running += rq->nr_running;
>> >> + sgs->sum_nr_running += rq->cfs.h_nr_running;
>> >>
>> >>   if (rq->nr_running > 1)
>> >>   *overload = true;
>> >>
>> >
>> > Why do we probe rq->nr_running while we do load balancing? Should not we
>> > be probing cfs_rq->nr_running instead? We are interested after all in
>> > load balancing fair tasks right? The reason I ask this is, I was
>> > wondering if we need to make the above similar change in more places in
>> > load balancing.
>>
>> Hi Preeti,
>>
>> Yes, we should probably the test   rq->cfs.h_nr_running > 0 before
>> setting overload.
>>
>
> The overload indicator is used for knowing when we can totally avoid
> load balancing to a cpu that is about to go idle.
> We can avoid load balancing when no cpu has more than 1 task.  So if you
> have say just one fair task and multiple deadline tasks on a cpu,
> and another cpu about to go idle, you should turn on normal load
> balancing in the idle path by setting overload to true.

The newly idle load balancing can only affect CFS tasks so triggering
a load_balance because a cpu is overloaded by rt tasks only, will not
change anything.

>
> So setting overload should be set based on rq->nr_running and not on
> rq->cfs.h_nr_running.

We should probably use both values like below

if ((rq->nr_running > 1) && ( rq->cfs.h_nr_running > 0))

Regards,
Vincent
>
> Thanks.
>
> Tim
>
>
--
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: [kernel.org PATCH] Li Zefan is now the 3.4 stable maintainer

[Li Zefan]

Hi Guenter,

Sorry for my late reply.

On 2014/8/27 12:59, Guenter Roeck wrote:
> On Tue, Aug 26, 2014 at 04:08:58PM -0700, Greg KH wrote:
>> Li has agreed to continue to support the 3.4 stable kernel tree until
>> September 2016.  Update the releases.html page on kernel.org to reflect
>> this.
>>
> Li,
> 
> it would be great if you can send me information about your -stable queue,
> ie how you maintain it and where it is located. This will enable me to
> continue testing the stable queue for the 3.4 kernel.
> 

Thanks for testing LTS kernels!

This is my 3.4.y git tree:

https://git.kernel.org/cgit/linux/kernel/git/lizf/linux-3.4.y.git/

And this is the patch queue:

https://git.kernel.org/cgit/linux/kernel/git/lizf/linux-3.4.y-queue.git/

I use quilt. When I've added some patches to 3.4.y, I'll update this
queue. The patches and series file are under /patches. Currently there's
already a patch in the queue.

When I release a new version, I'll clean up the queue by removing all
the files under /patches.

Hope this is all the information you need. Please tell me if you need
me to slightly adjust my workflow so it's easier for you.

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

[PATCH 2/2] usb: serial: xsens_mt: always bind to interface number 1

[Frans Klaver]

Probe is testing if the current interface provides two bulk endpoints.
While this achieves the goal of only binding to the correct interface,
we already know we can find the device on interface number 1. Stop
checking the endpoints and just return successfully when interface
number 1 is probed.

Signed-off-by: Frans Klaver 
---
 drivers/usb/serial/xsens_mt.c | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/serial/xsens_mt.c b/drivers/usb/serial/xsens_mt.c
index d500ccd..3837d51 100644
--- a/drivers/usb/serial/xsens_mt.c
+++ b/drivers/usb/serial/xsens_mt.c
@@ -41,28 +41,13 @@ static const struct usb_device_id id_table[] = {
 };
 MODULE_DEVICE_TABLE(usb, id_table);
 
-static int has_required_endpoints(const struct usb_host_interface *interface)
-{
-   __u8 i;
-   int has_bulk_in = 0;
-   int has_bulk_out = 0;
-
-   for (i = 0; i < interface->desc.bNumEndpoints; ++i) {
-   if (usb_endpoint_is_bulk_in(&interface->endpoint[i].desc))
-   has_bulk_in = 1;
-   else if (usb_endpoint_is_bulk_out(&interface->endpoint[i].desc))
-   has_bulk_out = 1;
-   }
-
-   return has_bulk_in && has_bulk_out;
-}
-
 static int xsens_mt_probe(struct usb_serial *serial,
const struct usb_device_id *id)
 {
-   if (!has_required_endpoints(serial->interface->cur_altsetting))
-   return -ENODEV;
-   return 0;
+   if (serial->interface->cur_altsetting->desc.bInterfaceNumber == 1)
+   return 0;
+
+   return -ENODEV;
 }
 
 static struct usb_serial_driver xsens_mt_device = {
-- 
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: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

[Matt Fleming]

On Wed, 03 Sep, at 02:47:32PM, H. Peter Anvin wrote:
> 
> I think we really have two options: either fix up the GOT (which may be
> a null operation, if the GOT is empty) or we add a compile-time check
> that the GOT is empty, lest we will keep having these problems.
> 
> Since the GOT fixup loop is only a few instructions, it doesn't seem to
> be all that problematic to just do it -- but make sure we don't end up
> running it twice on any code path!

Urgh, I totally did make it run twice. My bad.

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

Re: [PATCH 1/3] GPIO: gpio-dwapb: Enable platform driver binding to MFD driver

[Sebastian Andrzej Siewior]

On 2014-09-04 02:00:03 [+], Chen, Alvin wrote:
> > 
> > > --- a/drivers/gpio/Kconfig
> > > +++ b/drivers/gpio/Kconfig
> > > @@ -136,7 +136,6 @@ config GPIO_DWAPB
> > >   tristate "Synopsys DesignWare APB GPIO driver"
> > >   select GPIO_GENERIC
> > >   select GENERIC_IRQ_CHIP
> > > - depends on OF_GPIO
> > you need either OF_GPIO or PCI
> Since we enable this module not only support OF devices, but also support MFD 
> devices, so we remove OF_GPIO dependency.
> For 'PCI', the original code is also not depended on PCI, and this patch also 
> not, do you think it is necessary?

if not PCI then you should add something likwe 
"depends on OF_GPIO || MFD"

looking further, you need also HAS_IOMEM for things like
devm_ioremap_resource(). Linus, wouldn't it make sense to group this
driver and make the block depend on it?

> > >  struct dwapb_gpio {
> > >   struct  device  *dev;
> > >   void __iomem*regs;
> > >   struct dwapb_gpio_port  *ports;
> > > - unsigned intnr_ports;
> > you could keep this the way it is
> It has been moved to 'pdata'.

I saw that. But there is no need keep a pointer to pdata across the
whole driver since only need nr_ports in the driver removal part of the
whole driver.

> > >   struct irq_domain   *domain;
> > > + const struct dwapb_gpio_platform_data   *pdata;
> > 
> > and not making this a member of this struct. I've been going up and down the
> > source and I don't see the need to marry dwapb_gpio to
> > dwapb_gpio_platform_data.
> > That dwapb_gpio_port_property thing has a long name. Could you just set it 
> > up,
> > pass it for registration and the free it? You can't free the pdata for the 
> > non-OF
> > tree but for the OF case you keep that struct around for no reason.
> > You could safe some memory and use pdata directly for setup.
> Here, 'pdata' is used for both OF and MFD. For MFD, 'pdata' is passed from 
> MFD.
> For OF, 'pdata' is getting from device nodes properties. Why do we have such 
> design? Because it can make the handling
> more easy for flowing routine. All necessary properties get from 'pdata', 
> never care it is from OF or MFD. And someone
> are working on replacing OF interface with a firmware agnostic 
> device_property* interface which will work with both OF and ACPI.
> More information for this design, please contact Darren Hart 
> . Darren Hart wrote to me:
> "Generally speaking, rather than if/else blocks throughout the code checking 
> if it is enumerated via open firmware or as a platform device,
> a cleaner approach is to check if the pdata is null, and if so, populate the 
> pdata from the open firmware description if present.
> Then use the pdata throughout the driver.

But isn't it enough to hold on to this pdata thing through the probe
function only? After probe is done you could drop that memory in the
OF-case, right?
 
> > > + irq_set_handler_data(port->pp->irq, gpio);
> > 
> > This does not look like it belongs here. It should only be used together 
> > with
> > irq_set_chained_handler() or am I missing here something?
> This patch reused ' dwapb_irq_handler', it needs the irq handler data. For ' 
> irq_set_handler_data', it just sets the irq data.
> Why do you think it must be used together with ' irq_set_chained_handler'?

because you do request_irq(…, driver_data). If you you look close to
irq_set_chained_handler() it does not have such a member. Thus it uses
irq_set_handler_data() for that same purpose.

Sebastian
--
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/3] smp: Adding new function wake_up_all_idle_cpus()

[Chuansheng Liu]

Currently kick_all_cpus_sync() can break non-polling idle cpus
thru IPI interrupts.

But sometimes we need to break the polling idle cpus immediately
to reselect the suitable c-state, also for non-idle cpus, we need
to do nothing if we try to wake up them.

Here adding one new function wake_up_all_idle_cpus() to let all cpus
out of idle based on function wake_up_if_idle().

Signed-off-by: Chuansheng Liu 
---
 include/linux/smp.h |2 ++
 kernel/smp.c|   22 ++
 2 files changed, 24 insertions(+)

diff --git a/include/linux/smp.h b/include/linux/smp.h
index 34347f2..93dff5f 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -100,6 +100,7 @@ int smp_call_function_any(const struct cpumask *mask,
  smp_call_func_t func, void *info, int wait);
 
 void kick_all_cpus_sync(void);
+void wake_up_all_idle_cpus(void);
 
 /*
  * Generic and arch helpers
@@ -148,6 +149,7 @@ smp_call_function_any(const struct cpumask *mask, 
smp_call_func_t func,
 }
 
 static inline void kick_all_cpus_sync(void) {  }
+static inline void wake_up_all_idle_cpus(void) {  }
 
 #endif /* !SMP */
 
diff --git a/kernel/smp.c b/kernel/smp.c
index aff8aa1..9e0d0b2 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "smpboot.h"
 
@@ -699,3 +700,24 @@ void kick_all_cpus_sync(void)
smp_call_function(do_nothing, NULL, 1);
 }
 EXPORT_SYMBOL_GPL(kick_all_cpus_sync);
+
+/**
+ * wake_up_all_idle_cpus - break all cpus out of idle
+ * wake_up_all_idle_cpus try to break all cpus which is in idle state even
+ * including idle polling cpus, for non-idle cpus, we will do nothing
+ * for them.
+ */
+void wake_up_all_idle_cpus(void)
+{
+   int cpu;
+
+   preempt_disable();
+   for_each_online_cpu(cpu) {
+   if (cpu == smp_processor_id())
+   continue;
+
+   wake_up_if_idle(cpu);
+   }
+   preempt_enable();
+}
+EXPORT_SYMBOL_GPL(wake_up_all_idle_cpus);
-- 
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 3/3] cpuidle: Using the wake_up_all_idle_cpus() to wake up all idle cpus

[Chuansheng Liu]

Currently kick_all_cpus_sync() or smp_call_function() can not
break the polling idle cpu immediately.

Here using wake_up_all_idle_cpus() which can wake up the polling idle
cpu quickly is much helpful for power.

Signed-off-by: Chuansheng Liu 
---
 drivers/cpuidle/cpuidle.c |9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index ee9df5e..d31e04c 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -223,7 +223,7 @@ void cpuidle_uninstall_idle_handler(void)
 {
if (enabled_devices) {
initialized = 0;
-   kick_all_cpus_sync();
+   wake_up_all_idle_cpus();
}
 }
 
@@ -530,11 +530,6 @@ EXPORT_SYMBOL_GPL(cpuidle_register);
 
 #ifdef CONFIG_SMP
 
-static void smp_callback(void *v)
-{
-   /* we already woke the CPU up, nothing more to do */
-}
-
 /*
  * This function gets called when a part of the kernel has a new latency
  * requirement.  This means we need to get all processors out of their C-state,
@@ -544,7 +539,7 @@ static void smp_callback(void *v)
 static int cpuidle_latency_notify(struct notifier_block *b,
unsigned long l, void *v)
 {
-   smp_call_function(smp_callback, NULL, 1);
+   wake_up_all_idle_cpus();
return NOTIFY_OK;
 }
 
-- 
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 1/3] sched: Add new API wake_up_if_idle() to wake up the idle cpu

[Chuansheng Liu]

Implementing one new API wake_up_if_idle(), which is used to
wake up the idle CPU.

Suggested-by: Andy Lutomirski 
Signed-off-by: Chuansheng Liu 
---
 include/linux/sched.h |1 +
 kernel/sched/core.c   |   19 +++
 2 files changed, 20 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 857ba40..3f89ac1 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1024,6 +1024,7 @@ struct sched_domain_topology_level {
 extern struct sched_domain_topology_level *sched_domain_topology;
 
 extern void set_sched_topology(struct sched_domain_topology_level *tl);
+extern void wake_up_if_idle(int cpu);
 
 #ifdef CONFIG_SCHED_DEBUG
 # define SD_INIT_NAME(type).name = #type
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1211575..b818548 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1620,6 +1620,25 @@ static void ttwu_queue_remote(struct task_struct *p, int 
cpu)
}
 }
 
+void wake_up_if_idle(int cpu)
+{
+   struct rq *rq = cpu_rq(cpu);
+   unsigned long flags;
+
+   if (!is_idle_task(rq->curr))
+   return;
+
+   if (set_nr_if_polling(rq->idle)) {
+   trace_sched_wake_idle_without_ipi(cpu);
+   } else {
+   raw_spin_lock_irqsave(&rq->lock, flags);
+   if (is_idle_task(rq->curr))
+   smp_send_reschedule(cpu);
+   /* Else cpu is not in idle, do nothing here */
+   raw_spin_unlock_irqrestore(&rq->lock, flags);
+   }
+}
+
 bool cpus_share_cache(int this_cpu, int that_cpu)
 {
return per_cpu(sd_llc_id, this_cpu) == per_cpu(sd_llc_id, that_cpu);
-- 
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: How is pivot_root intended to be used?

[Steven Stewart-Gallus]

Thank you, I think I will change the code to be like:

int old_root = open("/", O_DIRECTORY);
if (-1 == old_root) {
perror("open");
return EXIT_FAILURE;
}

if (-1 == syscall(__NR_pivot_root, ".", ".")) {
perror("pivot_root");
return EXIT_FAILURE;
}

if (-1 == fchdir(old_root)) {
perror("fchdir");
return EXIT_FAILURE;
}

if (-1 == umount2(".", MNT_DETACH)) {
perror("umount");
return EXIT_FAILURE;
}

if (-1 == close(old_root)) {
perror("close");
return EXIT_FAILURE;
}

if (-1 == chdir("/")) {
perror("chdir");
return EXIT_FAILURE;
}

This seems more understandable to me and less likely to have bugs later on.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 09/11] sched: add usage_load_avg

[Vincent Guittot]

The update of update_rq_runnable_avg interface is missing for
CONFIG_FAIR_GROUP_SCHED in the original patch
"[PATCH v5 09/12] sched: add usage_load_avg"

Signed-off-by: Vincent Guittot 
---

Hi Peter,

Do you prefer that I sent a new version of 
"[PATCH v5 09/12] sched: add usage_load_avg" patch with the fix or this fix is
enough ?

Regards,
Vincent

 kernel/sched/fair.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1fd2131..cbe3eff 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2462,7 +2462,8 @@ static inline void __update_group_entity_contrib(struct 
sched_entity *se)
 
 static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
 {
-   __update_entity_runnable_avg(rq_clock_task(rq), &rq->avg, runnable);
+   __update_entity_runnable_avg(rq_clock_task(rq), &rq->avg, runnable,
+   runnable);
__update_tg_runnable_avg(&rq->avg, &rq->cfs);
 }
 #else /* CONFIG_FAIR_GROUP_SCHED */
-- 
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: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

[Matt Fleming]

On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote:
> 
> So how about we:
> - add ASSERT(_got == _egot, "GOT entries not supported in
> boot/compressed") to the linker script
> - #define __nogotentry __attribute__((visibility(hidden))) somewhere
> in compiler.h or wherever else it belongs
> - add the __nogotentry qualifiers to each extern that requires it,
> which is currently:
> early_serial_base
> efi_early
> free_mem_end_ptr
> free_mem_ptr
> real_mode
> - get rid of the fixup code in assembly
 
Seems fine to me since it was Peter who introduced the GOT fixup asm
code in the first place.

> Any idea what the oldest GCC is we should support?

I'm pretty sure we still support GCC 3.x.x. The symbol visibility
support was added in GCC 4.x right?

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

Re: [PATCH 0/3] lockless sys_times and posix_cpu_clock_get

[Peter Zijlstra]

> Peter, Ingo, Andrew,
> 
> Do any of you have an objection to these patches?
> 
> Which tree should I merge them through?
> 
> I am happy to resubmit them against any tree, just let
> me know where you want the patches to go.

I suppose I can try and stuff them in -tip. I picked up this lot which
seems to still apply fine.

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/

[PATCHv4 0/3] new APIs to allocate buffer-cache with user specific flag

[Gioh Kim]

Hello,

This patch try to solve problem that a long-lasting page caches of
ext4 superblock and journaling of superblock disturb page migration.

I've been testing CMA feature on my ARM-based platform
and found that two page caches cannot be migrated.
They are page caches of superblock of ext4 filesystem and its journaling data.

Current ext4 reads superblock with sb_bread() that allocates page
from movable area. But the problem is that ext4 hold the page until
it is unmounted. If root filesystem is ext4 the page cannot be migrated
forever.
And also the journaling data for the superblock cannot be migreated.

I introduce new APIs that allocates page cache with specific flag passed by an
argument.
*_gfp APIs are for user want to set page allocation flag for page cache
allocation.
And *_unmovable APIs are for the user wants to allocate page cache from
non-movable area.

It is useful for ext4/ext3 and others that want to hold page cache for a long
time.

I have 3 patchs:

1. Patch 1/3: introduce a new API that create page cache with allocation flag
2. Patch 2/3: have ext4 use the new API to read superblock
3. Patch 3/3: have jbd/jbd2 use the new API to make journaling of superblock

This patchset is based on linux-next-20140814.

Thanks a lot.

Gioh Kim (3):
  fs.c: support buffer cache allocations with gfp modifiers
  ext4: use non-movable memory for the ext4 superblock
  jbd/jbd2: use non-movable memory for the jbd superblock

 fs/buffer.c |   45 -
 fs/ext4/super.c |6 +++---
 fs/jbd/journal.c|2 +-
 fs/jbd2/journal.c   |2 +-
 include/linux/buffer_head.h |   47 ++-
 5 files changed, 73 insertions(+), 29 deletions(-)

-- 
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: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

[Maarten Lankhorst]

Op 04-09-14 om 09:40 schreef Matt Fleming:
> On Thu, 04 Sep, at 08:47:57AM, Ard Biesheuvel wrote:
>> So how about we:
>> - add ASSERT(_got == _egot, "GOT entries not supported in
>> boot/compressed") to the linker script
>> - #define __nogotentry __attribute__((visibility(hidden))) somewhere
>> in compiler.h or wherever else it belongs
>> - add the __nogotentry qualifiers to each extern that requires it,
>> which is currently:
>> early_serial_base
>> efi_early
>> free_mem_end_ptr
>> free_mem_ptr
>> real_mode
>> - get rid of the fixup code in assembly
>  
> Seems fine to me since it was Peter who introduced the GOT fixup asm
> code in the first place.
>
>> Any idea what the oldest GCC is we should support?
> I'm pretty sure we still support GCC 3.x.x. The symbol visibility
> support was added in GCC 4.x right?
>
gcc 3.3.6 has documented visibility at least.

https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Function-Attributes.html#Function-Attributes

I couldn't find it in earlier manuals, but grepping through gcc 3.0.4 source 
code shows that it would appear to be supported there too.

~Maarten

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

[PATCHv4 3/3] jbd/jbd2: use non-movable memory for the jbd superblock

[Gioh Kim]

A long-lasting buffer-cache can distrub page migration so that
it must be allocated from non-movable area.

The journal_init_inode is creating a buffer-cache for superblock journaling.
The superblock exists until system shutdown so that the buffer-cache
for the superblock would also exist for a long time
and it can distrub page migration.

This patch make the buffer-cache be allocated from non-movable area
not to distrub page migration.

Signed-off-by: Gioh Kim 
Reviewed-by: Jan Kara 
---
 fs/jbd/journal.c  |2 +-
 fs/jbd2/journal.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index 06fe11e..aab8549 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -886,7 +886,7 @@ journal_t * journal_init_inode (struct inode *inode)
goto out_err;
}
 
-   bh = __getblk(journal->j_dev, blocknr, journal->j_blocksize);
+   bh = getblk_unmovable(journal->j_dev, blocknr, journal->j_blocksize);
if (!bh) {
printk(KERN_ERR
   "%s: Cannot get buffer for journal superblock\n",
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 67b8e30..65bd3b1 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -1237,7 +1237,7 @@ journal_t * jbd2_journal_init_inode (struct inode *inode)
goto out_err;
}
 
-   bh = __getblk(journal->j_dev, blocknr, journal->j_blocksize);
+   bh = getblk_unmovable(journal->j_dev, blocknr, journal->j_blocksize);
if (!bh) {
printk(KERN_ERR
   "%s: Cannot get buffer for journal superblock\n",
-- 
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/

[PATCHv4 2/3] ext4: use non-movable memory for the ext4 superblock

[Gioh Kim]

A buffer-cache for superblock is disturbing page migration,
because the buffer-cache is not released until unmount.
The buffer-cache must be allocated from non-movable area.

Signed-off-by: Gioh Kim 
Reviewed-by: Jan Kara 
---
 fs/ext4/super.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 32b43ad..e4b62b3 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3435,7 +3435,7 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
logical_sb_block = sb_block;
}
 
-   if (!(bh = sb_bread(sb, logical_sb_block))) {
+   if (!(bh = sb_bread_unmovable(sb, logical_sb_block))) {
ext4_msg(sb, KERN_ERR, "unable to read superblock");
goto out_fail;
}
@@ -3645,7 +3645,7 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
brelse(bh);
logical_sb_block = sb_block * EXT4_MIN_BLOCK_SIZE;
offset = do_div(logical_sb_block, blocksize);
-   bh = sb_bread(sb, logical_sb_block);
+   bh = sb_bread_unmovable(sb, logical_sb_block);
if (!bh) {
ext4_msg(sb, KERN_ERR,
   "Can't read superblock on 2nd try");
@@ -3867,7 +3867,7 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
 
for (i = 0; i < db_count; i++) {
block = descriptor_loc(sb, logical_sb_block, i);
-   sbi->s_group_desc[i] = sb_bread(sb, block);
+   sbi->s_group_desc[i] = sb_bread_unmovable(sb, block);
if (!sbi->s_group_desc[i]) {
ext4_msg(sb, KERN_ERR,
   "can't read group descriptor %d", i);
-- 
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: OT: Open letter to the Linux World

[Peter Zijlstra]

On Mon, Aug 18, 2014 at 08:15:45PM +0200, Alexander Holler wrote:
> 
> Hmm, a sane and maintainable solution would use C++ with which people don't
> have to manually build lists or hashes for every structure like in the
> kernel (generic programming done right). So you won't find much kernel
> developers there. ;)
> 

Troll a lot do you? ;-)

While I like C++ (and quite a number of kernel people can in fact write
C++ no problem) we can have a long debate about whether the STL is in
fact 'done right' :-)

Also, I don't think init (as in PID-1) should be a large program, and
therefore writing it in C would be entirely reasonable.
--
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/

[PATCHv4 1/3] fs.c: support buffer cache allocations with gfp modifiers

[Gioh Kim]

A buffer cache is allocated from movable area
because it is referred for a while and released soon.
But some filesystems are taking buffer cache for a long time
and it can disturb page migration.

New APIs are introduced to allocate buffer cache
with user specific flag.
*_gfp APIs are for user want to set page allocation flag for page cache
allocation.
And *_unmovable APIs are for the user wants to allocate page cache from
non-movable area.

Signed-off-by: Gioh Kim 
Reviewed-by: Jan Kara 
---
 fs/buffer.c |   45 -
 include/linux/buffer_head.h |   47 ++-
 2 files changed, 68 insertions(+), 24 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 8f05111..9a6029e 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -993,7 +993,7 @@ init_page_buffers(struct page *page, struct block_device 
*bdev,
  */
 static int
 grow_dev_page(struct block_device *bdev, sector_t block,
-   pgoff_t index, int size, int sizebits)
+ pgoff_t index, int size, int sizebits, gfp_t gfp)
 {
struct inode *inode = bdev->bd_inode;
struct page *page;
@@ -1002,8 +1002,8 @@ grow_dev_page(struct block_device *bdev, sector_t block,
int ret = 0;/* Will call free_more_memory() */
gfp_t gfp_mask;
 
-   gfp_mask = mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS;
-   gfp_mask |= __GFP_MOVABLE;
+   gfp_mask = (mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS) | gfp;
+
/*
 * XXX: __getblk_slow() can not really deal with failure and
 * will endlessly loop on improvised global reclaim.  Prefer
@@ -1058,7 +1058,7 @@ failed:
  * that page was dirty, the buffers are set dirty also.
  */
 static int
-grow_buffers(struct block_device *bdev, sector_t block, int size)
+grow_buffers(struct block_device *bdev, sector_t block, int size, gfp_t gfp)
 {
pgoff_t index;
int sizebits;
@@ -1085,11 +1085,12 @@ grow_buffers(struct block_device *bdev, sector_t block, 
int size)
}
 
/* Create a page with the proper size buffers.. */
-   return grow_dev_page(bdev, block, index, size, sizebits);
+   return grow_dev_page(bdev, block, index, size, sizebits, gfp);
 }
 
-static struct buffer_head *
-__getblk_slow(struct block_device *bdev, sector_t block, int size)
+struct buffer_head *
+__getblk_slow(struct block_device *bdev, sector_t block,
+unsigned size, gfp_t gfp)
 {
/* Size must be multiple of hard sectorsize */
if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
@@ -,13 +1112,14 @@ __getblk_slow(struct block_device *bdev, sector_t 
block, int size)
if (bh)
return bh;
 
-   ret = grow_buffers(bdev, block, size);
+   ret = grow_buffers(bdev, block, size, gfp);
if (ret < 0)
return NULL;
if (ret == 0)
free_more_memory();
}
 }
+EXPORT_SYMBOL(__getblk_slow);
 
 /*
  * The relationship between dirty buffers and dirty pages:
@@ -1371,24 +1373,25 @@ __find_get_block(struct block_device *bdev, sector_t 
block, unsigned size)
 EXPORT_SYMBOL(__find_get_block);
 
 /*
- * __getblk will locate (and, if necessary, create) the buffer_head
+ * __getblk_gfp() will locate (and, if necessary, create) the buffer_head
  * which corresponds to the passed block_device, block and size. The
  * returned buffer has its reference count incremented.
  *
- * __getblk() will lock up the machine if grow_dev_page's try_to_free_buffers()
- * attempt is failing.  FIXME, perhaps?
+ * __getblk_gfp() will lock up the machine if grow_dev_page's
+ * try_to_free_buffers() attempt is failing.  FIXME, perhaps?
  */
 struct buffer_head *
-__getblk(struct block_device *bdev, sector_t block, unsigned size)
+__getblk_gfp(struct block_device *bdev, sector_t block,
+unsigned size, gfp_t gfp)
 {
struct buffer_head *bh = __find_get_block(bdev, block, size);
 
might_sleep();
if (bh == NULL)
-   bh = __getblk_slow(bdev, block, size);
+   bh = __getblk_slow(bdev, block, size, gfp);
return bh;
 }
-EXPORT_SYMBOL(__getblk);
+EXPORT_SYMBOL(__getblk_gfp);
 
 /*
  * Do async read-ahead on a buffer..
@@ -1404,24 +1407,28 @@ void __breadahead(struct block_device *bdev, sector_t 
block, unsigned size)
 EXPORT_SYMBOL(__breadahead);
 
 /**
- *  __bread() - reads a specified block and returns the bh
+ *  __bread_gfp() - reads a specified block and returns the bh
  *  @bdev: the block_device to read from
  *  @block: number of block
  *  @size: size (in bytes) to read
- * 
+ *  @gfp: page allocation flag
+ *
  *  Reads a specified block, and returns buffer head that contains it.
+ *  The page cache can be allocated from non-movable area
+ *  not to prevent page migration if you set gfp to zero.
  *  It returns NULL if the block was unreadable.
  */
 str

Re: [PATCH] eeepc-laptop: remove possible use of uninitialized value

[Frans Klaver]

On Thu, Sep 4, 2014 at 9:08 AM, Paul Bolle  wrote:
> On Thu, 2014-09-04 at 00:53 +0200, Frans Klaver wrote:
>> In store_sys_acpi, if count equals zero, or parse_arg()s sscanf call
>> fails, 'value' remains possibly uninitialized. In that case 'value'
>> shouldn't be used to produce the store_sys_acpi()s return value.
>>
>> Only test the return value of set_acpi() if we can actually call it.
>> Return rv otherwise.
>>
>> Signed-off-by: Frans Klaver 
>> ---
>>  drivers/platform/x86/eeepc-laptop.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/platform/x86/eeepc-laptop.c 
>> b/drivers/platform/x86/eeepc-laptop.c
>> index bd533c2..41f12ba 100644
>> --- a/drivers/platform/x86/eeepc-laptop.c
>> +++ b/drivers/platform/x86/eeepc-laptop.c
>> @@ -279,10 +279,10 @@ static ssize_t store_sys_acpi(struct device *dev, int 
>> cm,
>>   int rv, value;
>>
>>   rv = parse_arg(buf, count, &value);
>> - if (rv > 0)
>> - value = set_acpi(eeepc, cm, value);
>> - if (value < 0)
>> - return -EIO;
>> + if (rv > 0) {
>> + if (set_acpi(eeepc, cm, value) < 0)
>> + return -EIO;
>> + }
>>   return rv;
>>  }
>>
>
> The warning that this code (currently) generated triggered me to submit
> https://lkml.org/lkml/2014/7/1/150 , which uses a different approach to
> get rid of it. I received no reactions so far. Here's that patch again:
>
> >8
> From: Paul Bolle 
> Subject: [PATCH] eeepc-laptop: simplify parse_arg()
>
> parse_arg() has three possible return values:
> -EINVAL if sscanf(), in short, fails;
> zero if "count" is zero; and
> "count" in all other cases
>
> But "count" will never be zero. See, parse_arg() is called by the
> various store functions. And the callchain of these functions starts
> with sysfs_kf_write(). And that function checks for a zero "count". So
> we can stop checking for a zero "count", drop the "count" argument
> entirely, and transform parse_arg() into a function that returns zero on
> success or a negative error. That, in turn, allows to make those store
> functions just return "count" on success. The net effect is that the
> code becomes a bit easier to understand.
>
> A nice side effect is that this GCC warning is silenced too:
> drivers/platform/x86/eeepc-laptop.c: In function ‘store_sys_acpi’:
> drivers/platform/x86/eeepc-laptop.c:279:10: warning: ‘value’ may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>   int rv, value;
>
> Which is, of course, the reason to have a look at parse_arg().
>
> Signed-off-by: Paul Bolle 

Curious. I hadn't found this one when searching for earlier patches.

Thanks,
Frans


> ---
>  drivers/platform/x86/eeepc-laptop.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/platform/x86/eeepc-laptop.c 
> b/drivers/platform/x86/eeepc-laptop.c
> index bd533c22be57..78515b850165 100644
> --- a/drivers/platform/x86/eeepc-laptop.c
> +++ b/drivers/platform/x86/eeepc-laptop.c
> @@ -263,13 +263,11 @@ static int acpi_setter_handle(struct eeepc_laptop 
> *eeepc, int cm,
>  /*
>   * Sys helpers
>   */
> -static int parse_arg(const char *buf, unsigned long count, int *val)
> +static int parse_arg(const char *buf, int *val)
>  {
> -   if (!count)
> -   return 0;
> if (sscanf(buf, "%i", val) != 1)
> return -EINVAL;
> -   return count;
> +   return 0;
>  }
>
>  static ssize_t store_sys_acpi(struct device *dev, int cm,
> @@ -278,12 +276,13 @@ static ssize_t store_sys_acpi(struct device *dev, int 
> cm,
> struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
> int rv, value;
>
> -   rv = parse_arg(buf, count, &value);
> -   if (rv > 0)
> -   value = set_acpi(eeepc, cm, value);
> +   rv = parse_arg(buf, &value);
> +   if (rv < 0)
> +   return rv;
> +   value = set_acpi(eeepc, cm, value);
> if (value < 0)
> return -EIO;
> -   return rv;
> +   return count;
>  }
>
>  static ssize_t show_sys_acpi(struct device *dev, int cm, char *buf)
> @@ -377,13 +376,13 @@ static ssize_t store_cpufv(struct device *dev,
> return -EPERM;
> if (get_cpufv(eeepc, &c))
> return -ENODEV;
> -   rv = parse_arg(buf, count, &value);
> +   rv = parse_arg(buf, &value);
> if (rv < 0)
> return rv;
> -   if (!rv || value < 0 || value >= c.num)
> +   if (value < 0 || value >= c.num)
> return -EINVAL;
> set_acpi(eeepc, CM_ASL_CPUFV, value);
> -   return rv;
> +   return count;
>  }
>
>  static ssize_t show_cpufv_disabled(struct device *dev,
> @@ -402,7 +401,7 @@ static ssize_t store_cpufv_disabled(struct device *dev,
> struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
> int rv, value;
>
> -   rv = parse_arg(buf, 

Re: [PATCH] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set

[Anton Altaparmakov]

On 4 Sep 2014, at 03:30, Andrew Morton  wrote:
> __GFP_FS and __GFP_IO are (or were) for communicating to vmscan: don't
> enter the fs for writepage, don't write back swapcache.
> 
> I guess those concepts have grown over time without a ton of thought
> going into it.  Yes, I suppose that if a filesystem's writepage is
> called (for example) it expects that it will be able to perform
> writeback and it won't check (or even be passed) the __GFP_IO setting.
> 
> So I guess we could say that !__GFP_FS && GFP_IO is not implemented and
> shouldn't occur.
> 
> That being said, it still seems quite bad to disable VFS cache
> shrinking for PF_MEMALLOC_NOIO allocation attempts.

I think what it really boils down to is that file systems cannot allow 
recursion into _that_ file system so if VFS/VM shrinking could skip over all 
inodes/dentries/pages that are associated with the superblock of the volume for 
which the allocation is being done then that would be just fine.

An alternative would be that the file systems would need to be passed in a flag 
that will tell them that it is not safe to take locks and then file systems 
that need to take a lock could return with -EDEADLOCK and the VM can then skip 
over those entries and reclaim others.  Though I think it would be more 
efficient for the VFS/VM to simply not call into the file system that is doing 
the allocation as above...

Best regards,

Anton
-- 
Anton Altaparmakov  (replace at with @)
University of Cambridge Information Services, Roger Needham Building
7 JJ Thomson Avenue, Cambridge, CB3 0RB, UK

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

[PATCH net-next v3 1/2] r8152: change the location of rtl8152_set_mac_address

[Hayes Wang]

Exchange the location of rtl8152_set_mac_address() and
set_ethernet_addr(). Then, the set_ethernet_addr() could
set the MAC address by calling rtl8152_set_mac_address()
later.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 80b0179..b5ff933 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -975,6 +975,23 @@ void write_mii_word(struct net_device *netdev, int phy_id, 
int reg, int val)
 static int
 r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags);
 
+static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
+{
+   struct r8152 *tp = netdev_priv(netdev);
+   struct sockaddr *addr = p;
+
+   if (!is_valid_ether_addr(addr->sa_data))
+   return -EADDRNOTAVAIL;
+
+   memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
+
+   ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
+   pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES, 8, addr->sa_data);
+   ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
+
+   return 0;
+}
+
 static inline void set_ethernet_addr(struct r8152 *tp)
 {
struct net_device *dev = tp->netdev;
@@ -1003,23 +1020,6 @@ static inline void set_ethernet_addr(struct r8152 *tp)
}
 }
 
-static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
-{
-   struct r8152 *tp = netdev_priv(netdev);
-   struct sockaddr *addr = p;
-
-   if (!is_valid_ether_addr(addr->sa_data))
-   return -EADDRNOTAVAIL;
-
-   memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
-
-   ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
-   pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES, 8, addr->sa_data);
-   ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
-
-   return 0;
-}
-
 static void read_bulk_callback(struct urb *urb)
 {
struct net_device *netdev;
-- 
1.9.3

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

Re: [PATCH 1/2] perf/x86/intel: Add Haswell-EP uncore support

[Peter Zijlstra]

On Fri, Aug 22, 2014 at 07:29:26AM +0200, Andi Kleen wrote:
> > diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c 
> > b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> > index 4785ee8..2485fd9 100644
> > --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> > +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> > @@ -883,6 +883,8 @@ static int __init uncore_pci_init(void)
> > case 62: /* Ivy Bridge-EP */
> > ret = ivbep_uncore_pci_init();
> > break;
> > +   case 63: /* Haswell-EP */
> > +   ret = hswep_uncore_pci_init();
> 
> Is the lack of break intentional? If yes please add a /* FALL THROUGH */
> comment.

This does look inconsistent with the surrounding code, which does
suggest it was indeed an oversight and not on purpose.

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

Re: [PATCH resend 2/2] usb: serial: xsens_mt: always bind to interface number 1

[Johan Hovold]

On Thu, Sep 04, 2014 at 09:12:05AM +0200, Frans Klaver wrote:

> >  static int xsens_mt_probe(struct usb_serial *serial,
> > const struct usb_device_id *id)
> >  {
> > -   if (!has_required_endpoints(serial->interface->cur_altsetting))
> > -   return -ENODEV;
> > -   return 0;
> > +   if (serial->interface->cur_altsetting.desc.bInterfaceNumber == 1)
> 
> This should be
> 
> if (serial->interface->cur_altsetting->desc.bInterfaceNumber == 1)

So this wasn't even compile tested. Always test your patches before
submission, including trivial ones.

Is the new version tested on actual hardware?

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

Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable

[Michael S. Tsirkin]

On Thu, Sep 04, 2014 at 09:51:33AM +0300, Eliezer Tamir wrote:
> On 03/09/2014 10:51, Michael S. Tsirkin wrote:
> > On Wed, Sep 03, 2014 at 09:49:10AM +0300, Eliezer Tamir wrote:
> >> On 02/09/2014 11:31, Michael S. Tsirkin wrote:
> >>> On Tue, Sep 02, 2014 at 09:15:18AM +0300, Eliezer Tamir wrote:
> 
> >> Busy polling is not a general purpose feature, it's not something you
> >> can casually turn on and will "just work". Most applications should not
> >> be using busy polling. Currently it is used by multiserver applications
> >> that you spend days tuning to specific platforms.
> >>
> >> What the user wants is to lower both avg and maximum latencies, at the
> >> expense of everything else including power efficiency and sometimes
> >> even throughput. The only exception is making the system crash ;)
> >>
> >> While letting other things take precedence over busy polling might not
> >> hurt the avg latency much, it will kill your maximum latency.
> > 
> > If scheduler happens to run both server and client on the
> > same CPU, polling will hurt maximum latency even more.
> > So I guess different users want different things.
> > 
> > How about applications giving us a hint what they prefer?
> > For example, a new flag that says "I don't have anything useful to do so
> > let's do busy polling but my server is on the local system, so please
> > only poll if CPU is otherwise idle".
> 
> I'm sorry for being ambiguous, when I said multi-server application, I
> meant an app that runs on more than one server machine.
> 
> The loopback test is as far as I know not interesting.

It's not interesting for ethernet NIC vendors :).

But people do deploy servers and clients on the same box, and
improving latency for them would be benefitial.

Loopback is widely used by desktops, containers, vpns, etc etc

Getting more theoretical, even with external networking, any
application processing traffic in more than one thread behaves the same.
For example, it's not uncommon to have a thread get messages from a
socket, and pass them out to other threads for processing.  At the
moment the polling thread would sometimes delay the processing if it
lands on the same CPU.

> Of course if busypoll becomes interesting for virtualization over
> loopback,

IMO bringing up virtualization just muddies the waters, it's a general
problem that arises whenever you run a lot of stuff on your CPU.

> I have no problem with that, provided that there is a way to
> get the old behavior and that it is well documented.
> 
> -Eliezer

I agree here, since some application might be relying on the old behavior.

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

Re: [PATCH v4 00/22] perf: Add infrastructure and support for Intel PT

[Peter Zijlstra]

On Tue, Sep 02, 2014 at 02:18:16PM -0600, Mathieu Poirier wrote:
> Pawell, many thanks for looping me in.
> 
> I am definitely not a perf-internal guru and as such won't be able to
> comment on the implementation.  On the flip side it is easy for me to see
> how the work on coresight done at Linaro can be made to tie-in what
> Alexander is proposing.  Albeit not at the top of the priority list at this
> time, integration with perf (and ftrace) is definitely on the roadmap.
> 
> Powell is correct in his statement that Linaro's work in HW trace decoding
> is (currently) mainly focused on processor tracing but that will change
> when we have the basic infrastructure upstreamed.
> 
> Last but not least it would be interesting to have more information on the
> "sideband data".  With coresight we have something called "metadata", also
> related to how the trace source was configured and instrumental to proper
> trace decoding.  I'm pretty sure we are facing the same problems.

So we use the sideband or AUX data stream to export the 'big' data
stream generated by the CPU in an opaque manner. For every AUX data
block 'posted' we issue an event into the regular data buffer that
describes it.

I was assuming that both ARM and MIPS would generate a single data
stream as well. So please do tell more about your meta-data; is that a
one time thing or a second continuous stream of data, albeit smaller
than the main stream?

The way I read your explanation it is a one time blob generated once you
setup the hardware. I suppose we could either dump it once into the
normal data stream or maybe dump it once every time we generate an AUX
buffer event into the normal data stream -- if its not too big.

In any case, can you point us to public documentation of the ARM
CoreSight stuff and maybe provide a short summary for the tl;dr crowd?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 0/6] Per-user clock constraints

[Tomeu Vizoso]

On 09/03/2014 07:26 PM, Mike Turquette wrote:
> Quoting Tomeu Vizoso (2014-09-03 08:29:07)
>> Hi,
>>
>> I'm sending this v9 in order to fix a few build errors found by Intel's 0day 
>> build farm. Notable changes are:
>>
>> * Changes to mxs-saif.c have been folded into 2/6, in order for 
>> bisectability to be preserved.
>>
>> * All floor constraints are applied first, then all ceiling constraints. 
>> This is to keep the behavior deterministic and to prevent any situation in 
>> which floor constraints could trump over ceiling constraints.
>>
>> * A WARN has been added to flag inconsistent ranges of constraints.
>>
>> * Redundant includes of linux/clk.h have been removed.
>>
>> These series depend on Mike's patches at [0] and is rebased on top of 
>> today's clk-next.
> 
> Applied to clk-next! Thanks much for your hard work on this series. It
> has turned out pretty nice. And thanks to Rabin for the original
> proposal and to Andrew Lunn for helping to resolve the Kirkwood issues.

Indeed, I'm very grateful at all the help that these series have gotten
along the way.

> I would not be surprised if we have to fix some stuff up leading up to
> the next merge window. The split between struct clk and struct clk_core
> will likely cause some of the pending patches on the list to break and I
> might ask for your help with the Coccinelle script ;-)

I have the same feeling, but I think we should be able to deal with them
fairly quickly and painlessly. Since yesterday I haven't gotten any 0day
build error, but I'm not sure the build bots have tried my branch yet.

Thanks,

Tomeu

> I guess we'll know soon if things start to explode once this hits
> linux-next...
> 
> Thanks again,
> Mike
> 
>>
>> Follows the original cover letter blurb:
>>
>> I'm retaking Rabin's patches [1] for splitting the clk API in two: one API 
>> for
>> clk consumers and another for providers. The consumer API uses a clk 
>> structure
>> that just keeps track of the consumer and has a reference to the actual
>> clk_core struct, which is used internally.
>>
>> I have kept a patch from Rabin that aims to aid in debugging nested
>> enable/disable calls, though my personal aim is to allow more than one 
>> consumer
>> to influence the final, effective frequency rate. For now this is limited to
>> setting floor and ceiling constraints, with the short-term aim of allowing
>> devfreq and thermal drivers to set floor and ceiling frequencies on the 
>> memory
>> clock, respectively.
>>
>> For those functions in the consumer clk API that were called from providers, 
>> I
>> have added variants to clk-provider.h that are the same only that accept a
>> clk_core instead. These functions are prefixed with clk_provider_.
>>
>> Patch 1/7 just adds a bunch of defines with the goal of having all the 
>> renames
>> in their own commit while preserving git-bisectability, with patch 3/7
>> containing the rename itself as generated by the Coccinelle script in [2].
>> Patch 2/7 is needed because sound/soc/mxs/mxs-saif.c calls both the consumer
>> and the provider API. The actual implementation of the API split comes in 
>> patch
>> 4/7. I will be happy to organize the refactoring differently if anybody has a
>> better idea.
>>
>> Patch 5/7 warns when there's an unbalanced usage of the enable and disable
>> APIs, and patch 6/7 adds the API for setting floor and ceiling frequencies, 
>> per
>> consumer. Patch 7/7 will warn when prepare/unprepare are used unbalanced,
>> printing the code location of the last call to unprepare.
>>
>> [0] http://thread.gmane.org/gmane.linux.kernel/1778132
>> [1] http://thread.gmane.org/gmane.linux.kernel/1402006
>> [2] 
>> http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=clk-refactoring-9
>>
>> Thanks,
>>
>> Tomeu
>>
>> Tomeu Vizoso (6):
>>   clk: Add temporary mapping to the existing API
>>   clk: Move all drivers to use internal API
>>   clk: use struct clk only for external API
>>   clk: per-user clock accounting for debug
>>   clk: Add floor and ceiling constraints to clock rates
>>   clk: Warn of unbalanced clk_prepare() calls
>>
>>  arch/arm/mach-dove/common.c   |  10 +-
>>  arch/arm/mach-imx/clk-busy.c  |   9 +-
>>  arch/arm/mach-imx/clk-fixup-div.c |   4 +-
>>  arch/arm/mach-imx/clk-fixup-mux.c |   4 +-
>>  arch/arm/mach-imx/clk-gate2.c |   4 +-
>>  arch/arm/mach-imx/clk-imx1.c  |   3 +-
>>  arch/arm/mach-imx/clk-imx21.c |   3 +-
>>  arch/arm/mach-imx/clk-imx25.c |   9 +-
>>  arch/arm/mach-imx/clk-imx27.c |   5 +-
>>  arch/arm/mach-imx/clk-imx31.c |  11 +-
>>  arch/arm/mach-imx/clk-imx35.c |  23 +-
>>  arch/arm/mach-imx/clk-imx51-imx53.c   |  78 +--
>>  arch/arm/mach-imx/clk-imx6q.c |  54 +-
>>  arch/arm/mach-imx/clk-imx6sl.c|  14 +-
>>  arch/arm/mach-imx/clk-imx6sx.c|  98 ++--
>>  arch/arm/mach-i

Re: [SMP BUG?] the return value of is_smp() is bug?

[Peter Maydell]

On 4 September 2014 02:13, long.wanglong  wrote:
> When i revert the commit bc41b8724f24, the secondary core can boot.
> The problem is that qemu doesn't provide emulation of the SCU base
> address register. When reading the SCU base, qemu just return 0.

You need to upgrade your QEMU -- we improved the emulation
of all our Cortex-A9 boards to make sure they set valid values
for the base address register, in order to fix exactly this regression.
QEMU 2.0 or later should work.

(As an aside, I think the Aegis quirk test is pretty ugly:
"base address happens to be set to zero" is not exactly
a very reliable way to identify a particular SoC. However
in this case QEMU was emulating real h/w insufficiently
accurately, so we fixed it.)

thanks
-- PMM
--
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 5/5] Clocksource: Flextimer: Use Macro for clock source selection.

[Thomas Gleixner]

On Thu, 4 Sep 2014, li.xi...@freescale.com wrote:
> > So you remove the FTM_SC_PS_MASK without mentioning it in the
> > changelog. Either this is by mistake or it wants to be documented WHY
> > it is not needed in the first place.
> > 
> 
> This is just prepare for the other new features in the future.

So split it into a separate patch and provide a proper changelog WHY
you remove it.

Thanks,

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

RE: [PATCH 2/5] Clocksource: Flextimer: Use internal clocksource read API.

[Thomas Gleixner]

On Thu, 4 Sep 2014, li.xi...@freescale.com wrote:

> > Subject: Re: [PATCH 2/5] Clocksource: Flextimer: Use internal clocksource 
> > read
> > API.
> > 
> > On Tue, 26 Aug 2014, Xiubo Li wrote:
> > 
> > > Since the Flextimer device will be implemented in BE mode on
> > > LS1 SoC, and in LE mode on Vybrid, LS2 SoCs, so here we need
> > > the endianness judgment before doing the mmio.
> > 
> > Brilliant. So for every clocksource read you take a conditional.
> > 
> > > @@ -238,7 +243,7 @@ static int __init ftm_clocksource_init(unsigned long
> > freq)
> > >   sched_clock_register(ftm_read_sched_clock, 16, freq / (1 << priv->ps));
> > >   err = clocksource_mmio_init(priv->clksrc_base + FTM_CNT, "fsl-ftm",
> > >   freq / (1 << priv->ps), 300, 16,
> > > - clocksource_mmio_readl_up);
> > > + ftm_clocksource_read_up);
> > 
> > What's wrong with having endianess aware clocksource_mmio functions
> > and make the decision at init time?
> > 
> 
> Since the FTM will be in BE mode on LS1 platform, but will be in LE mode
> On LS2 platform.
> 
> And ftm_clocksource_read_up() will adapt to this different.

You are missing the point. Why do you want a conditional in a hot
path? You know at init time whether the thing is BE or LE, so you can
have separate functions for BE/LE or whatever and register that with
clocksource_mmio_init(). i.e.

 if (be)
clocksource_mmio_init(., cs_read_be);
 else if (le)
clocksource_mmio_init(., cs_read_le);
 else if (magic)
clocksource_mmio_init(., cs_read_magic);

Hmm?

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

Re: [PATCH] staging: comedi: hwdrv_apci1500: use dev->class_dev in calls to dev_warn()

[Ian Abbott]

On 2014-09-04 00:58, Chase Southwood wrote:

git-grep reveals that hwdrv_apci1500.c is the only file in comedi that uses
dev->hw_dev in calls to dev_{err,warn}().  The rest of the drivers pass
dev->class_dev to these macros instead.  Switch the dev_warn() calls in
this driver to use dev->class_dev as well, for consistency.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
As an aside, it looks like lots of these cases are actually error
conditions that might be more appropriate use cases for dev_err().  But
they could be changed in a follow on patch, this is enough for this one.
  .../comedi/drivers/addi-data/hwdrv_apci1500.c  | 104 ++---
  1 file changed, 52 insertions(+), 52 deletions(-)


Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-
--
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] mfd: da9052: Avoid setting read_flag_mask for da9052-i2c driver

[Lee Jones]

On Sat, 16 Aug 2014, Axel Lin wrote:

> Current code init regmap with &da9052_regmap_config for both da9052-spi and
> da9052-i2c drivers. da9052-spi sets the read_flag_mask.
> The same setting may be applied for da9052-i2c if da9052-spi driver is loaded
> first because they actually use the same regmap_config setting.
> Fix this issue by using a local variable for regmap_config in da9052-spi 
> driver,
> so the settings in spi driver won't impact the settings in i2c driver.
> Also makes da9052_regmap_config const to avoid similar issue.
> 
> Signed-off-by: Axel Lin 
> ---
> Hi Adam and Steve,

Applied with Adam's Ack.

> Any chance to test this patch?
> 
> Thanks,
> Axel
>  drivers/mfd/da9052-core.c | 2 +-
>  drivers/mfd/da9052-spi.c  | 7 ---
>  include/linux/mfd/da9052/da9052.h | 2 +-
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index e8af816..52a0c2f 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -522,7 +522,7 @@ static const struct mfd_cell da9052_subdev_info[] = {
>   },
>  };
>  
> -struct regmap_config da9052_regmap_config = {
> +const struct regmap_config da9052_regmap_config = {
>   .reg_bits = 8,
>   .val_bits = 8,
>  
> diff --git a/drivers/mfd/da9052-spi.c b/drivers/mfd/da9052-spi.c
> index 17666b4..45ae0b7 100644
> --- a/drivers/mfd/da9052-spi.c
> +++ b/drivers/mfd/da9052-spi.c
> @@ -23,6 +23,7 @@
>  
>  static int da9052_spi_probe(struct spi_device *spi)
>  {
> + struct regmap_config config;
>   int ret;
>   const struct spi_device_id *id = spi_get_device_id(spi);
>   struct da9052 *da9052;
> @@ -40,10 +41,10 @@ static int da9052_spi_probe(struct spi_device *spi)
>  
>   spi_set_drvdata(spi, da9052);
>  
> - da9052_regmap_config.read_flag_mask = 1;
> - da9052_regmap_config.write_flag_mask = 0;
> + config = da9052_regmap_config;
> + config.read_flag_mask = 1;
>  
> - da9052->regmap = devm_regmap_init_spi(spi, &da9052_regmap_config);
> + da9052->regmap = devm_regmap_init_spi(spi, &config);
>   if (IS_ERR(da9052->regmap)) {
>   ret = PTR_ERR(da9052->regmap);
>   dev_err(&spi->dev, "Failed to allocate register map: %d\n",
> diff --git a/include/linux/mfd/da9052/da9052.h 
> b/include/linux/mfd/da9052/da9052.h
> index bba65f5..c18a4c1 100644
> --- a/include/linux/mfd/da9052/da9052.h
> +++ b/include/linux/mfd/da9052/da9052.h
> @@ -211,7 +211,7 @@ static inline int da9052_reg_update(struct da9052 
> *da9052, unsigned char reg,
>  int da9052_device_init(struct da9052 *da9052, u8 chip_id);
>  void da9052_device_exit(struct da9052 *da9052);
>  
> -extern struct regmap_config da9052_regmap_config;
> +extern const struct regmap_config da9052_regmap_config;
>  
>  int da9052_irq_init(struct da9052 *da9052);
>  int da9052_irq_exit(struct da9052 *da9052);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/1] PWM Backlight: Fix a bug which could cause the PWM backlight driver use the wrong PWM chip and fail the driver probing if multiple PWM chips exist. This defect could also cause the uni

[Lee Jones]

> I'm guessing this is your first patch.
> 
> Please read: Documentation/SubmittingPatches
> 
> A few notes for you search for and read about in the above document.
> 
>  - Subject line formatting (short, succinct) 
>  - Commit logs (present, descriptive [what changed and why], succinct)
>  - Authorship (full/real names only)

You also need to CC linux-kernel@vger.kernel.org on all patches.

> > Signed-off-by: ryang 
> > ---
> >  drivers/video/backlight/pwm_bl.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/video/backlight/pwm_bl.c 
> > b/drivers/video/backlight/pwm_bl.c
> > index b85983e..e0014a5 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -273,6 +273,9 @@ static int pwm_backlight_probe(struct platform_device 
> > *pdev)
> >  
> > pb->pwm = devm_pwm_get(&pdev->dev, NULL);
> > if (IS_ERR(pb->pwm)) {
> > +   ret = PTR_ERR(pb->pwm);
> > +   if (ret == -EPROBE_DEFER)
> > +   goto err_alloc;
> > dev_err(&pdev->dev, "unable to request PWM, trying legacy 
> > API\n");
> >  
> > pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/5] Clocksource: Flextimer: Use internal clocksource read API.

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

> >
> > Since the FTM will be in BE mode on LS1 platform, but will be in LE mode
> > On LS2 platform.
> >
> > And ftm_clocksource_read_up() will adapt to this different.
> 
> You are missing the point. Why do you want a conditional in a hot
> path? You know at init time whether the thing is BE or LE, so you can
> have separate functions for BE/LE or whatever and register that with
> clocksource_mmio_init(). i.e.
> 
>  if (be)
>   clocksource_mmio_init(., cs_read_be);
>  else if (le)
>   clocksource_mmio_init(., cs_read_le);
>  else if (magic)
>   clocksource_mmio_init(., cs_read_magic);
> 

There already has the following access interfaces:

static inline u32 ftm_readl(void __iomem *addr)
{
if (priv->big_endian)
return ioread32be(addr);
else
return ioread32(addr);
}

static inline void ftm_writel(u32 val, void __iomem *addr)
{
if (priv->big_endian)
iowrite32be(val, addr);
else
iowrite32(val, addr);
}

So I added the following code:

static cycle_t ftm_clocksource_read_up(struct clocksource *c)
{
return ftm_readl(priv->clksrc_base + FTM_CNT) & 0x;
}

clocksource_mmio_init(.,ftm_clocksource_read_up);

Is this okay ?

Thanks,

BRs
Xiubo


--
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 1/4] Documentation/scheduler/sched-deadline.txt: fix terminology and improve clarity

[Juri Lelli]

Hi Henrik,

On 02/09/14 22:10, Henrik Austad wrote:
> On Thu, Aug 28, 2014 at 11:00:26AM +0100, Juri Lelli wrote:
>> From: Luca Abeni 
>>
>> Several small changes regarding SCHED_DEADLINE documentation that fix
>> terminology and improve clarity and readability:
>>
>>  - "current runtime" becomes "remaining runtime"
>>
>>  - readablity of an equation is improved by introducing more spacing
>>
>>  - clarify when admission control will certainly fail
>>
>>  - new URL for CBS technical report
>>
>>  - substitue "smallest" with "closest"
> 
> I'm tempted to say "earliest" (being part of the algorithm's name and all 
> ;)
> 
>>
>> Signed-off-by: Luca Abeni 
>> Signed-off-by: Juri Lelli 
>> Cc: Randy Dunlap 
>> Cc: Peter Zijlstra 
>> Cc: Ingo Molnar 
>> Cc: Henrik Austad 
>> Cc: Dario Faggioli 
>> Cc: Juri Lelli 
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  Documentation/scheduler/sched-deadline.txt | 32 
>> --
>>  1 file changed, 17 insertions(+), 15 deletions(-)
>>
>> diff --git a/Documentation/scheduler/sched-deadline.txt 
>> b/Documentation/scheduler/sched-deadline.txt
>> index 18adc92..dce6d63 100644
>> --- a/Documentation/scheduler/sched-deadline.txt
>> +++ b/Documentation/scheduler/sched-deadline.txt
>> @@ -45,14 +45,14 @@ CONTENTS
>>   every time the task wakes up, the scheduler computes a "scheduling 
>> deadline"
>>   consistent with the guarantee (using the CBS[2,3] algorithm). Tasks are 
>> then
>>   scheduled using EDF[1] on these scheduling deadlines (the task with the
>> - smallest scheduling deadline is selected for execution). Notice that this
>> + closest scheduling deadline is selected for execution). Notice that this
>>   guaranteed is respected if a proper "admission control" strategy (see 
>> Section
>>   "4. Bandwidth management") is used.
>>  
>>   Summing up, the CBS[2,3] algorithms assigns scheduling deadlines to tasks 
>> so
>>   that each task runs for at most its runtime every period, avoiding any
>>   interference between different tasks (bandwidth isolation), while the 
>> EDF[1]
>> - algorithm selects the task with the smallest scheduling deadline as the one
>> + algorithm selects the task with the closest scheduling deadline as the one
>>   to be executed first.  Thanks to this feature, also tasks that do not
> 
> s/first/next/
> 
> Also, next sentence does not make much sense, I would drop the also;
> 
> "Thanks to this feature, tasks that do not strictly comply with the ..."
> 
>>   strictly comply with the "traditional" real-time task model (see Section 3)
>>   can effectively use the new policy.
>> @@ -64,45 +64,45 @@ CONTENTS
>>  "deadline", and "period" parameters;
>>  
>>- The state of the task is described by a "scheduling deadline", and
>> -a "current runtime". These two parameters are initially set to 0;
>> +a "remaining runtime". These two parameters are initially set to 0;
>>  
>>- When a SCHED_DEADLINE task wakes up (becomes ready for execution),
>>  the scheduler checks if
>>  
>> -current runtimeruntime
>> - -- > 
>> - scheduling deadline - current time period
>> + remaining runtime  runtime
>> +-->-
>> +scheduling deadline - current time   period
>>
>>  then, if the scheduling deadline is smaller than the current time, or
>>  this condition is verified, the scheduling deadline and the
>> -current budget are re-initialised as
>> +remaining runtime are re-initialised as
>>  
>>   scheduling deadline = current time + deadline
>> - current runtime = runtime
>> + remaining runtime = runtime
>>  
>> -otherwise, the scheduling deadline and the current runtime are
>> +otherwise, the scheduling deadline and the remaining runtime are
>>  left unchanged;
>>  
>>- When a SCHED_DEADLINE task executes for an amount of time t, its
>> -current runtime is decreased as
>> +remaining runtime is decreased as
>>  
>> - current runtime = current runtime - t
>> + remaining runtime = remaining runtime - t
>>  
>>  (technically, the runtime is decreased at every tick, or when the
>>  task is descheduled / preempted);
>>  
>> -  - When the current runtime becomes less or equal than 0, the task is
>> +  - When the remaining runtime becomes less or equal than 0, the task is
>>  said to be "throttled" (also known as "depleted" in real-time 
>> literature)
>>  and cannot be scheduled until its scheduling deadline. The 
>> "replenishment
>>  time" for this task (see next item) is set to be equal to the current
>>  value of the scheduling deadline;
>>  
>>- When the current time is equal to the replenishment time of a
>> -throttled task, the scheduling deadline and the current runtime are
>> 

RE: bit fields && data tearing

[David Laight]

From:  Benjamin Herrenschmidt
> On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> 
> > Apologies for hijacking this thread but I need to extend this discussion
> > somewhat regarding what a compiler might do with adjacent fields in a 
> > structure.
> >
> > The tty subsystem defines a large aggregate structure, struct tty_struct.
> > Importantly, several different locks apply to different fields within that
> > structure; ie., a specific spinlock will be claimed before updating or 
> > accessing
> > certain fields while a different spinlock will be claimed before updating or
> > accessing certain _adjacent_ fields.
> >
> > What is necessary and sufficient to prevent accidental false-sharing?
> > The patch below was flagged as insufficient on ia64, and possibly ARM.
> 
> We expect native aligned scalar types to be accessed atomically (the
> read/modify/write of a larger quantity that gcc does on some bitfield
> cases has been flagged as a gcc bug, but shouldn't happen on normal
> scalar types).

That isn't true on all architectures for items smaller than a machine word.
At least one has to do rmw for byte accesses.

David

> I am not 100% certain of "bool" here, I assume it's treated as a normal
> scalar and thus atomic but if unsure, you can always use int.
> 
> Another option is to use the atomic bitops and make these bits in a
> bitmask but that is probably unnecessary if you have locks already.
> 
> Cheers,
> Ben.

RE: [PATCH 2/5] Clocksource: Flextimer: Use internal clocksource read API.

[Thomas Gleixner]

On Thu, 4 Sep 2014, li.xi...@freescale.com wrote:
> > >
> > > Since the FTM will be in BE mode on LS1 platform, but will be in LE mode
> > > On LS2 platform.
> > >
> > > And ftm_clocksource_read_up() will adapt to this different.
> > 
> > You are missing the point. Why do you want a conditional in a hot
> > path? You know at init time whether the thing is BE or LE, so you can
> > have separate functions for BE/LE or whatever and register that with
> > clocksource_mmio_init(). i.e.
> > 
> >  if (be)
> > clocksource_mmio_init(., cs_read_be);
> >  else if (le)
> > clocksource_mmio_init(., cs_read_le);
> >  else if (magic)
> > clocksource_mmio_init(., cs_read_magic);
> > 
> 
> There already has the following access interfaces:
> 
> static inline u32 ftm_readl(void __iomem *addr)
> {
> if (priv->big_endian)
> return ioread32be(addr);
> else
> return ioread32(addr);
> }
> 
> static inline void ftm_writel(u32 val, void __iomem *addr)
> {
> if (priv->big_endian)
> iowrite32be(val, addr);
> else
> iowrite32(val, addr);
> }
> 
> So I added the following code:
> 
> static cycle_t ftm_clocksource_read_up(struct clocksource *c)
> {
> return ftm_readl(priv->clksrc_base + FTM_CNT) & 0x;
> }
> 
> clocksource_mmio_init(.,ftm_clocksource_read_up);
> 
> Is this okay ?

No. Sit down, read and try to understand what I wrote, look at your
existing code and figure out WHY it is fundamentally different to what
I told you.

Thanks,

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

RE: [PATCH 2/5] Clocksource: Flextimer: Use internal clocksource read API.

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

Hi Thomas,

> > > > Since the FTM will be in BE mode on LS1 platform, but will be in LE mode
> > > > On LS2 platform.
> > > >
> > > > And ftm_clocksource_read_up() will adapt to this different.
> > >
> > > You are missing the point. Why do you want a conditional in a hot
> > > path? You know at init time whether the thing is BE or LE, so you can
> > > have separate functions for BE/LE or whatever and register that with
> > > clocksource_mmio_init(). i.e.

For our LS1 and LS2+ platforms, there will be only one Kernel Image and can work
for both of them with different dtbs.

Thanks,

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

Re: [PATCH v9 5/6] clk: Add floor and ceiling constraints to clock rates

[Tomeu Vizoso]

On 09/04/2014 02:53 AM, Mike Turquette wrote:
> Quoting Stephen Boyd (2014-09-03 16:39:37)
>> On 09/03/14 08:33, Tomeu Vizoso wrote:
>>> +int clk_set_ceiling_rate(struct clk *clk_user, unsigned long rate)
>>> +{
>>> + struct clk_core *clk = clk_to_clk_core(clk_user);
>>> +
>>> + WARN(rate > 0 && rate < clk_user->floor_constraint,
>>> +  "clk %s dev %s con %s: new ceiling %lu lower than existing floor 
>>> %lu\n",
>>> +  __clk_get_name(clk), clk_user->dev_id, clk_user->con_id, rate,
>>> +  clk_user->floor_constraint);
>>> +
>>> + clk_user->ceiling_constraint = rate;
>>> + return clk_provider_set_rate(clk, clk_provider_get_rate(clk));
>>> +}
>>> +EXPORT_SYMBOL_GPL(clk_set_ceiling_rate);
>>
>> Maybe I'm late to this patch series given that Mike applied it, but I
>> wonder why we wouldn't just have one API that takes a min and a max,
>> i.e. clk_set_rate_range(clk, min, max)? Then clk_set_rate() is a small
>> wrapper on top that just sets min and max to the same value.
> 
> We certainly can have that. But being able to easily adjust a floor or
> ceiling value seems like a good thing to me, and that is what these
> functions do.
> 
> If we decide to have a clk_set_rate_range (where we perhaps pass zero in
> for a value that we do not wish to constrain) then I imagine that
> clk_set_ceiling_rate and clk_set_floor_rate will simply become a wrapper
> for that function. No harm having it both ways. If one way of doing
> things falls out of favor we can always cull it and update all the
> users.

I opted for separate functions because in the specific use cases I
thought of, any user will be interested in setting either a floor or a
ceiling constraint, but not both.

Regards,

Tomeu
--
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] x86, hotplug: fix llc shared map unreleased during cpu hotplug

[Wanpeng Li]

On Thu, Sep 04, 2014 at 07:20:34AM +0200, Ingo Molnar wrote:
>
>* Wanpeng Li  wrote:
>
>> BUG: unable to handle kernel NULL pointer dereference at 0004
>> IP: [..] find_busiest_group
>> PGD 5a9d5067 PUD 13067 PMD 0
>> Oops:  [#3] SMP
>> [...]
>> Call Trace:
>> load_balance
>> ? _raw_spin_unlock_irqrestore
>> idle_balance
>> __schedule
>> schedule
>> schedule_timeout
>> ? lock_timer_base
>> schedule_timeout_uninterruptible
>> msleep
>> lock_device_hotplug_sysfs
>> online_store
>> dev_attr_store
>> sysfs_write_file
>> vfs_write
>> SyS_write
>> system_call_fastpath
>> 
>> Last level cache shared map is built during cpu up and build sched domain 
>> routine takes advantage of it to setup sched domain cpu topology, however, 
>> llc shared map is unreleased during cpu disable which lead to invalid sched 
>> domain cpu topology. This patch fix it by release llc shared map correctly
>> during cpu disable.
>
>Very little is said in this changelog about how the bug was 
>found, how likely it is to occur for others, what systems are 
>affected, etc.

This bug can be triggered by hot add and remove large number of xen 
domain0's vcpus repeated.

Regards,
Wanpeng Li 

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

Re: [PATCH v3 2/4] Documentation/scheduler/sched-deadline.txt: Rewrite section 4 intro

[Juri Lelli]

Hi Henrik,

On 02/09/14 22:14, Henrik Austad wrote:
> On Thu, Aug 28, 2014 at 11:00:27AM +0100, Juri Lelli wrote:
>> Section 4 intro was still describing the old interface. Rewrite it.
>>
>> Signed-off-by: Juri Lelli 
>> Signed-off-by: Luca Abeni 
>> Cc: Randy Dunlap 
>> Cc: Peter Zijlstra 
>> Cc: Ingo Molnar 
>> Cc: Henrik Austad 
>> Cc: Dario Faggioli 
>> Cc: Juri Lelli 
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  Documentation/scheduler/sched-deadline.txt | 51 
>> +++---
>>  1 file changed, 25 insertions(+), 26 deletions(-)
>>
>> diff --git a/Documentation/scheduler/sched-deadline.txt 
>> b/Documentation/scheduler/sched-deadline.txt
>> index dce6d63..0aff2d5 100644
>> --- a/Documentation/scheduler/sched-deadline.txt
>> +++ b/Documentation/scheduler/sched-deadline.txt
>> @@ -165,39 +165,38 @@ CONTENTS
>>  
>>   In order for the -deadline scheduling to be effective and useful, it is
>>   important to have some method to keep the allocation of the available CPU
>> - bandwidth to the tasks under control.
>> - This is usually called "admission control" and if it is not performed at 
>> all,
>> - no guarantee can be given on the actual scheduling of the -deadline tasks.
>> -
>> - Since when RT-throttling has been introduced each task group has a 
>> bandwidth
>> - associated, calculated as a certain amount of runtime over a period.
>> - Moreover, to make it possible to manipulate such bandwidth, 
>> readable/writable
>> - controls have been added to both procfs (for system wide settings) and 
>> cgroupfs
>> - (for per-group settings).
>> - Therefore, the same interface is being used for controlling the bandwidth
>> - distrubution to -deadline tasks.
>> -
>> - However, more discussion is needed in order to figure out how we want to 
>> manage
>> - SCHED_DEADLINE bandwidth at the task group level. Therefore, SCHED_DEADLINE
>> - uses (for now) a less sophisticated, but actually very sensible, mechanism 
>> to
>> - ensure that a certain utilization cap is not overcome per each root_domain.
>> -
>> - Another main difference between deadline bandwidth management and 
>> RT-throttling
>> + bandwidth to the tasks under control. This is usually called "admission
>> + control" and if it is not performed at all, no guarantee can be given on
>> + the actual scheduling of the -deadline tasks.
>> +
>> + The interface used to control the fraction of CPU bandwidth that can be
>> + allocated to -deadline tasks is similar to the one already used for -rt
>> + tasks with real-time group scheduling (a.k.a. RT-throttling - see
>> + Documentation/scheduler/sched-rt-group.txt), and is based on readable/
>> + writable control files located in procfs (for system wide settings).
>> + Notice that per-group settings (controlled through cgroupfs) are still not
>> + defined for -deadline tasks, because more discussion is needed in order to
>> + figure out how we want to manage SCHED_DEADLINE bandwidth at the task group
>> + level.
>> +
>> + A main difference between deadline bandwidth management and RT-throttling
>>   is that -deadline tasks have bandwidth on their own (while -rt ones 
>> don't!),
>> - and thus we don't need an higher level throttling mechanism to enforce the
>> - desired bandwidth.
>> + and thus we don't need a higher level throttling mechanism to enforce the
>> + desired bandwidth. Therefore, using this simple interface we can put a cap
>> + on total utilization of -deadline tasks (i.e., \Sum (runtime_i / period_i) 
>> <
>> + some_desired_value).
> 
> s/some_desired_value/global_dl_utilization_cap/  perhaps?
> 

Ok, fixed.

>>  4.1 System wide settings
>>  
>>  
>>   The system wide settings are configured under the /proc virtual file 
>> system.
>>  
>> - For now the -rt knobs are used for dl admission control and the -deadline
>> - runtime is accounted against the -rt runtime. We realise that this isn't
>> - entirely desirable; however, it is better to have a small interface for 
>> now,
>> - and be able to change it easily later. The ideal situation (see 5.) is to 
>> run
>> - -rt tasks from a -deadline server; in which case the -rt bandwidth is a 
>> direct
>> - subset of dl_bw.
>> + For now the -rt knobs are used for -deadline admission control and the
>> + -deadline runtime is accounted against the -rt runtime. We realise that 
>> this
>> + isn't entirely desirable; however, it is better to have a small interface 
>> for
>> + now, and be able to change it easily later. The ideal situation (see 5.) 
>> is to
>> + run -rt tasks from a -deadline server; in which case the -rt bandwidth is a
>> + direct subset of dl_bw.
> 
> Isn't forking forbidden for _dl tasks? Or did I miss a memo somewhere?
> 

Yes, forking is forbidden. But, that's mainly because it is not entirely
clear how bandwidth has to be split between parent and child(ren). When
we'll have -rt tasks running from a -deadline server this problem will
disappear, as children will

Re: [PATCH v4 01/11] cpumask: factor out show_cpumap into separate helper function

[Sudeep Holla]

Hi Peter,

On 04/09/14 07:20, Peter Zijlstra wrote:

On Wed, Sep 03, 2014 at 06:00:07PM +0100, Sudeep Holla wrote:

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 2997af6d2ccd..26d8348292dd 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -11,6 +11,8 @@
  #include 
  #include 

+#include 
+
  typedef struct cpumask { DECLARE_BITMAP(bits, NR_CPUS); } cpumask_t;

  /**
@@ -792,6 +794,31 @@ static inline const struct cpumask *get_cpu_mask(unsigned 
int cpu)
  }
  #endif /* NR_CPUS > BITS_PER_LONG */

+/**
+ * cpumap_copy_to_buf  - copies the cpumask into the buffer either
+ * as comma-separated list of cpus or hex values of cpumask
+ * @list: indicates whether the cpumap must be list
+ * @mask: the cpumask to copy
+ * @buf: the buffer to copy into
+ *
+ * Returns the length of the (null-terminated) @buf string, zero if
+ * nothing is copied.
+ */
+static inline ssize_t
+cpumap_copy_to_buf(bool list, const struct cpumask *mask, char *buf)
+{
+   ptrdiff_t len = PTR_ALIGN(buf + PAGE_SIZE - 1, PAGE_SIZE) - buf - 2;
+   int n = 0;
+
+   if (len > 1) {
+   n = list ? cpulist_scnprintf(buf, len, mask) :
+  cpumask_scnprintf(buf, len, mask);
+   buf[n++] = '\n';
+   buf[n] = '\0';
+   }
+   return n;
+}
+


Does that really make sense as an inline?



If I don't, every file including this header generates "warning:
‘cpumap_copy_to_buf’ defined but not used". Alternatively I can just
declare here and define it elsewhere but I could not find more apt
place than this. Any suggestions ? kernel/cpu.c ?

Regards,
Sudeep

--
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] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

[Ulf Hansson]

Hi

On 3 September 2014 15:08, Jean-Michel Hautbois
 wrote:
> 2014-09-03 11:09 GMT+02:00 Ulf Hansson :
>> On 3 September 2014 11:02, Adrian Hunter  wrote:
>>> On 09/03/2014 11:30 AM, Ulf Hansson wrote:
 On 2 September 2014 17:49, Jean-Michel Hautbois
  wrote:
> This property is useful when we don't want to access boot partitions on 
> eMMC
>
> Signed-off-by: Jean-Michel Hautbois 
> ---
>  Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
>  drivers/mmc/host/sdhci-esdhc-imx.c| 8 
>  include/linux/platform_data/mmc-esdhc-imx.h   | 1 +
>  3 files changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
> b/Documentation/devicetree/bindings/mmc/mmc.txt
> index 431716e..59cc854 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> @@ -40,6 +40,7 @@ Optional properties:
>  - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
>  - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
>  - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
> +- no-boot-part : when preset, tells to access boot partitions
>
>  *NOTE* on CD and WP polarity. To use common for all SD/MMC host 
> controllers line
>  polarity properties, we have to fix the meaning of the "normal" and 
> "inverted"
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
> b/drivers/mmc/host/sdhci-esdhc-imx.c
> index ccec0e3..439e663 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -942,6 +942,11 @@ sdhci_esdhc_imx_probe_dt(struct platform_device 
> *pdev,
> if (of_property_read_u32(np, "fsl,delay-line", 
> &boarddata->delay_line))
> boarddata->delay_line = 0;
>
> +   if (of_find_property(np, "no-boot-part", NULL))
> +   boarddata->access_boot_part = false;
> +   else
> +   boarddata->access_boot_part = true;
> +
> return 0;
>  }
>  #else
> @@ -1119,6 +1124,9 @@ static int sdhci_esdhc_imx_probe(struct 
> platform_device *pdev)
> host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
> }
>
> +   if (!boarddata->access_boot_part)
> +   host->mmc->caps2 |= MMC_CAP2_BOOTPART_NOACC;
> +

 Hmm, I don't think MMC_CAP2_BOOTPART_NOACC should have a DT binding.
 Does it describe the hardware in some form?

 Actually I would like to question why MMC_CAP2_BOOTPART_NOACC exists
 at all. If there are cards that don't supports the BOOT area,
 shouldn't we have a card quirk for it instead of a host cap? Maybe
 Adrian Hunter, how originally wrote the patch for adding
 MMC_CAP2_BOOTPART_NOACC, could help me understand the reasons behind
 it!?
>>>
>>> It was added because platform firmware was able to prevent access to the
>>> boot partitions (for security I think), so attempts to access them would
>>> fail messily.  It was not related to any specific card.
>>
>> Adrian, appreciate your clarification. After all it seems like adding
>> a DT binding for it should be appropriate.
>>
>> Kind regards
>> Uffe
>
> Thanks Adrian :).
> Well, there is boot partitions and rpmb partition, and maybe should we
> have a binding to prevent access to both of them ?
> Something else came to my mind, when you want to boot on eMMC, do you
> need to write u-boot in boot partitions or is it written at the
> logical adress 0 which is what fdisk uses as start ?
> Because, if this is not usuable but just scanned I can't see why we
> bother doing it... ?

Hi Jean-Michel,

I am not sure adding a DT binding for non access to rpmb would be
needed. At least until we heard of a similar case as Adrian describes
but for rpmb.

BTW, I just posted a patch which disabled partition scan of the boot
area, what to you think about that?
http://marc.info/?l=linux-mmc&m=140973496402028&w=2

Finally I am also wondering whether we could and thus should, handle
these situations entirely without using a host cap. In principle what
we need is a more sophisticated error handling when the switch errors
occurs, while trying to switch to the boot area/rpmb partitions. Could
you maybe investigate that option, before we decide to add a new DT
binding?

Kind regards
Uffe
--
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] ipmi: Clear drvdata when interface is removed by hotmod

[Takao Indoh]

This patch fixes a bug on hotmod removing.

After ipmi interface is removed using hotmod, kernel panic occurs when
rmmod impi_si. For example, try this:

 # echo "remove,"`cat /proc/ipmi/0/params` > \
 /sys/module/ipmi_si/parameters/hotmod
 # rmmod ipmi_si

Then, rmmod fails with the following messages.

[ cut here ]
WARNING: CPU: 12 PID: 10819 at /mnt/repos/linux/lib/list_debug.c:53
__list_del_entry+0x63/0xd0()
(snip)
CPU: 12 PID: 10819 Comm: rmmod Not tainted 3.17.0-rc1 #19
Hardware name: FUJITSU-SV PRIMERGY BX920 S2/D3030, BIOS 080015
Rev.3D81.3030 02/10/2012
 0009 88022d547d40 81575778 88022d547d88
 88022d547d78 8104ec5d 88023908cdb0 a06fa4e0
 8800bac20860  02046090 88022d547dd8
Call Trace:
 [] dump_stack+0x45/0x56
 [] warn_slowpath_common+0x7d/0xa0
 [] warn_slowpath_fmt+0x4c/0x50
 [] ? __kernfs_remove+0xdf/0x220
 [] __list_del_entry+0x63/0xd0
 [] list_del+0xd/0x30
 [] cleanup_one_si+0x2a/0x230 [ipmi_si]
 [] ipmi_pnp_remove+0x15/0x20 [ipmi_si]
 [] pnp_device_remove+0x24/0x40
 [] __device_release_driver+0x7f/0xf0
 [] driver_detach+0xb0/0xc0
 [] bus_remove_driver+0x55/0xd0
 [] driver_unregister+0x2c/0x50
 [] pnp_unregister_driver+0x12/0x20
 [] cleanup_ipmi_si+0xbc/0xf0 [ipmi_si]
 [] SyS_delete_module+0x132/0x1c0
 [] ? do_notify_resume+0x59/0x80
 [] ? int_signal+0x12/0x17
 [] system_call_fastpath+0x16/0x1b
---[ end trace 70b4377268f85c23 ]---

list_del in cleanup_one_si() fails because the smi_info is already
removed when hotmod removing.

When ipmi interface is removed by hotmod, smi_info is removed by
cleanup_one_si(), but it is still set in drvdata. Therefore when rmmod
ipmi_si, ipmi_pnp_remove tries to remove it again and fails.

By this patch, a pointer to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.

Signed-off-by: Takao Indoh 
---
 drivers/char/ipmi/ipmi_si_intf.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 5d66568..20a3739 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1904,8 +1904,14 @@ static int hotmod_handler(const char *val, struct 
kernel_param *kp)
continue;
if (e->si_type != si_type)
continue;
-   if (e->io.addr_data == addr)
-   cleanup_one_si(e);
+   if (e->io.addr_data != addr)
+   continue;
+
+   /* Clear driver data */
+   if (e->dev)
+   dev_set_drvdata(e->dev, NULL);
+
+   cleanup_one_si(e);
}
mutex_unlock(&smi_infos_lock);
}
@@ -2316,7 +2322,8 @@ static void ipmi_pnp_remove(struct pnp_dev *dev)
 {
struct smi_info *info = pnp_get_drvdata(dev);
 
-   cleanup_one_si(info);
+   if (info)
+   cleanup_one_si(info);
 }
 
 static const struct pnp_device_id pnp_dev_table[] = {
@@ -2621,7 +2628,8 @@ static int ipmi_pci_probe(struct pci_dev *pdev,
 static void ipmi_pci_remove(struct pci_dev *pdev)
 {
struct smi_info *info = pci_get_drvdata(pdev);
-   cleanup_one_si(info);
+   if (info)
+   cleanup_one_si(info);
pci_disable_device(pdev);
 }
 
@@ -2729,7 +2737,10 @@ static int ipmi_probe(struct platform_device *dev)
 static int ipmi_remove(struct platform_device *dev)
 {
 #ifdef CONFIG_OF
-   cleanup_one_si(dev_get_drvdata(&dev->dev));
+   struct smi_info *info = dev_get_drvdata(&dev->dev);
+
+   if (info)
+   cleanup_one_si(info);
 #endif
return 0;
 }
@@ -2796,7 +2807,11 @@ static int ipmi_parisc_probe(struct parisc_device *dev)
 
 static int ipmi_parisc_remove(struct parisc_device *dev)
 {
-   cleanup_one_si(dev_get_drvdata(&dev->dev));
+   struct smi_info *info = dev_get_drvdata(&dev->dev);
+
+   if (info)
+   cleanup_one_si(info);
+
return 0;
 }
 
-- 
1.8.3.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: bit fields && data tearing

[Mikael Pettersson]

Benjamin Herrenschmidt writes:
 > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
 > 
 > > Apologies for hijacking this thread but I need to extend this discussion
 > > somewhat regarding what a compiler might do with adjacent fields in a 
 > > structure.
 > > 
 > > The tty subsystem defines a large aggregate structure, struct tty_struct.
 > > Importantly, several different locks apply to different fields within that
 > > structure; ie., a specific spinlock will be claimed before updating or 
 > > accessing
 > > certain fields while a different spinlock will be claimed before updating 
 > > or
 > > accessing certain _adjacent_ fields.
 > > 
 > > What is necessary and sufficient to prevent accidental false-sharing?
 > > The patch below was flagged as insufficient on ia64, and possibly ARM.
 > 
 > We expect native aligned scalar types to be accessed atomically (the
 > read/modify/write of a larger quantity that gcc does on some bitfield
 > cases has been flagged as a gcc bug, but shouldn't happen on normal
 > scalar types).
 > 
 > I am not 100% certain of "bool" here, I assume it's treated as a normal
 > scalar and thus atomic but if unsure, you can always use int.

Please use an aligned int or long.  Some machines cannot do atomic
accesses on sub-int/long quantities, so 'bool' may cause unexpected
rmw cycles on adjacent fields.

/Mikael

 > 
 > Another option is to use the atomic bitops and make these bits in a
 > bitmask but that is probably unnecessary if you have locks already.
 > 
 > Cheers,
 > Ben.
 > 
 > 
 > > Regards,
 > > Peter Hurley
 > > 
 > > --- >% ---
 > > Subject: [PATCH 21/26] tty: Convert tty_struct bitfield to bools
 > > 
 > > The stopped, hw_stopped, flow_stopped and packet bits are smp-unsafe
 > > and interrupt-unsafe. For example,
 > > 
 > > CPU 0 | CPU 1
 > >   |
 > > tty->flow_stopped = 1 | tty->hw_stopped = 0
 > > 
 > > One of these updates will be corrupted, as the bitwise operation
 > > on the bitfield is non-atomic.
 > > 
 > > Ensure each flag has a separate memory location, so concurrent
 > > updates do not corrupt orthogonal states.
 > > 
 > > Signed-off-by: Peter Hurley 
 > > ---
 > >  include/linux/tty.h | 5 -
 > >  1 file changed, 4 insertions(+), 1 deletion(-)
 > > 
 > > diff --git a/include/linux/tty.h b/include/linux/tty.h
 > > index 1c3316a..7cf61cb 100644
 > > --- a/include/linux/tty.h
 > > +++ b/include/linux/tty.h
 > > @@ -261,7 +261,10 @@ struct tty_struct {
 > >unsigned long flags;
 > >int count;
 > >struct winsize winsize; /* winsize_mutex */
 > > -  unsigned char stopped:1, hw_stopped:1, flow_stopped:1, packet:1;
 > > +  bool stopped;
 > > +  bool hw_stopped;
 > > +  bool flow_stopped;
 > > +  bool packet;
 > >unsigned char ctrl_status;  /* ctrl_lock */
 > >unsigned int receive_room;  /* Bytes free for queue */
 > >int flow_change;
 > 
 > 
 > --
 > 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 v4] x86, hotplug: fix llc shared map unreleased during cpu hotplug

[Wanpeng Li]

On Thu, Sep 04, 2014 at 02:40:07PM +0900, Yasuaki Ishimatsu wrote:
>(2014/09/04 14:20), Ingo Molnar wrote:
>>
>>* Wanpeng Li  wrote:
>>
>>>BUG: unable to handle kernel NULL pointer dereference at 0004
>>>IP: [..] find_busiest_group
>>>PGD 5a9d5067 PUD 13067 PMD 0
>>>Oops:  [#3] SMP
>>>[...]
>>>Call Trace:
>>>load_balance
>>>? _raw_spin_unlock_irqrestore
>>>idle_balance
>>>__schedule
>>>schedule
>>>schedule_timeout
>>>? lock_timer_base
>>>schedule_timeout_uninterruptible
>>>msleep
>>>lock_device_hotplug_sysfs
>>>online_store
>>>dev_attr_store
>>>sysfs_write_file
>>>vfs_write
>>>SyS_write
>>>system_call_fastpath
>>>
>>>Last level cache shared map is built during cpu up and build sched domain
>>>routine takes advantage of it to setup sched domain cpu topology, however,
>>>llc shared map is unreleased during cpu disable which lead to invalid sched
>>>domain cpu topology. This patch fix it by release llc shared map correctly
>>>during cpu disable.
>>
>>Very little is said in this changelog about how the bug was
>>found, how likely it is to occur for others, what systems are
>>affected, etc.
>
>Hi Wanpeng,

Hi Yasuaki,

>
>In my understanding, the panic occurs by just onlining CPU as follows:
>echo 1 > /sys/devices/system/cpu/cpuX/online
>

See my reply to Ingo.

Regards,
Wanpeng Li 

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

[PATCH net-next v3 2/2] r8152: use eth_hw_addr_random

[Hayes Wang]

If the hw doesn't have a valid MAC address, give a random one and
set it to the hw.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b5ff933..f95e678 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -992,32 +992,35 @@ static int rtl8152_set_mac_address(struct net_device 
*netdev, void *p)
return 0;
 }
 
-static inline void set_ethernet_addr(struct r8152 *tp)
+static int set_ethernet_addr(struct r8152 *tp)
 {
struct net_device *dev = tp->netdev;
+   struct sockaddr sa;
int ret;
-   u8 node_id[8] = {0};
 
if (tp->version == RTL_VER_01)
-   ret = pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id);
+   ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
else
-   ret = pla_ocp_read(tp, PLA_BACKUP, sizeof(node_id), node_id);
+   ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
 
if (ret < 0) {
-   netif_notice(tp, probe, dev, "inet addr fail\n");
+   netif_err(tp, probe, dev, "Get ether addr fail\n");
+   } else if (!is_valid_ether_addr(sa.sa_data)) {
+   netif_err(tp, probe, dev, "Invalid ether addr %pM\n",
+ sa.sa_data);
+   eth_hw_addr_random(dev);
+   ether_addr_copy(sa.sa_data, dev->dev_addr);
+   ret = rtl8152_set_mac_address(dev, &sa);
+   netif_info(tp, probe, dev, "Random ether addr %pM\n",
+  sa.sa_data);
} else {
-   if (tp->version != RTL_VER_01) {
-   ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR,
-  CRWECR_CONFIG);
-   pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES,
- sizeof(node_id), node_id);
-   ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR,
-  CRWECR_NORAML);
-   }
-
-   memcpy(dev->dev_addr, node_id, dev->addr_len);
-   memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
+   if (tp->version == RTL_VER_01)
+   ether_addr_copy(dev->dev_addr, sa.sa_data);
+   else
+   ret = rtl8152_set_mac_address(dev, &sa);
}
+
+   return ret;
 }
 
 static void read_bulk_callback(struct urb *urb)
-- 
1.9.3

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

Re: [PATCH resend 2/2] usb: serial: xsens_mt: always bind to interface number 1

[Frans Klaver]

On Thu, Sep 04, 2014 at 10:15:22AM +0200, Johan Hovold wrote:
> On Thu, Sep 04, 2014 at 09:12:05AM +0200, Frans Klaver wrote:
> 
> > >  static int xsens_mt_probe(struct usb_serial *serial,
> > > const struct usb_device_id *id)
> > >  {
> > > -   if (!has_required_endpoints(serial->interface->cur_altsetting))
> > > -   return -ENODEV;
> > > -   return 0;
> > > +   if (serial->interface->cur_altsetting.desc.bInterfaceNumber == 1)
> > 
> > This should be
> > 
> > if (serial->interface->cur_altsetting->desc.bInterfaceNumber == 1)
> 
> So this wasn't even compile tested. Always test your patches before
> submission, including trivial ones.
> 
> Is the new version tested on actual hardware?

The implementation was tested (also fixed) before the first submission.
Not the patches. Looks like I've got a step to add.

The new version is applied, built and tested with some actual hardware
on 3.17-rc3.

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

Re: [PATCH v10 03/19] arm: fiq: Replace default FIQ handler

[Daniel Thompson]

On 03/09/14 20:34, Russell King - ARM Linux wrote:
> On Wed, Sep 03, 2014 at 11:21:30AM +0100, Daniel Thompson wrote:
>> On 02/09/14 17:42, Russell King - ARM Linux wrote:
>>> Yes, it does, because unlike the x86 community, we have a wide range
>>> of platforms, and platform code does not go through the same path or
>>> get the same review as core ARM code.
>>>
>>> As I already pointed out, with a notifier, it's very easy to sneak
>>> something into the FIQ path by submitting a patch for platform code
>>> which calls the registration function.  That's going to be pretty
>>> difficult to spot amongst the 3000+ messages on the linux-arm-kernel
>>> list each month in order to give it the review that it would need.
>>> That's especially true as I now ignore almost all most platform
>>> code patches as we have Arnd and Olof to look at that.
>>>
>>> So, unless you can come up with a proposal which ensures that there
>>> is sufficient review triggered when someone decides to call the
>>> notifier registration function...
>>
>> Reflecting upon this and upon Thomas' comments about only using FIQ for
>> watchdog, backtrace and performance monitoring...
>>
>> The short version is, "I was wrong and should have done what you said in
>> the first place".
>>
>> The long version adds, "because the coupling concerns were spurious; the
>> only proposed users of the default FIQ handler outside of core ARM code,
>> are ARM-centric irqchip drivers."
> 
> I would say that the ARM specific changes to entry-armv.S and setup.c
> are correct.  All that you're doing there is to replace the existing
> default no-op FIQ handler with some additional code which gets us into
> SVC mode and back out, but itself is also a no-op.  In other words, no
> real change.
> 
> That's a good first patch, and one which I would actually like to have
> in my tree sooner rather than later, so that I can split that out from
> my prototype code.

So would I!

I did some rebasing yesterday to put anything to do with kgdb right at
the back of the queue. This "good first patch" is now actually the first
patch; where the nofifier used to be it currently calls do_unexp_fiq()
making it very close to "no real change".

BTW do_unexp_fiq() calls printk() but

> I can also split out from it the ARM generic changes for implementing
> the FIQ dumping too, which gives us a second patch.  With a bit of
> additional work, much of that should actually be generic code, not
> ARM or x86 specific code.  That's going to annoy x86 people a little
> because some of that is being reworked...

So far I have been testing the action after patch review using the big
kgdb patches on top of it.

Today I plan to remove the kgdb stuff, drop in your version of
arch_trigger_all_cpu_backtrace() and test the results. I was going to
use the code you shared on 13 August meaning all the cpu mask bit
manipulation is in the arm-only code.

If you want me to work with something more recent then feel free to
point me at it...


> That will leave the problem of how to deal with the IRQ controller
> specifics, and how to properly wire it together with the IRQ controller
> in the loop - that is where Thomas' concerns are focused.

I'm working on those and its looking pretty good so far. This is mostly
because SGIs don't need to allocate virqs so the controversial bits of
my last patchset disappear completely.

--
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: mm: BUG in unmap_page_range

[Sasha Levin]

On 08/29/2014 09:23 PM, Sasha Levin wrote:
> On 08/27/2014 11:26 AM, Mel Gorman wrote:
>> > diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
>> > index 281870f..ffea570 100644
>> > --- a/include/asm-generic/pgtable.h
>> > +++ b/include/asm-generic/pgtable.h
>> > @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte)
>> >  
>> >VM_BUG_ON(!(val & _PAGE_PRESENT));
>> >  
>> > +  /* debugging only, specific to x86 */
>> > +  VM_BUG_ON(val & _PAGE_PROTNONE);
>> > +
>> >val &= ~_PAGE_PRESENT;
>> >val |= _PAGE_NUMA;
> Triggered again, the first VM_BUG_ON got hit, the second one never did.

Okay, this bug has reproduced quite a few times since then that I no longer
suspect it's random memory corruption. I'd be happy to try out more debug
patches if you have any leads.


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

[PATCH net-next v3 0/2] r8152: random MAC address

[Hayes Wang]

If the interface has invalid MAC address, it couldn't
be used. In order to let it work normally, give a
random one.

v3:
  Remove
ether_addr_copy(dev->perm_addr, dev->dev_addr);

v2:
  Use "%pM" format specifier for printing a MAC address.

Hayes Wang (2):
  r8152: change the location of rtl8152_set_mac_address
  r8152: use eth_hw_addr_random

 drivers/net/usb/r8152.c | 65 -
 1 file changed, 37 insertions(+), 28 deletions(-)

-- 
1.9.3

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

Re: [PATCH] mm: ksm: Remove unused function process_timeout()

[Chintan Pandya]

On 08/11/2014 04:52 PM, Murilo Opsfelder Araujo wrote:

This patch fixes compilation warning:

mm/ksm.c:1711:13: warning: ‘process_timeout’ defined but not used 
[-Wunused-function]

Signed-off-by: Murilo Opsfelder Araujo
---
  mm/ksm.c | 5 -
  1 file changed, 5 deletions(-)

diff --git a/mm/ksm.c b/mm/ksm.c
index f7de4c0..434a50a 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1708,11 +1708,6 @@ static void ksm_do_scan(unsigned int scan_npages)
}
  }

-static void process_timeout(unsigned long __data)
-{
-   wake_up_process((struct task_struct *)__data);
-}
-
  static int ksmd_should_run(void)
  {
return (ksm_run&  KSM_RUN_MERGE)&&  !list_empty(&ksm_mm_head.mm_list);



The original KSM patch which introduced this function (by mistake) has 
been re-sent for reviews. So, we can drop this at the moment.


--
Chintan Pandya

QUALCOMM INDIA, on behalf of 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 1/3] mfd: max77693: Initialize haptic register map

[Lee Jones]

On Mon, 01 Sep 2014, Jaewon Kim wrote:

> This patch add regmap_haptic initialization to use haptic register map
> in haptic device driver.
> 
> Signed-off-by: Jaewon Kim 
> Acked-by: Chanwoo Choi 
> ---
>  drivers/mfd/max77693.c |   21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)

Acked-by: Lee Jones 

Can this patch go in without the Input one?

> diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
> index 249c139..fbfed56 100644
> --- a/drivers/mfd/max77693.c
> +++ b/drivers/mfd/max77693.c
> @@ -144,6 +144,12 @@ static const struct regmap_irq_chip 
> max77693_muic_irq_chip = {
>   .num_irqs   = ARRAY_SIZE(max77693_muic_irqs),
>  };
>  
> +static const struct regmap_config max77693_regmap_haptic_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = MAX77693_HAPTIC_REG_END,
> +};
> +
>  static int max77693_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
>  {
> @@ -193,6 +199,15 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
>   }
>   i2c_set_clientdata(max77693->haptic, max77693);
>  
> + max77693->regmap_haptic = devm_regmap_init_i2c(max77693->haptic,
> + &max77693_regmap_haptic_config);
> + if (IS_ERR(max77693->regmap_haptic)) {
> + ret = PTR_ERR(max77693->regmap_haptic);
> + dev_err(max77693->dev,
> + "failed to initialize haptic register map: %d\n", ret);
> + goto err_regmap;
> + }
> +
>   /*
>* Initialize register map for MUIC device because use regmap-muic
>* instance of MUIC device when irq of max77693 is initialized
> @@ -204,7 +219,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
>   ret = PTR_ERR(max77693->regmap_muic);
>   dev_err(max77693->dev,
>   "failed to allocate register map: %d\n", ret);
> - goto err_regmap_muic;
> + goto err_regmap;
>   }
>  
>   ret = regmap_add_irq_chip(max77693->regmap, max77693->irq,
> @@ -214,7 +229,7 @@ static int max77693_i2c_probe(struct i2c_client *i2c,
>   &max77693->irq_data_led);
>   if (ret) {
>   dev_err(max77693->dev, "failed to add irq chip: %d\n", ret);
> - goto err_regmap_muic;
> + goto err_regmap;
>   }
>  
>   ret = regmap_add_irq_chip(max77693->regmap, max77693->irq,
> @@ -265,7 +280,7 @@ err_irq_charger:
>   regmap_del_irq_chip(max77693->irq, max77693->irq_data_topsys);
>  err_irq_topsys:
>   regmap_del_irq_chip(max77693->irq, max77693->irq_data_led);
> -err_regmap_muic:
> +err_regmap:
>   i2c_unregister_device(max77693->haptic);
>  err_i2c_haptic:
>   i2c_unregister_device(max77693->muic);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Add exit_prepare callback to the cpufreq_driver interface.

[Preeti U Murthy]

Hi,

I went through the cpufreq code and the previous discussion in the
context of this patch and I propose the below patch. Please let me know
if it misses something that you all had discussed.

On 09/04/2014 11:38 AM, Viresh Kumar wrote:
> On 19 March 2014 19:49, Rafael J. Wysocki  wrote:
> 
>> That said, for the intel_pstate case ->stop() as proposed by Dirk is 
>> demonstrably
>> sufficient and there are no other ->setpolicy drivers in sight wanting or 
>> needing
>> anything else.
>>
>> So to me, (1) the new ->stop() should *only* be called for ->setpolicy 
>> drivers,
>> because the purpose of it should be to "allow ->setpolicy drivers to do what 
>> the
>> GOV_STOP will do for regular drivers" as you put it above, and (2) some code 
>> in
>> the original intel_pstate's ->exit() may/should stay in there (instead of 
>> being
>> moved to the new ->stop()), which is the only possibly remaining issue here.
>>
>> The whole discussion about possibly re-using ->stop() for ->target drivers 
>> goes
>> in a totally wrong direction, because *if* ->target drivers need a new 
>> callback
>> to be executed around where ->stop() is called for ->setpolicy drivers, 
>> *then*
>> that has to be a *different* callback.
>>
>> And by the way, ->get() in fact has a different meaning for ->setpolicy 
>> drivers,
>> so it would be good to consider logical separation of ->setpolicy and 
>> ->target
>> drivers so that each kind has its own separate set of callbacks with no 
>> overlaps.
>> That would make it easier to avoid breakage resulting from changes made with
>> ->setpolicy drivers that also affect ->target drivers in unpredictable ways 
>> and
>> the other way around.
> 
> Okay, I have picked up a very old thread but it looks more sensible to start
> replying here..
> 
> Preeti (Cc'd) wants to do something similar, i.e. reduce freq of a
> core before it
> goes down. And the driver is probably: drivers/cpufreq/powernv-cpufreq.c, 
> which
> is ->target() type.
> 
> Now should we reuse the same callback ->stop_cpu() or implement a new one?
> I don't know if adding a new callback would be a good idea here..
> 
> --
> viresh
> 

cpufreq: Allow stop CPU callback to be used by all cpufreq drivers

Commit 367dc4aa introduced the stop CPU callback for intel_pstate
drivers. During the CPU_DOWN_PREPARE stage, this callback is invoked
so that drivers can take some action on the pstate of the cpu
before it is taken offline. This callback was assumed to be useful
only for those drivers which have implemented the set_policy CPU
callback because they have no other way to take action about the
cpufreq of a CPU which is being hotplugged out except in the exit
callback which is called very late in the offline process.

The drivers which implement the target/target_index callbacks were
expected to take care of requirements like the ones that commit
367dc4aa addresses in the GOV_STOP notification event. But there
are disadvantages to restricting the usage of stop CPU callback
to cpufreq drivers that implement the set_policy callbacks and who
want to take explicit action on the setting the cpufreq during a
hotplug operation.
   
1.GOV_STOP gets called for every CPU offline and drivers would usually
  want to take action when the last cpu in the policy->cpus mask
  is taken offline. As long as there is more than one cpu in the
  policy->cpus mask, cpufreq core itself makes sure that the freq
  for the other cpus in this mask is set according to the maximum load.
  This is sensible and drivers which implement the target_index callback
  would mostly not want to modify that. However the cpufreq core leaves a
  loose end when the cpu in the policy->cpus mask is the last one to go offline;
  it does nothing explicit to the frequency of the core. Drivers may need
  a way to take some action here and stop CPU callback mechanism is the
  best way to do it today.

2.We cannot implement driver specific actions in the GOV_STOP mechanism.
  So we will need another driver callback which is invoked from here which is
  unnecessary.

  Therefore this patch extends the usage of stop CPU callback to be used
  by all cpufreq drivers as long as they have this callback implemented
  and irrespective of whether they are set_policy/target_index drivers.
  The assumption is if the drivers find the GOV_STOP path to be a suitable
  way of implementing what they want to do with the freq of the cpu
  going offine,they will not implement the stop CPU callback at all.

  Signed-off-by: Preeti U Murthy 

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index d9fdedd..6463f35 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1380,7 +1380,7 @@ static int __cpufreq_remove_dev_prepare(struct device 
*dev,
if (!cpufreq_suspended)
pr_debug("%s: policy Kobject moved to cpu: %d from: 
%d\n",
 __func__, new_cpu, cpu);
-   } else if (cpufreq

Re: bit fields && data tearing

[Jakub Jelinek]

On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
> Benjamin Herrenschmidt writes:
>  > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
>  > 
>  > > Apologies for hijacking this thread but I need to extend this discussion
>  > > somewhat regarding what a compiler might do with adjacent fields in a 
> structure.
>  > > 
>  > > The tty subsystem defines a large aggregate structure, struct tty_struct.
>  > > Importantly, several different locks apply to different fields within 
> that
>  > > structure; ie., a specific spinlock will be claimed before updating or 
> accessing
>  > > certain fields while a different spinlock will be claimed before 
> updating or
>  > > accessing certain _adjacent_ fields.
>  > > 
>  > > What is necessary and sufficient to prevent accidental false-sharing?
>  > > The patch below was flagged as insufficient on ia64, and possibly ARM.
>  > 
>  > We expect native aligned scalar types to be accessed atomically (the
>  > read/modify/write of a larger quantity that gcc does on some bitfield
>  > cases has been flagged as a gcc bug, but shouldn't happen on normal
>  > scalar types).
>  > 
>  > I am not 100% certain of "bool" here, I assume it's treated as a normal
>  > scalar and thus atomic but if unsure, you can always use int.
> 
> Please use an aligned int or long.  Some machines cannot do atomic
> accesses on sub-int/long quantities, so 'bool' may cause unexpected
> rmw cycles on adjacent fields.

Yeah, at least pre-EV56 Alpha performs rmw cycles on char/short accesses
and thus those are not atomic.

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

Re: [PATCH 3/3] mfd: max77693: add haptic of_compatible in mfd_cell

[Lee Jones]

On Mon, 01 Sep 2014, Jaewon Kim wrote:

> This patch add haptic of_compatible in order to use the Haptic device driver
> using devicetree. and added the related documentation and example.
> 
> Signed-off-by: Jaewon Kim 
> Acked-by: Chanwoo Choi 
> ---
>  Documentation/devicetree/bindings/mfd/max77693.txt |   19 +++
>  drivers/mfd/max77693.c |2 +-

These should be in different patches - please split them.

>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt 
> b/Documentation/devicetree/bindings/mfd/max77693.txt
> index 11921cc..6e30ad8 100644
> --- a/Documentation/devicetree/bindings/mfd/max77693.txt
> +++ b/Documentation/devicetree/bindings/mfd/max77693.txt
> @@ -27,6 +27,18 @@ Optional properties:
>  
>   [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
>  
> +- haptic :
> + Required properties:
> + - compatible : Must be "maxim,max77693-hpatic"
> + - pwms : phandle to the physical PWM device,
> + A feel can be changed by changing a peroid cycle.

What is "a feel"?

Why is this this comment relevant to documenting the 'pwms' property?

> + Optional properties:
> +  - haptic-supply : power supply for haptic motor
> +  - pwm-names : Name to be used by the PWM subsystem for the PWM device

Are you sure this is optional?  If it is and given that there is only
one pwm, perhaps you need to remove it altogether?  *-names properties
are usually only required if there are more than one.

> + The haptic require of max77693 have to be instantiated under subnod
> +  named "haptic" using the following haptic format in example.
> +
>  Example:
>   max77693@66 {
>   compatible = "maxim,max77693";
> @@ -52,4 +64,11 @@ Example:
>   regulator-boot-on;
>   };
>   };
> +
> + haptic {
> + compatible = "maxim,max77693-haptic";
> + haptic-supply = <&haptic_supply>;
> + pwms = <&pwm 0 38022 0>;
> + pwm-names = "haptic";
> + };
>   };
> diff --git a/drivers/mfd/max77693.c b/drivers/mfd/max77693.c
> index fbfed56..ceb7ebf 100644
> --- a/drivers/mfd/max77693.c
> +++ b/drivers/mfd/max77693.c
> @@ -46,7 +46,7 @@ static const struct mfd_cell max77693_devs[] = {
>   { .name = "max77693-charger", },
>   { .name = "max77693-flash", },
>   { .name = "max77693-muic", },
> - { .name = "max77693-haptic", },
> + { .name = "max77693-haptic", .of_compatible = "maxim,max77693-haptic" },

Can you break this last entry out, so:

{
  .name = "max77693-haptic",
  .of_compatible = "maxim,max77693-haptic"
},

>  };
>  
>  static const struct regmap_config max77693_regmap_config = {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set

[Dave Chinner]

On Wed, Sep 03, 2014 at 04:10:00PM -0700, Andrew Morton wrote:
> On Wed,  3 Sep 2014 13:54:54 +0800 Junxiao Bi  wrote:
> 
> > commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O 
> > during memory allocation")
> > introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory 
> > allocation, __GFP_IO is cleared
> > when this flag is set, but __GFP_FS implies __GFP_IO, it should also be 
> > cleared. Or it may still
> > run into I/O, like in superblock shrinker.
> 
> Is there an actual bug which inspired this fix?  If so, please describe
> it.
> 
> I don't think it's accurate to say that __GFP_FS implies __GFP_IO. 
> Where did that info come from?

Pretty damn clear to me:

#define GFP_ATOMIC  (__GFP_HIGH)
#define GFP_NOIO(__GFP_WAIT)
#define GFP_NOFS(__GFP_WAIT | __GFP_IO)
#define GFP_KERNEL  (__GFP_WAIT | __GFP_IO | __GFP_FS)

especially when you consider the layering of the subsystems that use
these contexts. i.e. KERNEL on top of FS on top of IO on top of
ATOMIC

IOWs, asking for (__GFP_WAIT | __GFP_FS) reclaim context is
something outside the defined reclaim heirarchy. Filesystems
*depend* on being about to do IO to perform recalim of dirty
objects, whether it be the page cache, inode cache or any other
filesystem cache that can hold dirty objects.

> And the superblock shrinker is a good example of why this shouldn't be
> the case.  The main thing that code does is to reclaim clean fs objects
> without performing IO.

Filesystem shrinkers do indeed perform IO from the superblock
shrinker and have for years. Even clean inodes can require IO before
they can be freed - e.g. on an orphan list, need truncation of
post-eof blocks, need to wait for ordered operations to complete
before it can be freed, etc.

IOWs, Ext4, btrfs and XFS all can issue and/or block on
arbitrary amounts of IO in the superblock shrinker context. XFS, in
particular, has been doing transactions and IO from the VFS inode
cache shrinker since it was first introduced

> AFAICT the proposed patch will significantly
> weaken PF_MEMALLOC_NOIO allocation attempts by needlessly preventing
> the kernel from reclaiming such objects?

PF_MEMALLOC_NOIO is the anomolous case. It also has very few users,
who all happen to be working around very rare deadlocks caused by
vmalloc() hard coding GFP_KERNEL allocations deep in it's stack. So
the impact of fixing this anomoly is going to be completely
unnoticable...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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 0/2] Add exit_prepare callback to the cpufreq_driver interface.

[Viresh Kumar]

On 4 September 2014 14:40, Preeti U Murthy  wrote:
> cpufreq: Allow stop CPU callback to be used by all cpufreq drivers
>
> Commit 367dc4aa introduced the stop CPU callback for intel_pstate
> drivers. During the CPU_DOWN_PREPARE stage, this callback is invoked
> so that drivers can take some action on the pstate of the cpu
> before it is taken offline. This callback was assumed to be useful
> only for those drivers which have implemented the set_policy CPU
> callback because they have no other way to take action about the
> cpufreq of a CPU which is being hotplugged out except in the exit
> callback which is called very late in the offline process.
>
> The drivers which implement the target/target_index callbacks were
> expected to take care of requirements like the ones that commit
> 367dc4aa addresses in the GOV_STOP notification event. But there
> are disadvantages to restricting the usage of stop CPU callback
> to cpufreq drivers that implement the set_policy callbacks and who
> want to take explicit action on the setting the cpufreq during a
> hotplug operation.
>
> 1.GOV_STOP gets called for every CPU offline and drivers would usually
>   want to take action when the last cpu in the policy->cpus mask
>   is taken offline. As long as there is more than one cpu in the
>   policy->cpus mask, cpufreq core itself makes sure that the freq
>   for the other cpus in this mask is set according to the maximum load.
>   This is sensible and drivers which implement the target_index callback
>   would mostly not want to modify that. However the cpufreq core leaves a
>   loose end when the cpu in the policy->cpus mask is the last one to go 
> offline;
>   it does nothing explicit to the frequency of the core. Drivers may need
>   a way to take some action here and stop CPU callback mechanism is the
>   best way to do it today.
>
> 2.We cannot implement driver specific actions in the GOV_STOP mechanism.
>   So we will need another driver callback which is invoked from here which is
>   unnecessary.
>
>   Therefore this patch extends the usage of stop CPU callback to be used
>   by all cpufreq drivers as long as they have this callback implemented
>   and irrespective of whether they are set_policy/target_index drivers.
>   The assumption is if the drivers find the GOV_STOP path to be a suitable
>   way of implementing what they want to do with the freq of the cpu
>   going offine,they will not implement the stop CPU callback at all.
>
>   Signed-off-by: Preeti U Murthy 
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index d9fdedd..6463f35 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1380,7 +1380,7 @@ static int __cpufreq_remove_dev_prepare(struct device 
> *dev,
> if (!cpufreq_suspended)
> pr_debug("%s: policy Kobject moved to cpu: %d from: 
> %d\n",
>  __func__, new_cpu, cpu);
> -   } else if (cpufreq_driver->stop_cpu && cpufreq_driver->setpolicy) {
> +   } else if (cpufreq_driver->stop_cpu) {
> cpufreq_driver->stop_cpu(policy);
> }

Rafael explicitly said earlier that he want to see a separate callback for
->target() drivers, don't know why..

It looks fine to me though.
--
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 2/4] drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver

[Lee Jones]

Wim,

We're still waiting on your Ack?

> Added driver to support the 14F021P00 BMC Watchdog.
> The BMC is a Board Management Controller including watchdog functionality.
> 
> Signed-off-by: Andreas Werner 
> ---
>  drivers/watchdog/Kconfig |  10 ++
>  drivers/watchdog/Makefile|   1 +
>  drivers/watchdog/menf21bmc_wdt.c | 203 
> +++
>  3 files changed, 214 insertions(+)
>  create mode 100644 drivers/watchdog/menf21bmc_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 76dd541..96d72c2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -95,6 +95,16 @@ config GPIO_WATCHDOG
> If you say yes here you get support for watchdog device
> controlled through GPIO-line.
>  
> +config MENF21BMC_WATCHDOG
> + tristate "MEN 14F021P00 BMC Watchdog"
> + depends on MFD_MENF21BMC
> + select WATCHDOG_CORE
> + help
> +   Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
> +
> +   This driver can also be built as a module. If so the module
> +   will be called menf21bmc_wdt.
> +
>  config WM831X_WATCHDOG
>   tristate "WM831x watchdog"
>   depends on MFD_WM831X
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 468c320..de17014 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
>  obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
>  obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
>  obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
> +obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wdt.o
> diff --git a/drivers/watchdog/menf21bmc_wdt.c 
> b/drivers/watchdog/menf21bmc_wdt.c
> new file mode 100644
> index 000..2042874
> --- /dev/null
> +++ b/drivers/watchdog/menf21bmc_wdt.c
> @@ -0,0 +1,203 @@
> +/*
> + *  MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
> + *
> + *  Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> + *
> + *  This program is free software; you can redistribute  it and/or modify it
> + *  under  the terms of  the GNU General  Public License as published by the
> + *  Free Software Foundation;  either version 2 of the  License, or (at your
> + *  option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DEVNAME "menf21bmc_wdt"
> +
> +#define BMC_CMD_WD_ON0x11
> +#define BMC_CMD_WD_OFF   0x12
> +#define BMC_CMD_WD_TRIG  0x13
> +#define BMC_CMD_WD_TIME  0x14
> +#define BMC_CMD_WD_STATE 0x17
> +#define BMC_WD_OFF_VAL   0x69
> +#define BMC_CMD_RST_RSN  0x92
> +
> +#define BMC_WD_TIMEOUT_MIN   1   /* in sec */
> +#define BMC_WD_TIMEOUT_MAX   6553/* in sec */
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started 
> (default="
> + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +struct menf21bmc_wdt {
> + struct watchdog_device wdt;
> + struct i2c_client *i2c_client;
> +};
> +
> +static int menf21bmc_wdt_set_bootstatus(struct menf21bmc_wdt *data)
> +{
> + int rst_rsn;
> +
> + rst_rsn = i2c_smbus_read_byte_data(data->i2c_client, BMC_CMD_RST_RSN);
> + if (rst_rsn < 0)
> + return rst_rsn;
> +
> + if (rst_rsn == 0x02)
> + data->wdt.bootstatus |= WDIOF_CARDRESET;
> + else if (rst_rsn == 0x05)
> + data->wdt.bootstatus |= WDIOF_EXTERN1;
> + else if (rst_rsn == 0x06)
> + data->wdt.bootstatus |= WDIOF_EXTERN2;
> + else if (rst_rsn == 0x0A)
> + data->wdt.bootstatus |= WDIOF_POWERUNDER;
> +
> + return 0;
> +}
> +
> +static int menf21bmc_wdt_start(struct watchdog_device *wdt)
> +{
> + struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
> +
> + return i2c_smbus_write_byte(drv_data->i2c_client, BMC_CMD_WD_ON);
> +}
> +
> +static int menf21bmc_wdt_stop(struct watchdog_device *wdt)
> +{
> + struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
> +
> + return i2c_smbus_write_byte_data(drv_data->i2c_client,
> +  BMC_CMD_WD_OFF, BMC_WD_OFF_VAL);
> +}
> +
> +static int
> +menf21bmc_wdt_settimeout(struct watchdog_device *wdt, unsigned int timeout)
> +{
> + int ret;
> + struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
> +
> + /*
> +  *  BMC Watchdog does have a resolution of 100ms.
> +  *  Watchdog API defines the timeout in seconds, so we have to
> +  *  multiply the value.
> +  */
> + ret = i2c_smbus_write_word_data(drv_data->i2c_client,
> + BMC_CMD_WD_TIME, timeout * 10);
> + if (ret < 0)
> + return ret;
> +
> + wdt->timeout = timeout;
> +
> + return 0;
> +}
> +
> +static int menf21bmc_wdt

Re: [PATCH] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set

[Dave Chinner]

On Wed, Sep 03, 2014 at 01:54:54PM +0800, Junxiao Bi wrote:
> commit 21caf2fc1931 ("mm: teach mm by current context info to not do I/O 
> during memory allocation")
> introduces PF_MEMALLOC_NOIO flag to avoid doing I/O inside memory allocation, 
> __GFP_IO is cleared
> when this flag is set, but __GFP_FS implies __GFP_IO, it should also be 
> cleared. Or it may still
> run into I/O, like in superblock shrinker.
> 
> Signed-off-by: Junxiao Bi 
> Cc: joyce.xue 
> Cc: Ming Lei 
> ---
>  include/linux/sched.h |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 5c2c885..2fb2c47 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1936,11 +1936,13 @@ extern void thread_group_cputime_adjusted(struct 
> task_struct *p, cputime_t *ut,
>  #define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
>  #define used_math() tsk_used_math(current)
>  
> -/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
> +/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags
> + * __GFP_FS is also cleared as it implies __GFP_IO.
> + */
>  static inline gfp_t memalloc_noio_flags(gfp_t flags)
>  {
>   if (unlikely(current->flags & PF_MEMALLOC_NOIO))
> - flags &= ~__GFP_IO;
> + flags &= ~(__GFP_IO | __GFP_FS);
>   return flags;
>  }

You also need to mask all the shrink_control->gfp_mask
initialisations in mm/vmscan.c. The current code only masks the page
reclaim gfp_mask, not those that are passed to the shrinkers.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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 v4 01/11] cpumask: factor out show_cpumap into separate helper function

[Peter Zijlstra]

On Thu, Sep 04, 2014 at 10:03:25AM +0100, Sudeep Holla wrote:
> If I don't, every file including this header generates "warning:
> ‘cpumap_copy_to_buf’ defined but not used". Alternatively I can just
> declare here and define it elsewhere but I could not find more apt
> place than this. Any suggestions ? kernel/cpu.c ?

Sure the tail of cpu.c seems to have various other cpumask gunk in
already so it fits there. The other alternative would've been
lib/bitmap.c since that's where the various bitmap printf
implementations live.

You could make it bitmap_copy_to_buf() I suppose, and then have a
cpumask inline wrapper, to be fully consistent with the rest of the
implementations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] watchdog: add driver for Ricoh RN5T618 watchdog

[Lee Jones]

Wim,

Still waiting on a Watchdog Ack, so I can take this set in.

> This adds a driver for the watchdog timer available in Ricoh RN5T618
> PMIC. The device supports a programmable expiration time of 1, 8, 32
> or 128 seconds.
> 
> Signed-off-by: Beniamino Galvani 
> ---
>  drivers/watchdog/Kconfig   |   11 +++
>  drivers/watchdog/Makefile  |1 +
>  drivers/watchdog/rn5t618_wdt.c |  196 
> 
>  include/linux/mfd/rn5t618.h|4 +
>  4 files changed, 212 insertions(+)
>  create mode 100644 drivers/watchdog/rn5t618_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index f57312f..9eba6af 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -309,6 +309,17 @@ config ORION_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called orion_wdt.
>  
> +config RN5T618_WATCHDOG
> + tristate "Ricoh RN5T618 watchdog"
> + depends on MFD_RN5T618
> + select WATCHDOG_CORE
> + help
> +   If you say yes here you get support for watchdog on the Ricoh
> +   RN5T618 PMIC.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called rn5t618_wdt.
> +
>  config SUNXI_WATCHDOG
>   tristate "Allwinner SoCs watchdog support"
>   depends on ARCH_SUNXI
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 468c320..0afa343 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_IOP_WATCHDOG) += iop_wdt.o
>  obj-$(CONFIG_DAVINCI_WATCHDOG) += davinci_wdt.o
>  obj-$(CONFIG_ORION_WATCHDOG) += orion_wdt.o
>  obj-$(CONFIG_SUNXI_WATCHDOG) += sunxi_wdt.o
> +obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
>  obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
>  obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
>  obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> diff --git a/drivers/watchdog/rn5t618_wdt.c b/drivers/watchdog/rn5t618_wdt.c
> new file mode 100644
> index 000..3a76ad7
> --- /dev/null
> +++ b/drivers/watchdog/rn5t618_wdt.c
> @@ -0,0 +1,196 @@
> +/*
> + * Watchdog driver for Ricoh RN5T618 PMIC
> + *
> + * Copyright (C) 2014 Beniamino Galvani 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME "rn5t618-wdt"
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +static unsigned int heartbeat = -1;
> +
> +module_param(heartbeat, int, 0);
> +MODULE_PARM_DESC(heartbeat, "Initial watchdog heartbeat in seconds");
> +
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started 
> (default="
> +  __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +struct rn5t618_wdt {
> + struct watchdog_device wdt_dev;
> + struct rn5t618 *rn5t618;
> +};
> +
> +/*
> + * This array encodes the values of WDOGTIM field for the supported
> + * watchdog expiration times. If the watchdog is not accessed before
> + * the timer expiration, the PMU generates an interrupt and if the CPU
> + * doesn't clear it within one second the system is restarted.
> + */
> +static const struct {
> + u8 reg_val;
> + int time;
> +} rn5t618_wdt_map[] = {
> + { 0, 1 },
> + { 1, 8 },
> + { 2, 32 },
> + { 3, 128 },
> +};
> +
> +static int rn5t618_wdt_set_timeout(struct watchdog_device *wdt_dev,
> +unsigned int timeout)
> +{
> + struct rn5t618_wdt *wdt = watchdog_get_drvdata(wdt_dev);
> + int ret, i;
> +
> + for (i = 0; i < ARRAY_SIZE(rn5t618_wdt_map); i++) {
> + if (rn5t618_wdt_map[i].time + 1 >= timeout)
> + break;
> + }
> +
> + if (i == ARRAY_SIZE(rn5t618_wdt_map))
> + ret = -EINVAL;
> + else
> + ret = regmap_update_bits(wdt->rn5t618->regmap, RN5T618_WATCHDOG,
> +  RN5T618_WATCHDOG_WDOGTIM_M,
> +  rn5t618_wdt_map[i].reg_val);
> + if (!ret)
> + wdt_dev->timeout = rn5t618_wdt_map[i].time;
> +
> + return ret;
> +}
> +
> +static int rn5t618_wdt_start(struct watchdog_device *wdt_dev)
> +{
> + struct rn5t618_wdt *wdt = watchdog_get_drvdata(wdt_dev);
> + int ret;
> +
> + ret = rn5t618_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
> + if (ret)
> + return ret;
> +
> + /* enable repower-on */
> + ret = regmap_update_bits(wdt->rn5t618->regmap, RN5T618_REPCNT,
> +  RN5T618_REPCNT_REPWRON,
> +  RN5T618_REPCNT_REPWRON);
> +  

Re: [PATCH resend 2/2] usb: serial: xsens_mt: always bind to interface number 1

[Johan Hovold]

On Thu, Sep 04, 2014 at 11:05:47AM +0200, Frans Klaver wrote:
> On Thu, Sep 04, 2014 at 10:15:22AM +0200, Johan Hovold wrote:
> > On Thu, Sep 04, 2014 at 09:12:05AM +0200, Frans Klaver wrote:
> > 
> > > >  static int xsens_mt_probe(struct usb_serial *serial,
> > > > const struct usb_device_id *id)
> > > >  {
> > > > -   if (!has_required_endpoints(serial->interface->cur_altsetting))
> > > > -   return -ENODEV;
> > > > -   return 0;
> > > > +   if (serial->interface->cur_altsetting.desc.bInterfaceNumber == 
> > > > 1)
> > > 
> > > This should be
> > > 
> > > if (serial->interface->cur_altsetting->desc.bInterfaceNumber == 1)
> > 
> > So this wasn't even compile tested. Always test your patches before
> > submission, including trivial ones.
> > 
> > Is the new version tested on actual hardware?
> 
> The implementation was tested (also fixed) before the first submission.
> Not the patches. Looks like I've got a step to add.
> 
> The new version is applied, built and tested with some actual hardware
> on 3.17-rc3.

Good. Both patches applied now.

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

Re: [PATCH] mm: clear __GFP_FS when PF_MEMALLOC_NOIO is set

[Dave Chinner]

On Wed, Sep 03, 2014 at 07:30:58PM -0700, Andrew Morton wrote:
> > PF_MEMALLOC_NOIO is only set for some special processes. I think it
> > won't affect much.
> 
> Maybe not now.  But once we add hacks like this, people say "goody" and
> go and use them rather than exerting the effort to sort out their
> deadlocks properly :( There will be more PF_MEMALLOC_NOIO users in
> 2019.

We got PF_MEMALLOC_NOIO because we failed to get vmalloc deadlocks
fixed. The reason vmalloc didn't get fixed?

"there will be more vmalloc users".

> Dunno, I'd like to hear David's thoughts but perhaps it would be better
> to find some way to continue to permit PF_MEMALLOC_NOIO to shrink VFS
> caches for most filesystems and find some fs-specific fix for ocfs2. 
> That would mean testing PF_MEMALLOC_NOIO directly I guess.

No special flags in the superblock shrinker, please. We have tens of
other filesystem shrinkers that might be impacted, too. If we do not
want filesystem shrinkers (note the plural) to run, the
shrink_control->gfp_mask needs to have __GFP_FS cleared from it when
it is first configured and so that context is constant across all
shrinker reclaim cases.

If you're really worried by changing PF_MEMALLOC_NOIO, then we can
introduce PF_MEMALLOC_NOFS and have the mm subsystem mask both flags
appropriately when setting the gfp_mask in the shrink_control
settings. But fundamentally, our reclaim heirarchy defines that NOIO
implies NOFS, and so we need to fix PF_MEMALLOC_NOIO anyway.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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] checkpatch: allow optional shorter config descriptions

[Joe Perches]

On Wed, 2014-09-03 at 09:32 -0700, Vadim Bendebury wrote:
> This script is used by many other projects, and in some of them the
> requirement of at least 4 line long description for all Kconfig items
> is excessive. This patch adds a command line option to control the
> required minimum length.
> 
> Tested running this script over a patch including a two line config
> description. The script generated a warning when invoked as is, and
> did not generate it when invoked with --min-conf-desc-length=2.
> 
> Signed-off-by: Vadim Bendebury 
> ---
> 
>  scripts/checkpatch.pl | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index b385bcb..8808bde 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -43,6 +43,7 @@ my $configuration_file = ".checkpatch.conf";
>  my $max_line_length = 80;
>  my $ignore_perl_version = 0;
>  my $minimum_perl_version = 5.10.0;
> +my $min_conf_desc_length = 4;
>  
>  sub help {
>   my ($exitcode) = @_;
> @@ -63,6 +64,7 @@ Options:
>--types TYPE(,TYPE2...)show only these comma separated message types
>--ignore TYPE(,TYPE2...)   ignore various comma separated message types
>--max-line-length=nset the maximum line length, if exceeded, warn
> +  --min-conf-desc-length=n   set the min description length, if shorter, warn
>--show-types   show the message "types" in the output
>--root=PATHPATH to the kernel tree root
>--no-summary   suppress the per-file summary
> @@ -131,6 +133,7 @@ GetOptions(
>   'types=s'   => \@use,
>   'show-types!'   => \$show_types,
>   'max-line-length=i' => \$max_line_length,
> + 'min-conf-desc-length=i' => \$min_conf_desc_length,
>   'root=s'=> \$root,
>   'summary!'  => \$summary,
>   'mailback!' => \$mailback,
> @@ -2281,7 +2284,8 @@ sub process {
>   $length++;
>   }
>   WARN("CONFIG_DESCRIPTION",
> -  "please write a paragraph that describes the 
> config symbol fully\n" . $herecurr) if ($is_start && $is_end && $length < 4);
> +  "please write a paragraph that describes the 
> config symbol fully\n" . $herecurr)
> + if ($is_start && $is_end && $length < 
> $min_conf_desc_length);
>   #print "is_start<$is_start> is_end<$is_end> 
> length<$length>\n";
>   }

Fine by me, but I think think this is the
only checkpatch use of:

WARN(foo) if (test);

Every other checkpatch message block is:

if (test) {
WARN(foo);
}

so I would prefer to change this use
to match.
---
 scripts/checkpatch.pl | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d89857d..af4659c1 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -43,6 +43,7 @@ my $configuration_file = ".checkpatch.conf";
 my $max_line_length = 80;
 my $ignore_perl_version = 0;
 my $minimum_perl_version = 5.10.0;
+my $min_conf_desc_length = 4;
 
 sub help {
my ($exitcode) = @_;
@@ -63,6 +64,7 @@ Options:
   --types TYPE(,TYPE2...)show only these comma separated message types
   --ignore TYPE(,TYPE2...)   ignore various comma separated message types
   --max-line-length=nset the maximum line length, if exceeded, warn
+  --min-conf-desc-length=n   set the min description length, if shorter, warn
   --show-types   show the message "types" in the output
   --root=PATHPATH to the kernel tree root
   --no-summary   suppress the per-file summary
@@ -131,6 +133,7 @@ GetOptions(
'types=s'   => \@use,
'show-types!'   => \$show_types,
'max-line-length=i' => \$max_line_length,
+   'min-conf-desc-length=i' => \$min_conf_desc_length,
'root=s'=> \$root,
'summary!'  => \$summary,
'mailback!' => \$mailback,
@@ -2280,9 +2283,10 @@ sub process {
}
$length++;
}
-   WARN("CONFIG_DESCRIPTION",
-"please write a paragraph that describes the 
config symbol fully\n" . $herecurr) if ($is_start && $is_end && $length < 4);
-   #print "is_start<$is_start> is_end<$is_end> 
length<$length>\n";
+   if ($is_start && $is_end && $length < 
$min_conf_desc_length) {
+   WARN("CONFIG_DESCRIPTION",
+"please write a paragraph that describes 
the config symbol fully\n" . $herecurr);
+   }
}
 
 # discourage the addition of CONFIG_EXPERIMENTAL in Kconfig.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of 

Re: [PATCH v4 4/8] arm: use fixmap for text patching when text is RO

[Will Deacon]

On Wed, Sep 03, 2014 at 10:43:58PM +0100, Kees Cook wrote:
> On Wed, Aug 20, 2014 at 5:28 AM, Kees Cook  wrote:
> > On Tue, Aug 19, 2014 at 7:29 AM, Will Deacon  wrote:
> >> On Wed, Aug 13, 2014 at 06:06:29PM +0100, Kees Cook wrote:
> >>> +static void __kprobes *patch_map(void *addr, int fixmap, unsigned long 
> >>> *flags)
> >>> + __acquires(&patch_lock)
> >>> +{
> >>> + unsigned int uintaddr = (uintptr_t) addr;
> >>> + bool module = !core_kernel_text(uintaddr);
> >>> + struct page *page;
> >>> +
> >>> + if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
> >>> + page = vmalloc_to_page(addr);
> >>> + else if (!module && IS_ENABLED(CONFIG_DEBUG_RODATA))
> >>> + page = virt_to_page(addr);
> >>> + else
> >>> + return addr;
> >>> +
> >>> + if (flags)
> >>> + spin_lock_irqsave(&patch_lock, *flags);
> >>> + else
> >>> + __acquire(&patch_lock);
> >>
> >> I don't understand the locking here. Why is it conditional, why do we need
> >> to disable interrupts, and are you just racing against yourself?
> >
> > AIUI, the locking is here to avoid multiple users of the text poking
> > fixmaps. It's conditional because there are two fixmaps
> > (FIX_TEXT_POKE0 and FIX_TEXT_POKE1). Locking happens around 0 so
> > locking around 1 is not needed since it is only ever used when 0 is in
> > use. (__patch_text_real locks patch_lock before setting 0 when it uses
> > remapping, and if it also needs 1, it doesn't have to lock since the
> > lock is already held.)
> >
> >>> + set_fixmap(fixmap, page_to_phys(page));
> >>
> >> set_fixmap does TLB invalidation, right? I think that means it can block on
> >> 11MPCore and A15 w/ the TLBI erratum, so it's not safe to call this with
> >> interrupts disabled anyway.
> >
> > Oh right. Hrm.
> >
> > In an earlier version of this series set_fixmap did not perform TLB
> > invalidation. I wonder if this is not needed at all? (Wouldn't that be
> > nice...)
> 
> As suspected, my tests fail spectacularly without the TLB flush.
> Adding WARN_ON(!irqs_disabled()) doesn't warn, so I think we're safe
> here. Should I leave the WARN_ON in place for clarity, or some other
> comments?

I thought there was a potential call to spin_lock_irqsave right before
this TLB flush?

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

Re: [PATCH resend 2/2] usb: serial: xsens_mt: always bind to interface number 1

[Frans Klaver]

On Thu, Sep 04, 2014 at 11:22:26AM +0200, Johan Hovold wrote:
> On Thu, Sep 04, 2014 at 11:05:47AM +0200, Frans Klaver wrote:
> > 
> > The new version is applied, built and tested with some actual hardware
> > on 3.17-rc3.
> 
> Good. Both patches applied now.

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

Re: [PATCH v2.1 1/7] Adding Skyworks SKY81452 MFD driver

[Lee Jones]

You need a nice commit log here.

> v2.1:
> Clear mfd_cells to zero before setting.
> Added of_compatible into mfd_cells

The changelog should be below the '---' so it doesn't appear in the
commit log.

> ---
>  drivers/mfd/Kconfig  |  12 +
>  drivers/mfd/Makefile |   1 +
>  drivers/mfd/sky81452.c   | 111 
> +++
>  include/linux/mfd/sky81452.h |  32 +
>  4 files changed, 156 insertions(+)
>  create mode 100644 drivers/mfd/sky81452.c
>  create mode 100644 include/linux/mfd/sky81452.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index de5abf2..6962b4e 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -626,6 +626,18 @@ config MFD_SM501_GPIO
>lines on the SM501. The platform data is used to supply the
>base number for the first GPIO line to register.
>  
> +config MFD_SKY81452
> + tristate "Skyworks Solutions SKY81452"
> + select MFD_CORE
> + select REGMAP_I2C
> + depends on I2C
> + help
> +   This is the core driver for the Skyworks SKY81452 backlight and
> +   voltage regulator device.
> +
> +   This driver can also be built as a module.  If so, the module
> +   will be called sky81452.
> +
>  config MFD_SMSC
> bool "SMSC ECE1099 series chips"
> depends on I2C=y
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index f001487..6c2f317 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)  += as3711.o
>  obj-$(CONFIG_MFD_AS3722) += as3722.o
>  obj-$(CONFIG_MFD_STW481X)+= stw481x.o
>  obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> +obj-$(CONFIG_MFD_SKY81452)   += sky81452.o
>  
>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> diff --git a/drivers/mfd/sky81452.c b/drivers/mfd/sky81452.c
> new file mode 100644
> index 000..e91b928
> --- /dev/null
> +++ b/drivers/mfd/sky81452.c
> @@ -0,0 +1,111 @@
> +/*
> + * sky81452.cSKY81452 MFD driver
> + *
> + * Copyright 2014 Skyworks Solutions Inc.
> + * Author : Gyungoh Yoo 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2, or (at your option) any
> + * later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct regmap_config sky81452_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
> +static int sky81452_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &client->dev;
> + const struct sky81452_platform_data *pdata = dev_get_platdata(dev);
> + struct mfd_cell cells[2];
> + struct regmap *regmap;
> + int ret;
> +
> + if (!pdata) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> + }
> +
> + regmap = devm_regmap_init_i2c(client, &sky81452_config);
> + if (IS_ERR(regmap)) {
> + dev_err(dev, "failed to initialize I2C:%d", PTR_ERR(regmap));

Put a space before %d, or else it looks like a dodgy I2C address.

> + return PTR_ERR(regmap);
> + }
> +
> + i2c_set_clientdata(client, regmap);
> +
> + memset(cells, 0, sizeof(cells));
> + cells[0].name = "sky81452-bl";
> + cells[0].of_compatible = "skyworks,sky81452-backlight";
> + cells[0].platform_data = pdata->bl_pdata;
> + cells[0].pdata_size = sizeof(*pdata->bl_pdata);
> + cells[1].name = "sky81452-regulator";
> + cells[1].of_compatible = "skyworks,sky81452-regulator";
> + cells[1].platform_data = pdata->regulator_init_data;
> + cells[1].pdata_size = sizeof(*pdata->regulator_init_data);
> +
> + ret = mfd_add_devices(dev, -1, cells, ARRAY_SIZE(cells), NULL, 0, NULL);
> + if (IS_ERR_VALUE(ret))

Just use if (ret).

> + dev_err(dev, "failed to add child device:%d", ret);

s/device/devices

> +
> + return ret;
> +}
> +
> +static int sky81452_remove(struct i2c_client *client)
> +{
> + mfd_remove_devices(&client->dev);
> + return 0;
> +}
> +
> +static const struct i2c_device_id sky81452_ids[] = {
> + { "sky81452" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, sky81452_ids);
> +
> +#ifdef CONF

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

just i915 and vmwgfx fixes,

i915 contains a bunch of fixes for recent regressions in outputs,
vmwgfx fixes a possible loop for ever and a bad return code.

Dave.

The following changes since commit 59753a805499f1ffbca4ac0a24b3dff67bf1:

  Merge tag 'backlight-fixes-3.17' of 
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight (2014-08-28 
10:47:10 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 3aacfda0ecd9040521fbfb4a2c53cd6bf77ae4ee:

  Merge tag 'drm-intel-fixes-2014-09-03' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2014-09-04 11:20:00 
+1000)



Dave Airlie (4):
  Merge tag 'drm-intel-fixes-2014-08-28' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  drm/i915: handle G45/GM45 pulse detection connected state.
  Merge branch 'vmwgfx-fixes-3.17' of 
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2014-09-03' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Mathias Krause (1):
  drm/i915: Remove bogus __init annotation from DMI callbacks

Paulo Zanoni (1):
  drm/i915: fix plane/cursor handling when runtime suspended

Scot Doyle (2):
  drm/i915: Ignore VBT backlight presence check on Acer C720 (4005U)
  drm/i915: don't warn if backlight unexpectedly enabled

Thomas Hellstrom (2):
  drm/vmwgfx: Fix an incorrect OOM return value
  drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle

Ville Syrjälä (2):
  drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to 
haswell_crtc_disable()
  drm/i915: Fix lock dropping in intel_tv_detect()

 drivers/gpu/drm/i915/intel_bios.c   |  2 +-
 drivers/gpu/drm/i915/intel_crt.c|  2 +-
 drivers/gpu/drm/i915/intel_display.c| 34 +---
 drivers/gpu/drm/i915/intel_dp.c | 55 ++---
 drivers/gpu/drm/i915/intel_lvds.c   |  2 +-
 drivers/gpu/drm/i915/intel_panel.c  |  8 ++---
 drivers/gpu/drm/i915/intel_tv.c | 10 --
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 11 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|  3 +-
 9 files changed, 88 insertions(+), 39 deletions(-)

Re: [PATCH 0/3 v5] sched: Rewrite per entity runnable load average tracking

[Yuyang Du]

Ping Peter and Ingo, and Paul and Ben.

Yuyang

On Fri, Aug 01, 2014 at 08:30:59AM +0800, Yuyang Du wrote:
> v5 changes:
> 
> Thank Peter intensively for reviewing this patchset in detail and all his 
> comments.
> And Mike for general and cgroup pipe-test. Morten, Ben, and Vincent in the 
> discussion.
> 
> - Remove dead task and task group load_avg
> - Do not update trivial delta to task_group load_avg (threshold 1/64 
> old_contrib)
> - mul_u64_u32_shr() is used in decay_load, so on 64bit, load_sum can afford
>   about 4353082796 (=2^64/47742/88761) entities with the highest weight 
> (=88761)
>   always runnable, greater than previous theoretical maximum 132845
> - Various code efficiency and style changes
> 
> We carried out some performance tests (thanks to Fengguang and his LKP). The 
> results
> are shown as follows. The patchset (including threepatches) is on top of 
> mainline
> v3.16-rc5. We may report more perf numbers later.
> 
> Overall, this rewrite has better performance, and reduced net overhead in load
> average tracking, flat efficiency in multi-layer cgroup pipe-test.
> 
> --
> 
> host: lkp-snb01
> model: Sandy Bridge-EP
> memory: 32G
> 
> host: lkp-hsx03
> model: Brickland Haswell-EX
> nr_cpu: 144
> memory: 128G
> 
> host: xps2
> model: Nehalem
> memory: 4G
> 
> Legend:
>   [+-]XX% - change percent
>   ~XX%- stddev percent
> 
>v3.16-rc5   PATCH 1/3 + 2/3 + 3/3
> ---  -  
> 150854 ~ 2% +53.3% 231234 ~ 0%  
> lkp-snb01/hackbench/1600%-process-pipe
> 150986 ~ 1%  +1.6% 153470 ~ 0%  
> lkp-snb01/hackbench/1600%-process-socket
> 174142 ~ 2% +19.1% 207396 ~ 0%  
> lkp-snb01/hackbench/1600%-threads-pipe
> 156982 ~ 0%  -0.8% 155706 ~ 1%  
> lkp-snb01/hackbench/1600%-threads-socket
>  95201 ~ 0%  -0.7%  94492 ~ 0%  
> lkp-snb01/hackbench/50%-process-pipe
>  85279 ~ 0% +78.7% 152428 ~ 1%  
> lkp-snb01/hackbench/50%-process-socket
>  89911 ~ 0%  +0.6%  90477 ~ 0%  
> lkp-snb01/hackbench/50%-threads-pipe
>  78145 ~ 0% +87.5% 146505 ~ 0%  
> lkp-snb01/hackbench/50%-threads-socket
> 981503 ~ 1% +25.5%1231710 ~ 0%  TOTAL hackbench.throughput
> 
> ---  -  
>   75839119 ~ 0%  +0.1%   75922106 ~ 0%  xps2/pigz/100%-128K
>   77292677 ~ 0%  +0.1%   77399500 ~ 0%  xps2/pigz/100%-512K
>  153131796 ~ 0%  +0.1%  153321606 ~ 0%  TOTAL pigz.throughput
> 
> ---  -  
>   28868660 ~ 0%  +0.5%   29000332 ~ 0%  
> lkp-hsx03/vm-scalability/300s-anon-r-rand-mt
>   28760522 ~ 0%  +1.1%   29090639 ~ 0%  
> lkp-hsx03/vm-scalability/300s-anon-r-rand
>  3.351e+08 ~ 0%  +0.1%  3.353e+08 ~ 0%  
> lkp-hsx03/vm-scalability/300s-anon-r-seq-mt
>  3.346e+08 ~ 0%  +0.5%  3.364e+08 ~ 0%  
> lkp-hsx03/vm-scalability/300s-anon-r-seq
>   33537242 ~ 1%  +0.2%   33592010 ~ 0%  
> lkp-hsx03/vm-scalability/300s-anon-rx-rand-mt
>  3.358e+08 ~ 0%  +0.7%   3.38e+08 ~ 0%  
> lkp-hsx03/vm-scalability/300s-anon-rx-seq-mt
>1805110 ~ 0%  -0.0%1804723 ~ 0%  
> lkp-hsx03/vm-scalability/300s-lru-file-mmap-read-rand
>   13024108 ~ 0%  +8.8%   14171706 ~ 0%  
> lkp-hsx03/vm-scalability/300s-lru-file-mmap-read
>  1.112e+09 ~ 0%  +0.5%  1.117e+09 ~ 0%  TOTAL vm-scalability.throughput
> 
> --
> 
> v4 changes:
> 
> Thanks to Morten, Ben, and Fengguang for v4 revision.
> 
> - Insert memory barrier before writing cfs_rq->load_last_update_copy.
> - Fix typos.
> 
> v3 changes:
> 
> Many thanks to Ben for v3 revision.
> 
> Regarding the overflow issue, we now have for both entity and cfs_rq:
> 
> struct sched_avg {
> .
> u64 load_sum;
> unsigned long load_avg;
> .
> };
> 
> Given the weight for both entity and cfs_rq is:
> 
> struct load_weight {
> unsigned long weight;
> .
> };
> 
> So, load_sum's max is 47742 * load.weight (which is unsigned long), then on 
> 32bit,
> it is absolutly safe. On 64bit, with unsigned long being 64bit, but we can 
> afford
> about 4353082796 (=2^64/47742/88761) entities with the highest weight (=88761)
> always runnable, even considering we may multiply 1<<15 in decay_load64, we 
> can
> still support 132845 (=4353082796/2^15) always runnable, which should be 
> acceptible.
> 
> load_avg = load_sum / 47742 = load.weight (which is unsigned long), so it 
> should be
> perfectly safe for both entity (even with arbitrary user group share) and 
> cfs_rq on
> both 32bit and 64bit. Originally, we saved this division, but have to get it 
> back
> because of the overflow issue on 32bit (actually load average itself is safe 
> from
> overflow, but the rest of the code referencing it always uses long, such as 
> cpu_load,
> etc., which prevents it from sa

[PATCH] ARM: clk-imx6sl: correct the pxp and epdc axi clock selections

[Fancy Fang]

The parent clocks of IMX6SL_CLK_PXP_AXI_SEL and IMX6SL_CLK_EPDC_AXI_SEL
clocks are not the same. So split the epdc_pxp_sels into two different
clock selections 'pxp_axi_sels' and 'epdc_axi_sels'.

Signed-off-by: Fancy Fang 
Signed-off-by: Robby Cai 
Acked-by: Shawn Guo 
---
 arch/arm/mach-imx/clk-imx6sl.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
index 43261ea..d730dfa 100644
--- a/arch/arm/mach-imx/clk-imx6sl.c
+++ b/arch/arm/mach-imx/clk-imx6sl.c
@@ -47,7 +47,8 @@ static const char *csi_lcdif_sels[]   = { "mmdc", 
"pll2_pfd2", "pll3_120m", "pll3_
 static const char *usdhc_sels[]= { "pll2_pfd2", "pll2_pfd0", };
 static const char *ssi_sels[]  = { "pll3_pfd2", "pll3_pfd3", 
"pll4_audio_div", "dummy", };
 static const char *perclk_sels[]   = { "ipg", "osc", };
-static const char *epdc_pxp_sels[] = { "mmdc", "pll3_usb_otg", 
"pll5_video_div", "pll2_pfd0", "pll2_pfd2", "pll3_pfd1", };
+static const char *pxp_axi_sels[]  = { "pll2_bus", "pll3_usb_otg", 
"pll5_video_div", "pll2_pfd0", "pll2_pfd2", "pll3_pfd3", };
+static const char *epdc_axi_sels[] = { "pll2_bus", "pll3_usb_otg", 
"pll5_video_div", "pll2_pfd0", "pll2_pfd2", "pll3_pfd2", };
 static const char *gpu2d_ovg_sels[]= { "pll3_pfd1", "pll3_usb_otg", 
"pll2_bus", "pll2_pfd2", };
 static const char *gpu2d_sels[]= { "pll2_pfd2", 
"pll3_usb_otg", "pll3_pfd1", "pll2_bus", };
 static const char *lcdif_pix_sels[]= { "pll2_bus", "pll3_usb_otg", 
"pll5_video_div", "pll2_pfd0", "pll3_pfd0", "pll3_pfd1", };
@@ -251,8 +252,8 @@ static void __init imx6sl_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SL_CLK_SSI2_SEL] = imx_clk_fixup_mux("ssi2_sel",   
base + 0x1c, 12, 2, ssi_sels,  ARRAY_SIZE(ssi_sels),
imx_cscmr1_fixup);
clks[IMX6SL_CLK_SSI3_SEL] = imx_clk_fixup_mux("ssi3_sel",   
base + 0x1c, 14, 2, ssi_sels,  ARRAY_SIZE(ssi_sels),
imx_cscmr1_fixup);
clks[IMX6SL_CLK_PERCLK_SEL]   = imx_clk_fixup_mux("perclk_sel", 
base + 0x1c, 6,  1, perclk_sels,   ARRAY_SIZE(perclk_sels), 
imx_cscmr1_fixup);
-   clks[IMX6SL_CLK_PXP_AXI_SEL]  = imx_clk_mux("pxp_axi_sel",  
base + 0x34, 6,  3, epdc_pxp_sels, ARRAY_SIZE(epdc_pxp_sels));
-   clks[IMX6SL_CLK_EPDC_AXI_SEL] = imx_clk_mux("epdc_axi_sel", 
base + 0x34, 15, 3, epdc_pxp_sels, ARRAY_SIZE(epdc_pxp_sels));
+   clks[IMX6SL_CLK_PXP_AXI_SEL]  = imx_clk_mux("pxp_axi_sel",  
base + 0x34, 6,  3, pxp_axi_sels,  ARRAY_SIZE(pxp_axi_sels));
+   clks[IMX6SL_CLK_EPDC_AXI_SEL] = imx_clk_mux("epdc_axi_sel", 
base + 0x34, 15, 3, epdc_axi_sels, ARRAY_SIZE(epdc_axi_sels));
clks[IMX6SL_CLK_GPU2D_OVG_SEL]= imx_clk_mux("gpu2d_ovg_sel",
base + 0x18, 4,  2, gpu2d_ovg_sels,ARRAY_SIZE(gpu2d_ovg_sels));
clks[IMX6SL_CLK_GPU2D_SEL]= imx_clk_mux("gpu2d_sel",
base + 0x18, 8,  2, gpu2d_sels,ARRAY_SIZE(gpu2d_sels));
clks[IMX6SL_CLK_LCDIF_PIX_SEL]= imx_clk_mux("lcdif_pix_sel",
base + 0x38, 6,  3, lcdif_pix_sels,ARRAY_SIZE(lcdif_pix_sels));
-- 
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 v3 3/4] Documentation/scheduler/sched-deadline.txt: improve and clarify AC bits

[Juri Lelli]

Hi,

On 03/09/14 10:18, Juri Lelli wrote:
> Hi,
> 
> On 03/09/14 07:49, Luca Abeni wrote:
>> Hi,
>>
>> On 09/02/2014 11:45 PM, Henrik Austad wrote:
>> [...]
 + On multiprocessor systems with global EDF scheduling (non partitioned
 + systems), a sufficient test for schedulability can not be based on the
 + utilisations (it can be shown that task sets with utilisations slightly
 + larger than 1 can miss deadlines regardless of the number of CPUs M).
 + However, as previously stated, enforcing that the total utilisation is 
 smaller
 + than M is enough to guarantee that non real-time tasks are not starved 
 and
 + that the tardiness of real-time tasks has an upper bound.
>>>
>>> I'd _really_ appreciate a link to a paper where all of this is presented
>>> and proved!
>> Well, my original plan was to add the bibliography in the next round of 
>> patches...
>> Is this ok?
>>
>> [...]
 + As already stated in Section 3, a necessary condition to be respected to
 + correctly schedule a set of real-time tasks is that the total utilisation
 + is smaller than M. When talking about -deadline tasks, this requires to
 + impose that the sum of the ratio between runtime and period for all tasks
 + is smaller than M.
>>>
>>> "This requires to impose that .." uhm, what? Drop 'to impose'.
>> Ok. I'll send an updated patch to Juri in few days
>>
>>
 [...] Notice that the ratio runtime/period is equivalent to
 + the utilisation of a "traditional" real-time task, and is also often
 + referred to as "bandwidth".
 + The interface used to control the CPU bandwidth that can be allocated
 + to -deadline tasks is similar to the one already used for -rt
tasks with real-time group scheduling (a.k.a. RT-throttling - see
Documentation/scheduler/sched-rt-group.txt), and is based on readable/
writable control files located in procfs (for system wide settings).
 @@ -232,8 +285,16 @@ CONTENTS
95. With rt_period equal to 100, by default, it means that 
 -deadline
tasks can use at most 95%, multiplied by the number of CPUs that 
 compose the
root_domain, for each root_domain.
 -
 - A -deadline task cannot fork.
 + This means that non -deadline tasks will receive at least 5% of the CPU 
 time,
 + and that -deadline tasks will receive their runtime with a guaranteed
 + worst-case delay respect to the "deadline" parameter. If "deadline" = 
 "period"
 + and the cpuset mechanism is used to implement partitioned scheduling (see
 + Section 5), then this simple setting of the bandwidth management is able 
 to
 + deterministically guarantee that -deadline tasks will receive their 
 runtime
 + in a period.
>>>
>>> The whole 95 / 100, is at least 50 *consecutive* ms given to non
>>> rt/dl tasks every second, or is this more finegrained now?
>>>
>>> If the 50ms can be given in a single go, then I don't think you can
>>> guarantee that deadline-tasks will receive their runtime in a period - a
>>> period can be <50ms, no?
>> Uhmm... Maybe there is something I am missing in how the SCHED_DEADLINE 
>> admission
>> control is implemented, but I do not know about any "50 consecutive ms to 
>> non dl
>> tasks" rule. I agree that if there is such a rule then deadline tasks are 
>> screwed.
>> Juri?
>>
>>
> 
> In SCHED_DEADLINE we use those values only at admission control time (when
> the user calls sched_setattr()). Then, at runtime, we use tasks' parameters
> to perform scheduling. So there is no consecutive 50ms time for 
> !SCHED_DEADLINE
> tasks.
> 
> We could probably clarify this aspect in the previous patch with something
> like this:
> 
> [snip]
> + The interface used to control the fraction of CPU bandwidth that can be
> + allocated to -deadline tasks is similar to the one already used for -rt
> + tasks with real-time group scheduling (a.k.a. RT-throttling - see
> + Documentation/scheduler/sched-rt-group.txt), and is based on readable/
> + writable control files located in procfs (for system wide settings).
> + Notice that per-group settings (controlled through cgroupfs) are still not
> + defined for -deadline tasks, because more discussion is needed in order to
> + figure out how we want to manage SCHED_DEADLINE bandwidth at the task group
> + level.
> +
> + A main difference between deadline bandwidth management and RT-throttling
>   is that -deadline tasks have bandwidth on their own (while -rt ones don't!),
> - and thus we don't need an higher level throttling mechanism to enforce the
> - desired bandwidth.
> + and thus we don't need a higher level throttling mechanism to enforce the
> >
> + desired bandwidth. In other words, this means that interface parameters are
> + only used at admission control time (i.e., when the user calls
> + sched_setattr()). Scheduling is then performed considering actual tasks'
> + parameters, so that CPU bandwidth is

[PATCH] mfd: pcf50633: use sprintf directly

[Andy Shevchenko]

When dump a content of the registers let's use snprintf() directly with %*ph
specifier.

Signed-off-by: Andy Shevchenko 
---
 drivers/mfd/pcf50633-core.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
index c87f7a0..8401552 100644
--- a/drivers/mfd/pcf50633-core.c
+++ b/drivers/mfd/pcf50633-core.c
@@ -106,10 +106,7 @@ static ssize_t show_dump_regs(struct device *dev, struct 
device_attribute *attr,
} else
dump[n1] = pcf50633_reg_read(pcf, n + n1);
 
-   hex_dump_to_buffer(dump, sizeof(dump), 16, 1, buf1, 128, 0);
-   buf1 += strlen(buf1);
-   *buf1++ = '\n';
-   *buf1 = '\0';
+   buf1 += sprintf(buf1, "%*ph\n", (int)sizeof(dump), dump);
}
 
return buf1 - buf;
-- 
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 v4] x86, hotplug: fix llc shared map unreleased during cpu hotplug

[Wanpeng Li]

Hi Ingo,
On Thu, Sep 04, 2014 at 04:56:41PM +0800, Wanpeng Li wrote:
>On Thu, Sep 04, 2014 at 07:20:34AM +0200, Ingo Molnar wrote:
>>
>>* Wanpeng Li  wrote:
>>
>>> BUG: unable to handle kernel NULL pointer dereference at 0004
>>> IP: [..] find_busiest_group
>>> PGD 5a9d5067 PUD 13067 PMD 0
>>> Oops:  [#3] SMP
>>> [...]
>>> Call Trace:
>>> load_balance
>>> ? _raw_spin_unlock_irqrestore
>>> idle_balance
>>> __schedule
>>> schedule
>>> schedule_timeout
>>> ? lock_timer_base
>>> schedule_timeout_uninterruptible
>>> msleep
>>> lock_device_hotplug_sysfs
>>> online_store
>>> dev_attr_store
>>> sysfs_write_file
>>> vfs_write
>>> SyS_write
>>> system_call_fastpath
>>> 
>>> Last level cache shared map is built during cpu up and build sched domain 
>>> routine takes advantage of it to setup sched domain cpu topology, however, 
>>> llc shared map is unreleased during cpu disable which lead to invalid sched 
>>> domain cpu topology. This patch fix it by release llc shared map correctly
>>> during cpu disable.
>>
>>Very little is said in this changelog about how the bug was 
>>found, how likely it is to occur for others, what systems are 
>>affected, etc.
>
>This bug can be triggered by hot add and remove large number of xen 
>domain0's vcpus repeated.
>

If I need to send a new version of the patch or you can pick the patch
w/ the updated changelog for me? ;-)

Regards,
Wanpeng Li 

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

Re: [PATCH v6 2/3] mfd: qcom-rpm: Driver for the Qualcomm RPM

[Lee Jones]

On Mon, 25 Aug 2014, Bjorn Andersson wrote:

> Driver for the Resource Power Manager (RPM) found in Qualcomm 8660, 8960
> and 8064 based devices. The driver exposes resources that child drivers
> can operate on; to implementing regulator, clock and bus frequency
> drivers.
> 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/mfd/Kconfig  |   14 +
>  drivers/mfd/Makefile |1 +
>  drivers/mfd/qcom_rpm.c   |  580 
> ++
>  include/linux/mfd/qcom_rpm.h |   10 +
>  4 files changed, 605 insertions(+)
>  create mode 100644 drivers/mfd/qcom_rpm.c
>  create mode 100644 include/linux/mfd/qcom_rpm.h

I'd like to take this in with the other MFD patch.

Is the regulator one okay to go in on it's own?

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 04/19] serial: samsung: Remove support for legacy clock code

[Paul Bolle]

On Wed, 2014-07-16 at 16:43 +0200, Tomasz Figa wrote:
> On 16.07.2014 16:35, Paul Bolle wrote:
> > On Wed, 2014-07-16 at 16:26 +0200, Paul Bolle wrote:
> >> On Wed, 2014-07-16 at 14:43 +0200, Tomasz Figa wrote:
> >>> That's right. Apparently I missed them. I guess that's not critical,
> >>> though, and could be done in separate patch, right?
> >>
> >> This is not critical at all, so that's fine with me. 
> > 
> > Actually, that's only correct if the solution here is to just remove the
> > (currently) dead code hidden behind CONFIG_SAMSUNG_CLOCK. But if the
> > solution requires something less trivial, that might be quite wrong.
> > 
> > So please disregard my comment!
> 
> The code between those ifdefs is no longer used, because all Samsung
> platforms use the Common Clock Framework after this series. So I believe
> we can safely remove this dead code.

The three checks for CONFIG_SAMSUNG_CLOCK can still be seen in v3.17-rc3
and next-20140903. Should I perhaps submit the trivial patch to remove
them (and the code they hide) or did things turn out to be more
complicated?


Paul Bolle

--
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 v8 2/3] mfd: Add hi6421 PMIC core driver

[Lee Jones]

On Mon, 01 Sep 2014, Guodong Xu wrote:

> This adds driver to support HiSilicon Hi6421 PMIC. Hi6421 includes multi-
> functions, such as regulators, codec, ADCs, Coulomb counter, etc.
> This driver includes core APIs _only_.
> 
> Drivers for individul components, like voltage regulators, are
> implemented in corresponding driver directories and files.
> 
> Registers in Hi6421 are memory mapped, so using regmap-mmio API.
> 
> Signed-off-by: Guodong Xu 
> ---
>  drivers/mfd/Kconfig |  13 +
>  drivers/mfd/Makefile|   1 +
>  drivers/mfd/hi6421-pmic-core.c  | 113 
> 
>  include/linux/mfd/hi6421-pmic.h |  41 +++
>  4 files changed, 168 insertions(+)
>  create mode 100644 drivers/mfd/hi6421-pmic-core.c
>  create mode 100644 include/linux/mfd/hi6421-pmic.h

Applied, thanks.

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index de5abf2..2de4919 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -210,6 +210,19 @@ config MFD_MC13XXX_I2C
>   help
> Select this if your MC13xxx is connected via an I2C bus.
>  
> +config MFD_HI6421_PMIC
> + tristate "HiSilicon Hi6421 PMU/Codec IC"
> + depends on OF
> + select MFD_CORE
> + select REGMAP_MMIO
> + help
> +   Add support for HiSilicon Hi6421 PMIC. Hi6421 includes multi-
> +   functions, such as regulators, RTC, codec, Coulomb counter, etc.
> +   This driver includes core APIs _only_. You have to select
> +   individul components like voltage regulators under corresponding
> +   menus in order to enable them.
> +   We communicate with the Hi6421 via memory-mapped I/O.
> +
>  config HTC_EGPIO
>   bool "HTC EGPIO support"
>   depends on GPIOLIB && ARM
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index f001487..dc59efd 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)  += as3711.o
>  obj-$(CONFIG_MFD_AS3722) += as3722.o
>  obj-$(CONFIG_MFD_STW481X)+= stw481x.o
>  obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> +obj-$(CONFIG_MFD_HI6421_PMIC)+= hi6421-pmic-core.o
>  
>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> diff --git a/drivers/mfd/hi6421-pmic-core.c b/drivers/mfd/hi6421-pmic-core.c
> new file mode 100644
> index 000..321a265
> --- /dev/null
> +++ b/drivers/mfd/hi6421-pmic-core.c
> @@ -0,0 +1,113 @@
> +/*
> + * Device driver for Hi6421 IC
> + *
> + * Copyright (c) <2011-2014> HiSilicon Technologies Co., Ltd.
> + *  http://www.hisilicon.com
> + * Copyright (c) <2013-2014> Linaro Ltd.
> + *  http://www.linaro.org
> + *
> + * Author: Guodong Xu 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static const struct mfd_cell hi6421_devs[] = {
> + { .name = "hi6421-regulator", },
> +};
> +
> +static struct regmap_config hi6421_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 8,
> + .max_register = HI6421_REG_TO_BUS_ADDR(HI6421_REG_MAX),
> +};
> +
> +static int hi6421_pmic_probe(struct platform_device *pdev)
> +{
> + struct hi6421_pmic *pmic;
> + struct resource *res;
> + void __iomem *base;
> + int ret;
> +
> + pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
> + if (!pmic)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + pmic->regmap = devm_regmap_init_mmio_clk(&pdev->dev, NULL, base,
> +  &hi6421_regmap_config);
> + if (IS_ERR(pmic->regmap)) {
> + dev_err(&pdev->dev,
> + "regmap init failed: %ld\n", PTR_ERR(pmic->regmap));
> + return PTR_ERR(pmic->regmap);
> + }
> +
> + /* set over-current protection debounce 8ms */
> + regmap_update_bits(pmic->regmap, HI6421_OCP_DEB_CTRL_REG,
> + (HI6421_OCP_DEB_SEL_MASK
> +  | HI6421_OCP_EN_DEBOUNCE_MASK
> +   

Re: [PATCH 04/19] serial: samsung: Remove support for legacy clock code

[Paul Bolle]

[Use Tomasz's new address and add Sylwester.]

On Thu, 2014-09-04 at 11:39 +0200, Paul Bolle wrote:
> On Wed, 2014-07-16 at 16:43 +0200, Tomasz Figa wrote:
> > On 16.07.2014 16:35, Paul Bolle wrote:
> > > On Wed, 2014-07-16 at 16:26 +0200, Paul Bolle wrote:
> > >> On Wed, 2014-07-16 at 14:43 +0200, Tomasz Figa wrote:
> > >>> That's right. Apparently I missed them. I guess that's not critical,
> > >>> though, and could be done in separate patch, right?
> > >>
> > >> This is not critical at all, so that's fine with me. 
> > > 
> > > Actually, that's only correct if the solution here is to just remove the
> > > (currently) dead code hidden behind CONFIG_SAMSUNG_CLOCK. But if the
> > > solution requires something less trivial, that might be quite wrong.
> > > 
> > > So please disregard my comment!
> > 
> > The code between those ifdefs is no longer used, because all Samsung
> > platforms use the Common Clock Framework after this series. So I believe
> > we can safely remove this dead code.
> 
> The three checks for CONFIG_SAMSUNG_CLOCK can still be seen in v3.17-rc3
> and next-20140903. Should I perhaps submit the trivial patch to remove
> them (and the code they hide) or did things turn out to be more
> complicated?
> 
> 
> Paul Bolle

--
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 v8 1/3] Documentation: mfd: add docs for hi6421 dt

[Lee Jones]

On Mon, 01 Sep 2014, Guodong Xu wrote:

> Add documentation for HiSilicon Hi6421 PMIC dt binding.
> 
> Signed-off-by: Guodong Xu 
> ---
>  Documentation/devicetree/bindings/mfd/hi6421.txt | 38 
> 
>  1 file changed, 38 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/hi6421.txt

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/hi6421.txt 
> b/Documentation/devicetree/bindings/mfd/hi6421.txt
> new file mode 100644
> index 000..0d5a446
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/hi6421.txt
> @@ -0,0 +1,38 @@
> +* HI6421 Multi-Functional Device (MFD), by HiSilicon Ltd.
> +
> +Required parent device properties:
> +- compatible : contains "hisilicon,hi6421-pmic";
> +- reg: register range space of hi6421;
> +
> +Supported Hi6421 sub-devices include:
> +
> +Device IRQ Names  Supply Names   Description
> +-- -     ---
> +regulators   :  None : None : Regulators
> +
> +Required child device properties:
> +None.
> +
> +Example:
> + hi6421 {
> + compatible = "hisilicon,hi6421-pmic";
> + reg = <0xfcc0 0x0180>; /* 0x60 << 2 */
> +
> + regulators {
> + // supply for MLC NAND/ eMMC
> + hi6421_vout0_reg: hi6421_vout0 {
> + regulator-name = "VOUT0";
> + regulator-min-microvolt = <285>;
> + regulator-max-microvolt = <285>;
> + };
> +
> + // supply for 26M Oscillator
> + hi6421_vout1_reg: hi6421_vout1 {
> + regulator-name = "VOUT1";
> + regulator-min-microvolt = <170>;
> + regulator-max-microvolt = <200>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + };
> + };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] [media] videobuf-dma-contig: replace vm_iomap_memory() with remap_pfn_range().

[Fancy Fang]

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.

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 
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index bf80f0f..8bd9889 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -305,7 +305,9 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
/* Try to remap memory */
size = vma->vm_end - vma->vm_start;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-   retval = vm_iomap_memory(vma, mem->dma_handle, size);
+   retval = remap_pfn_range(vma, vma->vm_start,
+mem->dma_handle >> PAGE_SHIFT,
+size, vma->vm_page_prot);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ",
retval);
-- 
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: clk-imx6sl: correct the pxp and epdc axi clock selections

[Fancy Fang]

The parent clocks of IMX6SL_CLK_PXP_AXI_SEL and IMX6SL_CLK_EPDC_AXI_SEL
clocks are not the same. So split the epdc_pxp_sels into two different
clock selections 'pxp_axi_sels' and 'epdc_axi_sels'.

Signed-off-by: Fancy Fang 
Signed-off-by: Robby Cai 
Acked-by: Shawn Guo 
---
 arch/arm/mach-imx/clk-imx6sl.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
index 43261ea..d730dfa 100644
--- a/arch/arm/mach-imx/clk-imx6sl.c
+++ b/arch/arm/mach-imx/clk-imx6sl.c
@@ -47,7 +47,8 @@ static const char *csi_lcdif_sels[]   = { "mmdc", 
"pll2_pfd2", "pll3_120m", "pll3_
 static const char *usdhc_sels[]= { "pll2_pfd2", "pll2_pfd0", };
 static const char *ssi_sels[]  = { "pll3_pfd2", "pll3_pfd3", 
"pll4_audio_div", "dummy", };
 static const char *perclk_sels[]   = { "ipg", "osc", };
-static const char *epdc_pxp_sels[] = { "mmdc", "pll3_usb_otg", 
"pll5_video_div", "pll2_pfd0", "pll2_pfd2", "pll3_pfd1", };
+static const char *pxp_axi_sels[]  = { "pll2_bus", "pll3_usb_otg", 
"pll5_video_div", "pll2_pfd0", "pll2_pfd2", "pll3_pfd3", };
+static const char *epdc_axi_sels[] = { "pll2_bus", "pll3_usb_otg", 
"pll5_video_div", "pll2_pfd0", "pll2_pfd2", "pll3_pfd2", };
 static const char *gpu2d_ovg_sels[]= { "pll3_pfd1", "pll3_usb_otg", 
"pll2_bus", "pll2_pfd2", };
 static const char *gpu2d_sels[]= { "pll2_pfd2", 
"pll3_usb_otg", "pll3_pfd1", "pll2_bus", };
 static const char *lcdif_pix_sels[]= { "pll2_bus", "pll3_usb_otg", 
"pll5_video_div", "pll2_pfd0", "pll3_pfd0", "pll3_pfd1", };
@@ -251,8 +252,8 @@ static void __init imx6sl_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SL_CLK_SSI2_SEL] = imx_clk_fixup_mux("ssi2_sel",   
base + 0x1c, 12, 2, ssi_sels,  ARRAY_SIZE(ssi_sels),
imx_cscmr1_fixup);
clks[IMX6SL_CLK_SSI3_SEL] = imx_clk_fixup_mux("ssi3_sel",   
base + 0x1c, 14, 2, ssi_sels,  ARRAY_SIZE(ssi_sels),
imx_cscmr1_fixup);
clks[IMX6SL_CLK_PERCLK_SEL]   = imx_clk_fixup_mux("perclk_sel", 
base + 0x1c, 6,  1, perclk_sels,   ARRAY_SIZE(perclk_sels), 
imx_cscmr1_fixup);
-   clks[IMX6SL_CLK_PXP_AXI_SEL]  = imx_clk_mux("pxp_axi_sel",  
base + 0x34, 6,  3, epdc_pxp_sels, ARRAY_SIZE(epdc_pxp_sels));
-   clks[IMX6SL_CLK_EPDC_AXI_SEL] = imx_clk_mux("epdc_axi_sel", 
base + 0x34, 15, 3, epdc_pxp_sels, ARRAY_SIZE(epdc_pxp_sels));
+   clks[IMX6SL_CLK_PXP_AXI_SEL]  = imx_clk_mux("pxp_axi_sel",  
base + 0x34, 6,  3, pxp_axi_sels,  ARRAY_SIZE(pxp_axi_sels));
+   clks[IMX6SL_CLK_EPDC_AXI_SEL] = imx_clk_mux("epdc_axi_sel", 
base + 0x34, 15, 3, epdc_axi_sels, ARRAY_SIZE(epdc_axi_sels));
clks[IMX6SL_CLK_GPU2D_OVG_SEL]= imx_clk_mux("gpu2d_ovg_sel",
base + 0x18, 4,  2, gpu2d_ovg_sels,ARRAY_SIZE(gpu2d_ovg_sels));
clks[IMX6SL_CLK_GPU2D_SEL]= imx_clk_mux("gpu2d_sel",
base + 0x18, 8,  2, gpu2d_sels,ARRAY_SIZE(gpu2d_sels));
clks[IMX6SL_CLK_LCDIF_PIX_SEL]= imx_clk_mux("lcdif_pix_sel",
base + 0x38, 6,  3, lcdif_pix_sels,ARRAY_SIZE(lcdif_pix_sels));
-- 
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] mmc: sdhci-esdhc-imx: Enable boot partition access from DT

[Jean-Michel Hautbois]

Hi Ulf,

> I am not sure adding a DT binding for non access to rpmb would be
> needed. At least until we heard of a similar case as Adrian describes
> but for rpmb.
>
> BTW, I just posted a patch which disabled partition scan of the boot
> area, what to you think about that?
> http://marc.info/?l=linux-mmc&m=140973496402028&w=2
>
> Finally I am also wondering whether we could and thus should, handle
> these situations entirely without using a host cap. In principle what
> we need is a more sophisticated error handling when the switch errors
> occurs, while trying to switch to the boot area/rpmb partitions. Could
> you maybe investigate that option, before we decide to add a new DT
> binding?

According to me and what Hsin-Hsiang Tseng wrote, it seems that we
should be able to have access to boot partitions if we want to give a
possibility of writing u-boot in one (or both) of them. This is the
way the i.MX6 will boot on a eMMC if I read the reference manual
correctly, but I didn't tested it yet.
But there is no need to scan those partitions at boot, as there will
probably never be a partition table inside, as you said.
All we need is providing access to mmc[n]blkpboot0 and mmc[n]blkpboot1
and a way to tell which one is used as default boot partition.

This is my point of view, but I didn't read JESD84-A441 so I don't
know if this is the good way.

Regards,
JM
--
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 v10 03/19] arm: fiq: Replace default FIQ handler

[Russell King - ARM Linux]

On Thu, Sep 04, 2014 at 10:09:20AM +0100, Daniel Thompson wrote:
> On 03/09/14 20:34, Russell King - ARM Linux wrote:
> > I would say that the ARM specific changes to entry-armv.S and setup.c
> > are correct.  All that you're doing there is to replace the existing
> > default no-op FIQ handler with some additional code which gets us into
> > SVC mode and back out, but itself is also a no-op.  In other words, no
> > real change.
> > 
> > That's a good first patch, and one which I would actually like to have
> > in my tree sooner rather than later, so that I can split that out from
> > my prototype code.
> 
> So would I!
> 
> I did some rebasing yesterday to put anything to do with kgdb right at
> the back of the queue. This "good first patch" is now actually the first
> patch; where the nofifier used to be it currently calls do_unexp_fiq()
> making it very close to "no real change".
> 
> BTW do_unexp_fiq() calls printk() but

You're making the assumption that something called do_unexp_fiq() before
your patches.  It seems that that function is dead code, and now that
you've pointed that out, I will kill this function.

The current situation is that if the CPU receives a FIQ, it enters the
FIQ vector, which contains an immediate return instruction.

> If you want me to work with something more recent then feel free to
> point me at it...

I'll post some of that stuff later today, probably this evening.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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: Some questions about DEBUG_PAGEALLOC on ARMv8

[Catalin Marinas]

Hi Zhichang,

(cc'ing Steve Capper for the huge page stuff)

On Fri, Aug 22, 2014 at 01:38:26PM +0100, zhichang.yuan wrote:
> I am working to implement the DEBUG_PAGEALLOC on ARMv8.

I assume that's the arm64 kernel.

> After i investigated the DEBUG_PAGEALLOC implementation on x86 arch,
> some questions are standing in the way to start coding.
> 
> 1. How to handle the large page when DEBUG_PAGEALLOC is enabled In
> ARMv8, the kernel direct memory page table entries will set the block
> flag for better performance. When DEBUG_PAGEALLOC is configured, if
> the size of freed page is not multiply of page block size, there is no
> corresponding page table entry. In the old x86 kernel version, the
> large page to be freed will be split into normal page size and build
> the corresponding PTEs. And afterwards, someone done a patch to remove
> the splitting process. It will make the code simpler and easily
> stable.

Initially, you could either map everything as pages or implement
splitting of huge pages (if for example the huge page is at the pmd
level, you allocate and populate a pte).

> I prefer the current design in x86, what are your thoughts here?

I haven't looked at it yet.

> 2. Does ARMv8 support HIBERNATION?

Not yet.

> The HIBERNATION has some dependency on DEBUG_PAGEALLOC.

Like in DEBUG_PAGEALLOC "depends on !HIBERNATION"?

> 3. Is the hypothesis of DEBUG_PAGEALLOC always true?

Which hypothesis?

> From the x86 code, DEBUG_PAGEALLOC use the invalid page table entries
> to catch the accesses to free pages. This mechanism is based on the
> hypothesis that all the corresponding page table entries that are
> corresponding to the free pages are cleared correctly. Supposed this
> condition is always true, what we need to do is just to clear the
> kernel linear mapping page entries, since those page tables are
> fixable after initialization. DEBUG_PAGEALLOC on x86 seems to do like
> that.

I guess that's the ARCH_SUPPORTS_DEBUG_PAGEALLOC rather than just the
simple DEBUG_PAGEALLOC which can be enabled on arm64 as well, you just
get page poisoning rather than invalid mappings.

It could be done on arm64 as well but you need to sort out huge page
splitting or just map everything as pages when the option is enabled.

> Is it possible the hypothesis will be broken?
> If the answer is yes, DEBUG_PAGEALLOC can catch the accesses to free
> page with kernel linear mapping address. But if the virtual address is
> from other mapped areas and target to the free pages, DEBUG_PAGEALLOC
> will do nothing.
> 
> Is this result the original objective of DEBUG_PAGEALLOC?
> I can not find the initial commit log in kernel Git, i am not sure
> about it.

The objective is written in the Kconfig:

config DEBUG_PAGEALLOC
bool "Debug page memory allocations"
...
  Unmap pages from the kernel linear mapping after free_pages().
  This results in a large slowdown, but helps to find certain types
  of memory corruption.

  For architectures which don't enable ARCH_SUPPORTS_DEBUG_PAGEALLOC,
  fill the pages with poison patterns after free_pages() and verify
  the patterns before alloc_pages().  Additionally,
  this option cannot be enabled in combination with hibernation as
  that would result in incorrect warnings of memory corruption after
  a resume because free pages are not saved to the suspend image.

-- 
Catalin
--
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 V1 1/2] ARM: clk-imx6q: refine clock tree for ASRC

[Shengjiu Wang]

ASRC has "asrc", "asrc_ipg", "asrc_mem" clocks, and they share
the same gate bits.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/mach-imx/clk-imx6q.c |5 -
 include/dt-bindings/clock/imx6qdl-clock.h |4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 2edcebf..d5bf1e2 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -107,6 +107,7 @@ static struct clk_div_table video_div_table[] = {
 };
 
 static unsigned int share_count_esai;
+static unsigned int share_count_asrc;
 
 static void __init imx6q_clocks_init(struct device_node *ccm_node)
 {
@@ -317,7 +318,9 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
 
/*name 
parent_name  reg shift */
clk[IMX6QDL_CLK_APBH_DMA] = imx_clk_gate2("apbh_dma",  
"usdhc3",base + 0x68, 4);
-   clk[IMX6QDL_CLK_ASRC] = imx_clk_gate2("asrc",  
"asrc_podf", base + 0x68, 6);
+   clk[IMX6QDL_CLK_ASRC] = imx_clk_gate2_shared("asrc", 
"asrc_podf",   base + 0x68, 6, &share_count_asrc);
+   clk[IMX6QDL_CLK_ASRC_IPG] = imx_clk_gate2_shared("asrc_ipg", 
"ahb", base + 0x68, 6, &share_count_asrc);
+   clk[IMX6QDL_CLK_ASRC_MEM] = imx_clk_gate2_shared("asrc_mem", 
"ahb", base + 0x68, 6, &share_count_asrc);
clk[IMX6QDL_CLK_CAN1_IPG] = imx_clk_gate2("can1_ipg",  "ipg",   
base + 0x68, 14);
clk[IMX6QDL_CLK_CAN1_SERIAL]  = imx_clk_gate2("can1_serial",   
"can_root",  base + 0x68, 16);
clk[IMX6QDL_CLK_CAN2_IPG] = imx_clk_gate2("can2_ipg",  "ipg",   
base + 0x68, 18);
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h 
b/include/dt-bindings/clock/imx6qdl-clock.h
index 323e865..1e99613 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -220,6 +220,8 @@
 #define IMX6QDL_CLK_LVDS2_GATE 207
 #define IMX6QDL_CLK_ESAI_IPG   208
 #define IMX6QDL_CLK_ESAI_MEM   209
-#define IMX6QDL_CLK_END210
+#define IMX6QDL_CLK_ASRC_IPG   210
+#define IMX6QDL_CLK_ASRC_MEM   211
+#define IMX6QDL_CLK_END212
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
-- 
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 V1 2/2] ARM: clk-imx6q: refine clock tree for SSI

[Shengjiu Wang]

Each SSI has "ssi", "ssi_ipg" clocks, and they share same gate bits.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/mach-imx/clk-imx6q.c |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index d5bf1e2..013d3cd 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -108,6 +108,9 @@ static struct clk_div_table video_div_table[] = {
 
 static unsigned int share_count_esai;
 static unsigned int share_count_asrc;
+static unsigned int share_count_ssi1;
+static unsigned int share_count_ssi2;
+static unsigned int share_count_ssi3;
 
 static void __init imx6q_clocks_init(struct device_node *ccm_node)
 {
@@ -392,9 +395,12 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
clk[IMX6QDL_CLK_SDMA] = imx_clk_gate2("sdma",  "ahb",   
base + 0x7c, 6);
clk[IMX6QDL_CLK_SPBA] = imx_clk_gate2("spba",  "ipg",   
base + 0x7c, 12);
clk[IMX6QDL_CLK_SPDIF]= imx_clk_gate2("spdif", 
"spdif_podf",base + 0x7c, 14);
-   clk[IMX6QDL_CLK_SSI1_IPG] = imx_clk_gate2("ssi1_ipg",  "ipg",   
base + 0x7c, 18);
-   clk[IMX6QDL_CLK_SSI2_IPG] = imx_clk_gate2("ssi2_ipg",  "ipg",   
base + 0x7c, 20);
-   clk[IMX6QDL_CLK_SSI3_IPG] = imx_clk_gate2("ssi3_ipg",  "ipg",   
base + 0x7c, 22);
+   clk[IMX6QDL_CLK_SSI1_IPG] = imx_clk_gate2_shared("ssi1_ipg",  
"ipg",base + 0x7c, 18, &share_count_ssi1);
+   clk[IMX6QDL_CLK_SSI2_IPG] = imx_clk_gate2_shared("ssi2_ipg",  
"ipg",base + 0x7c, 20, &share_count_ssi2);
+   clk[IMX6QDL_CLK_SSI3_IPG] = imx_clk_gate2_shared("ssi3_ipg",  
"ipg",base + 0x7c, 22, &share_count_ssi3);
+   clk[IMX6QDL_CLK_SSI1] = imx_clk_gate2_shared("ssi1",  
"ssi1_podf",  base + 0x7c, 18, &share_count_ssi1);
+   clk[IMX6QDL_CLK_SSI2] = imx_clk_gate2_shared("ssi2",  
"ssi2_podf",  base + 0x7c, 20, &share_count_ssi2);
+   clk[IMX6QDL_CLK_SSI3] = imx_clk_gate2_shared("ssi3",  
"ssi3_podf",  base + 0x7c, 22, &share_count_ssi3);
clk[IMX6QDL_CLK_UART_IPG] = imx_clk_gate2("uart_ipg",  "ipg",   
base + 0x7c, 24);
clk[IMX6QDL_CLK_UART_SERIAL]  = imx_clk_gate2("uart_serial",   
"uart_serial_podf",  base + 0x7c, 26);
clk[IMX6QDL_CLK_USBOH3]   = imx_clk_gate2("usboh3","ipg",   
base + 0x80, 0);
-- 
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: bit fields && data tearing

[Benjamin Herrenschmidt]

On Thu, 2014-09-04 at 08:43 +, David Laight wrote:
> From:  Benjamin Herrenschmidt
> > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> > 
> > > Apologies for hijacking this thread but I need to extend this discussion
> > > somewhat regarding what a compiler might do with adjacent fields in a 
> > > structure.
> > >
> > > The tty subsystem defines a large aggregate structure, struct tty_struct.
> > > Importantly, several different locks apply to different fields within that
> > > structure; ie., a specific spinlock will be claimed before updating or 
> > > accessing
> > > certain fields while a different spinlock will be claimed before updating 
> > > or
> > > accessing certain _adjacent_ fields.
> > >
> > > What is necessary and sufficient to prevent accidental false-sharing?
> > > The patch below was flagged as insufficient on ia64, and possibly ARM.
> > 
> > We expect native aligned scalar types to be accessed atomically (the
> > read/modify/write of a larger quantity that gcc does on some bitfield
> > cases has been flagged as a gcc bug, but shouldn't happen on normal
> > scalar types).
> 
> That isn't true on all architectures for items smaller than a machine word.
> At least one has to do rmw for byte accesses.

Yeah correct, alpha and bytes right ? Is there any other ? That's why I
suggested int.

>   David
> 
> > I am not 100% certain of "bool" here, I assume it's treated as a normal
> > scalar and thus atomic but if unsure, you can always use int.
> > 
> > Another option is to use the atomic bitops and make these bits in a
> > bitmask but that is probably unnecessary if you have locks already.
> > 
> > Cheers,
> > Ben.


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

Urgent and Confidencial

[Attorney Peter Kono]

Dear Friend
This is Attorney Peter Kono again; I really do not mean to waste your time. 
Considering the fact that this is a £16,000,000.00 British Pounds.deal shear 
rate 50/50 % and it's bank to bank wire trasaction within three workind days.
 
I carefully contact you due to many Internet frauds nowadays.but i put my faith 
in God because all things in life is by risk but don't let me down now or 
after, This is Mr.Plaviashakunthala Lobo and his family was involved in plan 
crash 22nd of May 2010 in List of passengers on Air India Express flight that 
crash  32.Plaviashakunthala Lobo 33. Venishanikola Lobo
34. Vishalfloid Lobo (child) and all family died without any inheritance or 
next of kin so i want you to work together with me been an attorney so this is 
Mr.Plaviashakunthala Lobo account details.
 
Bank name:   Bank of Africa
Bank Address:Cotonou Benin Republic
Account name:Plaviashakunthala Lobo
Account Number:  1103-8022-1351
Account Balance: 16,000,000.00 British Pounds (GBP)
Date of deposit:  19th December, 2009
Account officer:  Anita Morgan
 
I was with Mr.Plaviashakunthala Lobo as a legal witness when this money was 
deposited as fixed deposit in 2009. Since his demise, I have visited this bank 
three times. Contact the bank and ask for the confirmation of his involvement 
in the plane crash.check the website:  
http://www.thehindu.com/news/national/list-of-passengers-on-air-india-express-flight/article435569.ece
 
Thanks
Attorney Peter Kono 
E-mail:   drkpy1...@barid.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 24/24] Add documentation about ARM64 ILP32 ABI

[Arnd Bergmann]

On Wednesday 03 September 2014 14:19:18 Andrew Pinski wrote:
> +This document describes the ILP32 syscall ABI and where it differs
> +from the generic linux syscall interface.
> +ILP32 sets __kernel_long_t and __kernel_ulong_t both to 64bit
> +(long long).  This effects the following types:
> +* time_t: unsigned long long
> +* clock_t: unsigned long long
> +* fsword_t: long long
> +* suseconds_t: long long
> +* swblk_t: long long
> +* fd_mask_t: long long

What about data structures derived from these? I'm worried that
some of them (in particular time_t) leak into ioctl interfaces
when they are getting included in some other data structure that
is used as an ioctl argument.

Do you have a list of which data structures change based on the
scalar type changes?

Arnd
--
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] x86: only load initrd above 4g on second try

[Matt Fleming]

On Wed, 03 Sep, at 09:50:07PM, Yinghai Lu wrote:
> Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
> loaded above 4G"), the kernel freezes at the earliest possible moment
> when trying to boot via UEFI on Asus laptop.
> 
> Revert to old way to load initrd under 4G on first try,
> second try will use above 4G buffer when initrd is too big
> and does not fit under 4G.
> 
> -v2: add print out for second try, and print out files buf address.
> -v3: can not snprintf
> -v4: drop address print out for files buf
> 
> Reported-by: Mantas Mikulėnas 
> Tested-by: Anders Darander 
> Signed-off-by: Yinghai Lu 
> 
> ---
>  arch/x86/boot/compressed/eboot.c |   18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)

Thanks, I've picked this up and expanded on the commit message because a
lot of useful information was discussed on the mailing list that we
should definitely include.

  
http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=urgent&id=b524e05df6d466af2f7eea1f044369109e48e641

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

Re: [PATCH 0/2] Add exit_prepare callback to the cpufreq_driver interface.

[Preeti U Murthy]

On 09/04/2014 02:46 PM, Viresh Kumar wrote:
> On 4 September 2014 14:40, Preeti U Murthy  wrote:
>> cpufreq: Allow stop CPU callback to be used by all cpufreq drivers
>>
>> Commit 367dc4aa introduced the stop CPU callback for intel_pstate
>> drivers. During the CPU_DOWN_PREPARE stage, this callback is invoked
>> so that drivers can take some action on the pstate of the cpu
>> before it is taken offline. This callback was assumed to be useful
>> only for those drivers which have implemented the set_policy CPU
>> callback because they have no other way to take action about the
>> cpufreq of a CPU which is being hotplugged out except in the exit
>> callback which is called very late in the offline process.
>>
>> The drivers which implement the target/target_index callbacks were
>> expected to take care of requirements like the ones that commit
>> 367dc4aa addresses in the GOV_STOP notification event. But there
>> are disadvantages to restricting the usage of stop CPU callback
>> to cpufreq drivers that implement the set_policy callbacks and who
>> want to take explicit action on the setting the cpufreq during a
>> hotplug operation.
>>
>> 1.GOV_STOP gets called for every CPU offline and drivers would usually
>>   want to take action when the last cpu in the policy->cpus mask
>>   is taken offline. As long as there is more than one cpu in the
>>   policy->cpus mask, cpufreq core itself makes sure that the freq
>>   for the other cpus in this mask is set according to the maximum load.
>>   This is sensible and drivers which implement the target_index callback
>>   would mostly not want to modify that. However the cpufreq core leaves a
>>   loose end when the cpu in the policy->cpus mask is the last one to go 
>> offline;
>>   it does nothing explicit to the frequency of the core. Drivers may need
>>   a way to take some action here and stop CPU callback mechanism is the
>>   best way to do it today.
>>
>> 2.We cannot implement driver specific actions in the GOV_STOP mechanism.
>>   So we will need another driver callback which is invoked from here which is
>>   unnecessary.
>>
>>   Therefore this patch extends the usage of stop CPU callback to be used
>>   by all cpufreq drivers as long as they have this callback implemented
>>   and irrespective of whether they are set_policy/target_index drivers.
>>   The assumption is if the drivers find the GOV_STOP path to be a suitable
>>   way of implementing what they want to do with the freq of the cpu
>>   going offine,they will not implement the stop CPU callback at all.
>>
>>   Signed-off-by: Preeti U Murthy 
>>
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>> index d9fdedd..6463f35 100644
>> --- a/drivers/cpufreq/cpufreq.c
>> +++ b/drivers/cpufreq/cpufreq.c
>> @@ -1380,7 +1380,7 @@ static int __cpufreq_remove_dev_prepare(struct device 
>> *dev,
>> if (!cpufreq_suspended)
>> pr_debug("%s: policy Kobject moved to cpu: %d from: 
>> %d\n",
>>  __func__, new_cpu, cpu);
>> -   } else if (cpufreq_driver->stop_cpu && cpufreq_driver->setpolicy) {
>> +   } else if (cpufreq_driver->stop_cpu) {
>> cpufreq_driver->stop_cpu(policy);
>> }
> 
> Rafael explicitly said earlier that he want to see a separate callback for
> ->target() drivers, don't know why..

I think Rafael's point was that since no driver that had implemented the
target_index callback was using it at the time that this patch was
proposed, it was be best to couple the check on existence of stop_cpu
callback with the the check on the kind of cpufreq driver. However
powerpc is also in need of this today and we implement the target_index
callback and find it convenient to use the stop CPU callback.

Rafael, in which case would it not make sense to remove the check on
driver->setpolicy above?

Besides, I don't understand very well why we had this double check in
the first place. Only if the drivers are in need of the functionality
like stop_cpu, would they have implemented this callback right? If we
are to assume that the drivers which have implemented the target_index
callback should never be needing it, they would not have implemented the
stop CPU callback either. So what was that, which was blatantly wrong
with just having a check on stop_cpu? I did go through the discussion
but did not find a convincing answer to this.

Rafael?

Regards
Preeti U Murthy

> 
> It looks fine to me though.
> 

--
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 v10 03/19] arm: fiq: Replace default FIQ handler

[Daniel Thompson]

On 04/09/14 10:45, Russell King - ARM Linux wrote:
> On Thu, Sep 04, 2014 at 10:09:20AM +0100, Daniel Thompson wrote:
>> On 03/09/14 20:34, Russell King - ARM Linux wrote:
>>> I would say that the ARM specific changes to entry-armv.S and setup.c
>>> are correct.  All that you're doing there is to replace the existing
>>> default no-op FIQ handler with some additional code which gets us into
>>> SVC mode and back out, but itself is also a no-op.  In other words, no
>>> real change.
>>>
>>> That's a good first patch, and one which I would actually like to have
>>> in my tree sooner rather than later, so that I can split that out from
>>> my prototype code.
>>
>> So would I!
>>
>> I did some rebasing yesterday to put anything to do with kgdb right at
>> the back of the queue. This "good first patch" is now actually the first
>> patch; where the nofifier used to be it currently calls do_unexp_fiq()
>> making it very close to "no real change".
>>
>> BTW do_unexp_fiq() calls printk() but
> 
> You're making the assumption that something called do_unexp_fiq() before
> your patches.  It seems that that function is dead code, and now that
> you've pointed that out, I will kill this function.
>
> The current situation is that if the CPU receives a FIQ, it enters the
> FIQ vector, which contains an immediate return instruction.

Actually it was the comment above the return instruction in the original
code about getting a message out that made me try to reconnect
do_unexp_fiq().

printk() has reasonably strong defences against being called twice by
the same CPU in that we ought to avoid deadlock if the current CPU owns
the printk locks (although the message would be dropped). I therefore
thought do_unexp_fiq() was a best-effort attempt to inform the user.

That said, assuming the FIQ re-enters, then without a rate limiter the
message will be rather insistent.

For now I will remove calls to do_unexp_fiq().


>> If you want me to work with something more recent then feel free to
>> point me at it...
> 
> I'll post some of that stuff later today, probably this evening.

Hopefully so shall I.

--
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] mfd: pcf50633: use sprintf directly

[Lee Jones]

On Thu, 04 Sep 2014, Andy Shevchenko wrote:

> When dump a content of the registers let's use snprintf() directly with %*ph
> specifier.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/pcf50633-core.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/pcf50633-core.c b/drivers/mfd/pcf50633-core.c
> index c87f7a0..8401552 100644
> --- a/drivers/mfd/pcf50633-core.c
> +++ b/drivers/mfd/pcf50633-core.c
> @@ -106,10 +106,7 @@ static ssize_t show_dump_regs(struct device *dev, struct 
> device_attribute *attr,
>   } else
>   dump[n1] = pcf50633_reg_read(pcf, n + n1);
>  
> - hex_dump_to_buffer(dump, sizeof(dump), 16, 1, buf1, 128, 0);
> - buf1 += strlen(buf1);
> - *buf1++ = '\n';
> - *buf1 = '\0';
> + buf1 += sprintf(buf1, "%*ph\n", (int)sizeof(dump), dump);
>   }
>  
>   return buf1 - buf;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/