Re: [net-next PATCH 0/8] Multiqueue API for macvtap

[David Miller]

From: Jason Wang 
Date: Thu,  6 Jun 2013 17:54:32 +0800

> This series implements a fully tuntap compatiable API which could be used
> by userspace to manage multiple macvtap queues. The main parts is to add
> TUNSETQUEUE ioctl support for macvtap.

Series applied, thanks everyone.
--
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] arch: x86: include: asm: need 'unsigned' type cast for atomic_clear_mask()

[Chen Gang]

atomic_set_mask() has already have 'unsigned' type case, and
atomic_clear_mask() is the pair of atomic_set_mask().

So it also need 'unsigned' type case.


Signed-off-by: Chen Gang 
---
 arch/x86/include/asm/atomic.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm/atomic.h
index 722aa3b..5b5cf52 100644
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -255,7 +255,7 @@ static inline void atomic_or_long(unsigned long *v1, 
unsigned long v2)
 /* These are x86-specific, used by some header files */
 #define atomic_clear_mask(mask, addr)  \
asm volatile(LOCK_PREFIX "andl %0,%1"   \
-: : "r" (~(mask)), "m" (*(addr)) : "memory")
+: : "r" (~(unsigned)(mask)), "m" (*(addr)) : "memory")
 
 #define atomic_set_mask(mask, addr)\
asm volatile(LOCK_PREFIX "orl %0,%1"\
-- 
1.7.7.6
--
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: [gentoo-dev] dm-crypt reordering BIOs across barriers?

[Sergei Trofimovich]

On Fri, 07 Jun 2013 23:47:33 -0400
Richard Yao  wrote:

> When you use dm-crypt, block IO requests to a dm-* device will invoke
> dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write
> barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(),
> which will immediately queue it to the device.
> 
> If a few dozen IOs are queued in rapid succession with multiple write
> barriers, all write barriers will be executed before any actual write
> BIOs occur because the write IOs will be processed asynchronously in a
> work queue. Since the barriers will be long gone by the time the write
> IOs are queued, they can be queued in any order.
> 
> Am I misunderstanding this or is dm-crypt ignoring proper write barrier
> semantics?
> 
http://www.saout.de/pipermail/dm-crypt/2012-April/002441.html
http://lwn.net/Articles/400541/

-- 

  Sergei


signature.asc
Description: PGP signature

Re: [RFC v1] add new io-scheduler to use cgroup on high-speed device

[sanbai]

On 2013-06-08- 11:50, sanbai wrote:

On 2013年06月08日 03:53, Vivek Goyal wrote:

On Fri, Jun 07, 2013 at 11:09:54AM +0800, sanbai wrote:

On 2013年06月05日 21:30, Vivek Goyal wrote:

On Wed, Jun 05, 2013 at 10:09:31AM +0800, Robin Dong wrote:
We want to use blkio.cgroup on high-speed device (like fusionio) 
for our mysql clusters.
After testing different io-scheduler, we found that  cfq is too 
slow and deadline can't run on cgroup.
So why not enhance deadline to be able to be used with cgroups 
instead of

coming up with a new scheduler?

I think if we add cgroups support into deadline, it will not be
suitable to call "deadline" anymore...so a new ioscheduler and a new
name may not confuse users.

Nobody got confused when we added cgroup support to CFQ. Not that
I am saying go add support to deadline. I am just saying that need
for cgroup support does not sound like it justfies need of a new
IO scheduler.

[..]
Can you give more details. Do you idle? Idling kills performance. 
If not,

then without idling how do you achieve performance differentiation.

We don't idle, when comes to .elevator_dispatch_fn，we just compute
quota for every group:

quota = nr_requests - rq_in_driver;
group_quota = quota * group_weight / total_weight;

and dispatch 'group_quota' requests for the coordinate group.
Therefore high-weight group
will dispatch more requests than low-weight group.

Ok, this works only if all the groups are full all the time otherwise
groups will lose their fair share. This simplifies the things a lot.
That is fairness is provided only if group is always backlogged. In
practice, this happens only if a group is doing IO at very high rate
(like your fio scripts). Have you tried running any real life workload
in these cgroups (apache, databases etc) and see how good is service
differentiation.

Anyway, sounds like this can be done at generic block layer like
blk-throtl and it can sit on top so that it can work with all schedulers
and can also work with bio based block drivers.

That's a new idea, I will give a try later.


[..]

I do the test again for cfq (slice_idle=0, quatum=128) and tpps

cfq (slice_idle=0, quatum=128)
groupname iops avg-rt(ms) max-rt(ms)
test1 16148 15 188
test2 12756 20 117
test3 9778 26 268
test4 6198 41 209

tpps
groupname iops avg-rt(ms) max-rt(ms)
test1 17292 14 65
test2 15221 16 80
test3 12080 21 66
test4 7995 32 90

Looks cfq with is much better than before.

Yep, I am sure there are more simple opportunites for optimization
where it can help. Can you try couple more things.

- Drive even deeper queue depth. Set quantum=512.

- set group_idle=0.

I changed the iodepth to 512 in fio script and the new result is:

cfq (group_idle=0, quantum=512)
groupnameiopsavg-rt(ms)   max-rt(ms)
test1   1525933305
test2   1185842345
test3   8885  57335
test4   5738  89355

cfq (group_idle=0, quantum=512, slice_sync=10)
groupnameiopsavg-rt(ms)   max-rt(ms)
test1   1650731177
test2   1289639366
test3   9301  55188
test4   6023  84545

tpps
groupnameiopsavg-rt(ms)   max-rt(ms)
test1   163163199
test2   1506633106
test3   1218242101
test4   8350  61180

looks cfq works much better now.


But after I changed to 'randrw', the condition is a little different:

cfq (group_idle=0, quantum=512, slice_sync=10,slice_async=10)
groupnameiops(r/w)avg-rt(ms)   max-rt(ms)
test1   8717/872626/31   553/576
test2   6944/694334/39   507/514
test3   4974/496149/53   725/658
test4   3117/310979/84   1107/1094

tpps
groupnameiops(r/w)avg-rt(ms)max-rt(ms)
test1   9130/914725/3085/98
test2   7644/765230/36103/118
test3   5727/573341/47   132/146
test4   3889/389162/68   193/214


   Ideally this should effectively emulate what you are doing. That 
is try

   to provide fairness without idling on group.

   In practice I could not keep group queue full and before group 
exhausted
   its slice, it got empty and got deleted from service tree and lost 
its

   fair share. So if group_idle=0 leads to no service differentiation,
   try slice_sync=10 and see what happens.

Thanks
Vivek






--

Robin Dong

email：san...@taobao.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 v2] arm64: kernel: compiling issue, need delete read_current_timer().

[Chen Gang]

Hello Maintainers:

Please help check it, when you have time.

Thanks.

On 05/27/2013 06:02 PM, Chen Gang wrote:
> Hello Maintainers:
> 
> Please help check this patch whether OK, when you have time.
> 
> Thanks.
> 
> On 05/21/2013 05:46 PM, Chen Gang wrote:
>>
>> Under arm64, we will calibrate the delay loop statically using a known
>> timer frequency, so delete read_current_timer(), or it will cause
>> compiling issue with allmodconfig.
>>
>> The related error:
>>   ERROR: "read_current_timer" [lib/rbtree_test.ko] undefined!
>>   ERROR: "read_current_timer" [lib/interval_tree_test.ko] undefined!
>>   ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
>>   ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
>>
>>
>> Signed-off-by: Chen Gang 
>> ---
>>  arch/arm64/include/asm/timex.h |6 +++---
>>  arch/arm64/kernel/time.c   |6 --
>>  2 files changed, 3 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/timex.h b/arch/arm64/include/asm/timex.h
>> index b24a31a..81a076e 100644
>> --- a/arch/arm64/include/asm/timex.h
>> +++ b/arch/arm64/include/asm/timex.h
>> @@ -16,14 +16,14 @@
>>  #ifndef __ASM_TIMEX_H
>>  #define __ASM_TIMEX_H
>>  
>> +#include 
>> +
>>  /*
>>   * Use the current timer as a cycle counter since this is what we use for
>>   * the delay loop.
>>   */
>> -#define get_cycles()({ cycles_t c; read_current_timer(&c); c; })
>> +#define get_cycles()arch_counter_get_cntvct()
>>  
>>  #include 
>>  
>> -#define ARCH_HAS_READ_CURRENT_TIMER
>> -
>>  #endif
>> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
>> index a551f88..03dc371 100644
>> --- a/arch/arm64/kernel/time.c
>> +++ b/arch/arm64/kernel/time.c
>> @@ -68,12 +68,6 @@ unsigned long long notrace sched_clock(void)
>>  return arch_timer_read_counter() * sched_clock_mult;
>>  }
>>  
>> -int read_current_timer(unsigned long *timer_value)
>> -{
>> -*timer_value = arch_timer_read_counter();
>> -return 0;
>> -}
>> -
>>  void __init time_init(void)
>>  {
>>  u32 arch_timer_rate;
>>
> 
> 


-- 
Chen Gang

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

Re: Linux 3.9.5

[Guenter Roeck]

On Fri, Jun 07, 2013 at 12:58:16PM -0700, Greg KH wrote:
> I'm announcing the release of the 3.9.5 kernel.
> 
> All users of the 3.9 kernel series must upgrade.
> 
> The updated 3.9.y git tree can be found at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
> linux-3.9.y
> and can be browsed at the normal kernel.org git web browser:
>   
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
> 
> thanks,
> 
> greg k-h
> 
powerpc build fails:

arch/powerpc/kernel/traps.c: In function 'alignment_exception':
arch/powerpc/kernel/traps.c:1154:3: error: label 'bail' used but not defined
make[1]: *** [arch/powerpc/kernel/traps.o] Error 1
make[1]: *** Waiting for unfinished jobs

Due to commit 6ce6c629 (powerpc/tm: Abort on emulation and alignment faults).

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

Re: [RFC v1] add new io-scheduler to use cgroup on high-speed device

[sanbai]

On 2013年06月08日 03:53, Vivek Goyal wrote:

On Fri, Jun 07, 2013 at 11:09:54AM +0800, sanbai wrote:

On 2013年06月05日 21:30, Vivek Goyal wrote:

On Wed, Jun 05, 2013 at 10:09:31AM +0800, Robin Dong wrote:

We want to use blkio.cgroup on high-speed device (like fusionio) for our mysql 
clusters.
After testing different io-scheduler, we found that  cfq is too slow and 
deadline can't run on cgroup.

So why not enhance deadline to be able to be used with cgroups instead of
coming up with a new scheduler?

I think if we add cgroups support into deadline, it will not be
suitable to call "deadline" anymore...so a new ioscheduler and a new
name may not confuse users.

Nobody got confused when we added cgroup support to CFQ. Not that
I am saying go add support to deadline. I am just saying that need
for cgroup support does not sound like it justfies need of a new
IO scheduler.

[..]

Can you give more details. Do you idle? Idling kills performance. If not,
then without idling how do you achieve performance differentiation.

We don't idle, when comes to .elevator_dispatch_fn，we just compute
quota for every group:

quota = nr_requests - rq_in_driver;
group_quota = quota * group_weight / total_weight;

and dispatch 'group_quota' requests for the coordinate group.
Therefore high-weight group
will dispatch more requests than low-weight group.

Ok, this works only if all the groups are full all the time otherwise
groups will lose their fair share. This simplifies the things a lot.
That is fairness is provided only if group is always backlogged. In
practice, this happens only if a group is doing IO at very high rate
(like your fio scripts). Have you tried running any real life workload
in these cgroups (apache, databases etc) and see how good is service
differentiation.

Anyway, sounds like this can be done at generic block layer like
blk-throtl and it can sit on top so that it can work with all schedulers
and can also work with bio based block drivers.

That's a new idea, I will give a try later.
   


[..]

I do the test again for cfq (slice_idle=0, quatum=128) and tpps

cfq (slice_idle=0, quatum=128)
groupname iops avg-rt(ms) max-rt(ms)
test1 16148 15 188
test2 12756 20 117
test3 9778 26 268
test4 6198 41 209

tpps
groupname iops avg-rt(ms) max-rt(ms)
test1 17292 14 65
test2 15221 16 80
test3 12080 21 66
test4 7995 32 90

Looks cfq with is much better than before.

Yep, I am sure there are more simple opportunites for optimization
where it can help. Can you try couple more things.

- Drive even deeper queue depth. Set quantum=512.

- set group_idle=0.

I changed the iodepth to 512 in fio script and the new result is:

cfq (group_idle=0, quantum=512)
groupnameiopsavg-rt(ms)   max-rt(ms)
test1   1525933305
test2   1185842345
test3   8885  57335
test4   5738  89355

cfq (group_idle=0, quantum=512, slice_sync=10)
groupnameiopsavg-rt(ms)   max-rt(ms)
test1   1650731177
test2   1289639366
test3   9301  55188
test4   6023  84545

tpps
groupnameiopsavg-rt(ms)   max-rt(ms)
test1   163163199
test2   1506633106
test3   1218242101
test4   8350  61180

looks cfq works much better now.


   Ideally this should effectively emulate what you are doing. That is try
   to provide fairness without idling on group.

   In practice I could not keep group queue full and before group exhausted
   its slice, it got empty and got deleted from service tree and lost its
   fair share. So if group_idle=0 leads to no service differentiation,
   try slice_sync=10 and see what happens.

Thanks
Vivek



--

Robin Dong
董昊（花名：三百）
阿里巴巴 集团 核心系统部 内核组
分机：72370
手机：13520865473
email：san...@taobao.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/

dm-crypt reordering BIOs across barriers?

[Richard Yao]

When you use dm-crypt, block IO requests to a dm-* device will invoke
dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write
barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(),
which will immediately queue it to the device.

If a few dozen IOs are queued in rapid succession with multiple write
barriers, all write barriers will be executed before any actual write
BIOs occur because the write IOs will be processed asynchronously in a
work queue. Since the barriers will be long gone by the time the write
IOs are queued, they can be queued in any order.

Am I misunderstanding this or is dm-crypt ignoring proper write barrier
semantics?



signature.asc
Description: OpenPGP digital signature

Attention

[LEE YONG]

My name is Lee Yong, Contact me for more information about a later client of 
mine that bears the same last name as yours leaving behind some funds.
--
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/7] irq: fix checkpatch errors and warnings

[Kefeng Wang]

On 2013-06-08 6:24, Joe Perches wrote:
> On Fri, 2013-06-07 at 22:42 +0200, Thomas Gleixner wrote:
>> On Thu, 6 Jun 2013, Kefeng Wang wrote:
>>
>>> Fix all the checkpath errors in kernel/irq dir, and some warnings
>>> also fixed.
>>
>> Sorry, I'm not really interested in this kind of patches. To be
>> honest, it would be way more exciting if you had taught checkpatch to
>> actually fix the missing space after the comma.
> 
> Yup.  Kefeng, if you want to take that up,
> I'd be happy to help/guide you.
> 
>> Aside of that your mechanical fixups are mostly making the code worse
>> to read. Just a few examples:
>>
>> --- linux-2.6.orig/kernel/irq/chip.c
> []
>> struct irq_desc *desc = irq_get_desc_buslock(irq, &flags,
>>  
>> IRQ_GET_DESC_CHECK_GLOBAL);
>>
>> Aligning the first arguments of the first and the second line makes it
>> way simpler to read.
> 
> or maybe use
> 
>   struct irq_desc *desc =
>   irq_get_desc_buslock(irq, &flags, IRQ_GET_DESC_CHECK_GLOBAL);
> 
> and satisfy 80 cols too.
> 
> Existing uses that exceed the 80 column text limit shouldn't
> be changed without making other useful changes at the same
> time.  Make 80 column changes as part of a larger patch set,
> 
>> --- linux-2.6.orig/kernel/irq/handle.c
> []
>> @@ -47,7 +47,7 @@ static void warn_no_thread(unsigned int 
> 
>> -   printk(KERN_WARNING "IRQ %d device %s returned IRQ_WAKE_THREAD "
>> +   pr_warn("IRQ %d device %s returned IRQ_WAKE_THREAD "
>>"but no thread function available.", irq, action->name);
> 
> It'd be useful to add a terminating \n though to avoid
> interleaving by other thread pr_cont/naked printks.
> 
>> The checkpatch warning is to prevent new code to use the old style
>> printk format, but it's not intended to force that on existing code.
> 
> Yup, and checkpatch will never be a perfect tool.
> 
>> Please sit down and read and understand the code and try to find real
>> issues which cannot be detected and solved by scripts and
>> tools. That's what's kernel hacking is about. You are not becoming a
>> kernel developer by running tools and blindly fixing the complaints of
>> the tools. You have to understand the code and you have to learn to
>> judge the output of tools.
> 
> Quite right.
> 
> Maybe add something like it to SubmittingPatches in
> Section 2 ala:
> 
> 5) "Don't be a checkpatch monkey - How not to write patches"
> 

hi Thomas and Joe， thank very much for your reply and remind,
I will pay more attention to study kernel， like your said,
read more code and be an good kernel developer.

thanks,
kefeng


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

[PATCH] KVM: x86: fix missed memory synchronization when patch hypercall

[Xiao Guangrong]

From: Xiao Guangrong 

Currently, memory synchronization is missed in emulator_fix_hypercall,
please see the commit 758ccc89b83
(KVM: x86: drop calling kvm_mmu_zap_all in emulator_fix_hypercall)

This patch fixes it by introducing kvm_vcpus_hang_on_page_start() and
kvm_vcpus_hang_on_page_end which unmap the patched page from guest
and use kvm_flush_remote_tlbs() as the serializing instruction to
ensure the memory coherence
[ The SDM said that INVEPT, INVVPID and MOV (to control register, with
  the exception of MOV CR8) are the serializing instructions. ]

The mmu-lock is held during host patches the page so that it stops vcpus
to fix its further page fault

Signed-off-by: Xiao Guangrong 
---
 arch/x86/kvm/mmu.c | 25 +
 arch/x86/kvm/mmu.h |  3 +++
 arch/x86/kvm/x86.c |  7 +++
 3 files changed, 35 insertions(+)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7d50a2d..35cd0b6 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4536,6 +4536,31 @@ int kvm_mmu_get_spte_hierarchy(struct kvm_vcpu *vcpu, 
u64 addr, u64 sptes[4])
 }
 EXPORT_SYMBOL_GPL(kvm_mmu_get_spte_hierarchy);

+/*
+ * Force vcpu to hang when it is trying to access the specified page.
+ *
+ * kvm_vcpus_hang_on_page_start and kvm_vcpus_hang_on_page_end should
+ * be used in pairs and they are currently used to sync memory access
+ * between vcpus when host cross-modifies the code segment of guest.
+ *
+ * We unmap the page from the guest and do memory synchronization by
+ * kvm_flush_remote_tlbs() under the protection of mmu-lock. If vcpu
+ * accesses the page, it will trigger #PF and be blocked on mmu-lock.
+ */
+void kvm_vcpus_hang_on_page_start(struct kvm *kvm, gfn_t gfn)
+{
+   spin_lock(&kvm->mmu_lock);
+
+   /* kvm_flush_remote_tlbs() can act as serializing instruction. */
+   if (kvm_unmap_hva(kvm, gfn_to_hva(kvm, gfn)))
+   kvm_flush_remote_tlbs(kvm);
+}
+
+void kvm_vcpus_hang_on_page_end(struct kvm *kvm)
+{
+   spin_unlock(&kvm->mmu_lock);
+}
+
 void kvm_mmu_destroy(struct kvm_vcpu *vcpu)
 {
ASSERT(vcpu);
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index 5b59c57..35910be 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -115,4 +115,7 @@ static inline bool permission_fault(struct kvm_mmu *mmu, 
unsigned pte_access,
 }

 void kvm_mmu_invalidate_zap_all_pages(struct kvm *kvm);
+
+void kvm_vcpus_hang_on_page_start(struct kvm *kvm, gfn_t gfn);
+void kvm_vcpus_hang_on_page_end(struct kvm *kvm);
 #endif
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 9e4afa7..776bf1a 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5528,8 +5528,15 @@ static int emulator_fix_hypercall(struct 
x86_emulate_ctxt *ctxt)
struct kvm_vcpu *vcpu = emul_to_vcpu(ctxt);
char instruction[3];
unsigned long rip = kvm_rip_read(vcpu);
+   gpa_t gpa;
+
+   gpa = kvm_mmu_gva_to_gpa_fetch(vcpu, rip, NULL);
+   if (gpa == UNMAPPED_GVA)
+   return X86EMUL_PROPAGATE_FAULT;

+   kvm_vcpus_hang_on_page_start(vcpu->kvm, gpa_to_gfn(gpa));
kvm_x86_ops->patch_hypercall(vcpu, instruction);
+   kvm_vcpus_hang_on_page_end(vcpu->kvm);

return emulator_write_emulated(ctxt, rip, instruction, 3, NULL);
 }
-- 
1.8.1.4

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

Re: [PATCH RFC 0/3] clk: dt: bindings for mux & divider clocks

[Shawn Guo]

On Fri, Jun 07, 2013 at 10:52:54AM -0700, Mike Turquette wrote:
> Yes, there was a time when I was firmly against doing such a thing.
> However I'm not sure it is so bad now.  More and more SoCs are going to
> keep getting merged into the kernel and that just means more and more
> clock data.  Perhaps DT is best suited to handle this bloat.  I broke
> the clock data out into a separate file so that it didn't overwhelm the
> existing omap4.dtsi.

I'm actually more concerned by run-time impact.  Any of_find_node_*()
call will possibly have to scan all those hundreds of nodes to find the
desired one.  Anyway, it's an OMAP folks decision, and the impact might
not be that much on those fast CPUs.

Shawn

> 
> Either way I marked this series as RFC precisely due to your point.  I
> want feedback on how the OMAP folks feel about this.  So far no has has
> NACKed it ;-)

--
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 V3 0/2] x86/microcode/amd: early loading fixes

[Jacob Shin]

This patchset addreses two problems with early loading on AMD.

First, feedback from Yinghai that find_ucode_in_initrd() should be
marked __init:
  https://lkml.org/lkml/2013/6/4/695

And second, feedback from Henrique that Intel early loading supports
multiple microcode firmware concatenated together, whereas the current
AMD implementation lacks this support:
  https://lkml.org/lkml/2013/5/31/4

V3:
* style fix -- reduce multiple if statements into a single one

V2:
* test for !initrd_start before using it
* use __pa() instead of __pa_nodebug() on AP load
* fixed calculation of start offset and size of the microcode container file

Jacob Shin (2):
  x86/microcode/amd: make find_ucode_in_initrd() __init
  x86/microcode/amd: allow multiple families' bin files appended
together

 arch/x86/kernel/microcode_amd_early.c |  170 -
 1 file changed, 125 insertions(+), 45 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: [patch 0/9] sched: use runnable load avg in balance

[Alex Shi]

On 06/07/2013 03:20 PM, Alex Shi wrote:
> Peter&Ingo:
> 
> v8: add a marco div64_ul and used it in task_h_load()
> v7: rebasing on tip/sched/core tree.

Peter & Ingo:

IMHO, if the patch set missed in 3.11 kernel. We will lose the following
widely benefit on many benchmarks, hackbench, pgbench, sysbench,
anonymous java load ...

What's your opinions? :)

> 
> I tested on Intel core2, NHM, SNB, IVB, 2 and 4 sockets machines with
> benchmark kbuild, aim7, dbench, tbench, hackbench, oltp, and netperf
> loopback etc. 
> 
> On SNB EP 4 sockets machine, the hackbench increased about 50%, and
> result become stable. on other machines, hackbench increased about
> 2~10%. oltp increased about 30% in NHM EX box. netperf loopback also
> increased on SNB EP 4 sockets box. 
> No clear changes on other benchmarks.
> 
> Michael Wang gotten better performance on pgbench on his box with this
> patchset. https://lkml.org/lkml/2013/5/16/82
> 
> And Morten tested previous version with better power consumption.
> http://comments.gmane.org/gmane.linux.kernel/1463371
> 
> Changlong found ltp cgroup stress testing get faster on SNB EP
> machine with the last patch.  https://lkml.org/lkml/2013/5/23/65
> ---
> 3.10-rc1  patch1-7 patch1-8
> duration=764   duration=754   duration=750
> duration=764   duration=754   duration=751
> duration=763   duration=755   duration=751
> 
> duration means the seconds of testing cost.
> ---
> 
> Jason also found java server load benefited on his 8 sockets machine
> with last patch. https://lkml.org/lkml/2013/5/29/673
> ---
> When using a 3.10-rc2 tip kernel with patches 1-8, there was about a 40%
> improvement in performance of the workload compared to when using the
> vanilla 3.10-rc2 tip kernel with no patches. When using a 3.10-rc2 tip
> kernel with just patches 1-7, the performance improvement of the
> workload over the vanilla 3.10-rc2 tip kernel was about 25%.
> ---
> 
> We also tried to include blocked load avg in balance. but find many
> benchmark performance drop a lot! Seems accumulating current
> blocked_load_avg into cpu load isn't a good idea. Because:
> 1, The blocked_load_avg is decayed same as runnable load, sometime is far
> bigger than runnable load, that drive tasks to other idle or slight
> load cpu, than cause both performance and power issue. But if the
> blocked load is decayed too fast, it lose its effect. 
> 2, Another issue of blocked load is that when waking up task, we can not 
> know blocked load proportion of the task on rq. So, the blocked load is
> meaningless in wake affine decision.  
> 
> According to above problem, we can not figure out a right way now to use 
> blocked_load_avg in balance.
> 
> Since using runnable load avg in balance brings much benefit on
> performance and power. and this patch was reviewed for long time.
> So seems it's time to let it be clobbered in some sub tree, like 
> tip or linux-next.  Any comments?
> 
> Regards
> Alex
> 


-- 
Thanks
Alex
--
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] Run callback of device_prepare/complete consistently

[Yanmin Zhang]

On Sat, 2013-06-08 at 03:52 +0200, Rafael J. Wysocki wrote:
> On Saturday, June 08, 2013 09:36:03 AM Yanmin Zhang wrote:
> > On Sat, 2013-06-08 at 03:30 +0200, Rafael J. Wysocki wrote:
> > > On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
> > > > On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> > > > > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > > > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > > > > dpm_run_callback is used in other stages of power states changing.
> > > > > > > It provides debug info message and time measurement when call 
> > > > > > > these
> > > > > > > callback. We also want to benefit ->prepare and ->complete.
> > > > > > > 
> > > > > > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > > > > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in 
> > > > > > > device_complete
> > > > > > 
> > > > > > Is this an "Oh, why don't we do that?" series, or is it useful for 
> > > > > > anything
> > > > > > in practice?  I'm asking, because we haven't added that stuff to 
> > > > > > start with
> > > > > > since we didn't see why it would be useful to anyone.
> > > > > > 
> > > > > > And while patch [1/2] reduces the code size (by 1 line), so I can 
> > > > > > see some
> > > > > > (tiny) benefit from applying it, patch [2/2] adds more code and is 
> > > > > > there any
> > > > > > paractical reason?
> > > > > Sometimes, suspend-to-ram path spends too much time (either suspend 
> > > > > slowly
> > > > > or wakeup slowly) and we need optimize it.
> > > > > With the 2 patches, we could collect initcall_debug printk info and 
> > > > > manually
> > > > > check what prepare/complete callbacks consume too much time.
> > > > 
> > > > But initcall information is for initialization stuff, not suspend/resume
> > > > things, right?  Doesn't the existing tools for parsing this choke if it
> > > > sees the information at suspend/resume time?
> > > 
> > > We've been using that for suspend/resume for quite some time too, but not
> > > for the prepare/complete phases (because we still believe that's not 
> > > really
> > > useful for them). 
> > > 
> > > Well, I'll be handling patches changing code under drivers/base/power,
> > > I promise. :-)
> > > 
> > > I've been doing that for quite a few years now ...
> > Yes, indeed. Power is one of the most important features on embedded 
> > devices.
> > Lots of smart phones don't really go through the full cycles of 
> > suspend-to-ram.
> > We are following the full steps of the suspend.
> 
> But if you go through the code, you'll see that alomost no drivers actually
> implemet .prepare() and .complete().  Some subsystems do, but they really 
> don't
> take too much time to execute.  Which means that your patches with
> initcall_debug will add quite a pile of useless garbage to the kernel log
Does that mean we need add more log levels around such info instead of just 
having or
not having?

Yanmin


--
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] irq: add a new function irq_in_progress to check pending IRQ handlers

[Yanmin Zhang]

On Fri, 2013-06-07 at 08:08 -0700, Greg KH wrote:
> On Fri, Jun 07, 2013 at 12:54:55PM +0800, Yanmin Zhang wrote:
> > On Thu, 2013-06-06 at 21:19 -0700, Greg KH wrote:
> > > On Fri, Jun 07, 2013 at 11:18:06AM +0800, Yanmin Zhang wrote:
> > > > On Thu, 2013-06-06 at 20:08 -0700, Greg KH wrote:
> > > > > On Fri, Jun 07, 2013 at 10:37:52AM +0800, Yanmin Zhang wrote:
> > > > > > On Thu, 2013-06-06 at 18:02 -0700, Greg KH wrote:
> > > > > > > On Fri, Jun 07, 2013 at 08:53:29AM +0800, Yanmin Zhang wrote:
> > > > > > > > On Thu, 2013-06-06 at 15:18 +0200, Thomas Gleixner wrote:
> > > > > > > > > On Thu, 6 Jun 2013, shuox@intel.com wrote:
> > > > > > > > > > From: Zhang Yanmin 
> > > > > > > > > > 
> > > > > > > > > > synchronize_irq waits pending IRQ handlers to be finished. 
> > > > > > > > > > If using this
> > > > > > > > > > function while holding a resource, the IRQ handler may 
> > > > > > > > > > cause deadlock.
> > > > > > > > > > 
> > > > > > > > > > Here we add a new function irq_in_progress which doesn't 
> > > > > > > > > > wait for the handlers
> > > > > > > > > > to be finished.
> > > > > > > > > > 
> > > > > > > > > > A typical use case at suspend-to-ram:
> > > > > > > > > > 
> > > > > > > > > > device driver's irq handler is complicated and might hold a 
> > > > > > > > > > mutex at rare cases.
> > > > > > > > > > Its suspend function is called and a suspended flag is set.
> > > > > > > > > > In case its IRQ handler is running, suspend function calls 
> > > > > > > > > > irq_in_progress. if
> > > > > > > > > > handler is running, abort suspend.
> > > > > > > > > > The irq handler checks the suspended flag. If the device is 
> > > > > > > > > > suspended, irq handler
> > > > > > > > > > either ignores the interrupt, or wakes up the whole system, 
> > > > > > > > > > and the driver's
> > > > > > > > > > resume function could deal with the delayed interrupt 
> > > > > > > > > > handling.
> > > > > > > > > 
> > > > > > > > > This is as wrong as it can be. Fix the driver instead of 
> > > > > > > > > hacking racy
> > > > > > > > > functions into the core code.
> > > > > > > > > 
> > > > > > > > > So your problem looks like this:
> > > > > > > > > 
> > > > > > > > > CPU 0 CPU 1
> > > > > > > > > irq_handler_thread()  suspend()
> > > > > > > > >.  mutex_lock(&m);
> > > > > > > > >mutex_lock(&m);synchronize_irq();
> > > > > > > > > 
> > > > > > > > > So why needs the mutex to be taken before synchronize_irq()? 
> > > > > > > > > Why not
> > > > > > > > > doing the obvious?
> > > > > > > > > 
> > > > > > > > > suspend()
> > > > > > > > >   disable_irq(); (Implies synchronize_irq)
> > > > > > > > >   mutex_lock(&m);
> > > > > > > > >   
> > > > > > > > >   mutex_unlock(&m);
> > > > > > > > >   enable_irq();
> > > > > > > > Thanks for the kind comment.
> > > > > > > > 
> > > > > > > > We do consider your solution before and it works well indeed 
> > > > > > > > with some specific
> > > > > > > > simple drivers. For example, some drives use GPIO pin as 
> > > > > > > > interrupt source.
> > > > > > > > 
> > > > > > > > On one specific platform, disable_irq would really disable the 
> > > > > > > > irq at RTE entry,
> > > > > > > > which means we lose the wakeup capability of this device.
> > > > > > > > synchronize_irq can be another solution. But we did hit 'DPM 
> > > > > > > > device timeout' issue
> > > > > > > > reported by dpm_wd_handler at suspend-to-ram.
> > > > > > > > 
> > > > > > > > The driver is complicated. We couldn't change too many 
> > > > > > > > functions to optimize it.
> > > > > > > > In addition, we have to use the driver instead of throwing it 
> > > > > > > > away.
> > > > > > > 
> > > > > > > What is preventing you from rewriting it to work properly?
> > > > > > It's complicated.
> > > > > 
> > > > > That sounds like your issue, not ours, so please don't push the 
> > > > > problem
> > > > > onto someone else.  Take ownership of the driver, fix it up, and all
> > > > > will be good.
> > > > > 
> > > > > 
> > > > > > > > With irq_in_progress, we can resolve this issue and it does 
> > > > > > > > work, although it
> > > > > > > > looks like ugly.
> > > > > > > 
> > > > > > > Don't paper over driver bugs in the core kernel, fix the driver.
> > > > > > It's hard to say it's a driver bug. Could generic kernel provide 
> > > > > > some
> > > > > > flexibility for such complicated drivers?
> > > > > 
> > > > > Please post the code for the driver, and then we will be glad to
> > > > > continue the dicussion.
> > > > Greg,
> > > > 
> > > > Thanks for your enthusiasm. It's a private driver for products.
> > > 
> > > What do you mean "private driver"?  All drivers need to be merged into
> > > the mainline kernel, it saves you time and money, and we will fix your
> > > bugs for you.
> > > 
> > > You know that, your bosses know that, your management knows that, so why
> > > are you trying to hide things?
> > > 
>

[PATCH V3 2/2] x86/microcode/amd: allow multiple families' bin files appended together

[Jacob Shin]

Add support for parsing through multiple families' microcode patch
container binary files appended together when early loading. This is
already supported on Intel.

Reported-by: Henrique de Moraes Holschuh 
Signed-off-by: Jacob Shin 
---
 arch/x86/kernel/microcode_amd_early.c |   68 +++--
 1 file changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/microcode_amd_early.c 
b/arch/x86/kernel/microcode_amd_early.c
index c783248..1ac6e9a 100644
--- a/arch/x86/kernel/microcode_amd_early.c
+++ b/arch/x86/kernel/microcode_amd_early.c
@@ -87,15 +87,21 @@ static void __cpuinit apply_ucode_in_initrd(void *ucode, 
size_t size)
struct equiv_cpu_entry *eq;
u32 *header;
u8  *data;
-   u16 eq_id;
+   u16 eq_id = 0;
int offset, left;
-   u32 rev, dummy;
+   u32 rev, eax;
u32 *new_rev;
+   unsigned long *uoffset;
+   size_t *usize;
 
 #ifdef CONFIG_X86_32
new_rev = (u32 *)__pa_nodebug(&ucode_new_rev);
+   uoffset = (unsigned long *)__pa_nodebug(&ucode_offset);
+   usize   = (size_t *)__pa_nodebug(&ucode_size);
 #else
new_rev = &ucode_new_rev;
+   uoffset = &ucode_offset;
+   usize   = &ucode_size;
 #endif
 
data   = ucode;
@@ -108,18 +114,50 @@ static void __cpuinit apply_ucode_in_initrd(void *ucode, 
size_t size)
header[2] == 0)/* size */
return;
 
-   eq = (struct equiv_cpu_entry *)(data + CONTAINER_HDR_SZ);
-   offset = header[2] + CONTAINER_HDR_SZ;
-   data  += offset;
-   left  -= offset;
+   eax = cpuid_eax(0x0001);
+
+   while (left > 0) {
+   eq = (struct equiv_cpu_entry *)(data + CONTAINER_HDR_SZ);
+
+   offset = header[2] + CONTAINER_HDR_SZ;
+   data  += offset;
+   left  -= offset;
 
-   eq_id  = find_equiv_id(eq, cpuid_eax(0x0001));
-   if (!eq_id)
+   eq_id = find_equiv_id(eq, eax);
+   if (eq_id)
+   break;
+
+   /*
+* support multiple container files appended together. if this
+* one does not have a matching equivalent cpu entry, we fast
+* forward to the next container file.
+*/
+   while (left > 0) {
+   header = (u32 *)data;
+   if (header[0] == UCODE_MAGIC &&
+   header[1] == UCODE_EQUIV_CPU_TABLE_TYPE)
+   break;
+
+   offset = header[1] + SECTION_HDR_SIZE;
+   data  += offset;
+   left  -= offset;
+   }
+
+   /* mark where the next microcode container file starts */
+   offset= data - (u8 *)ucode;
+   *uoffset += offset;
+   *usize   -= offset;
+   ucode = data;
+   }
+
+   if (!eq_id) {
+   *usize = 0;
return;
+   }
 
/* find ucode and update if needed */
 
-   rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy);
+   rdmsr(MSR_AMD64_PATCH_LEVEL, rev, eax);
 
while (left > 0) {
struct microcode_amd *mc;
@@ -132,15 +170,21 @@ static void __cpuinit apply_ucode_in_initrd(void *ucode, 
size_t size)
mc = (struct microcode_amd *)(data + SECTION_HDR_SIZE);
if (eq_id == mc->hdr.processor_rev_id && rev < mc->hdr.patch_id)
if (__apply_microcode_amd(mc) == 0) {
-   if (!(*new_rev))
-   *new_rev = mc->hdr.patch_id;
-   break;
+   rev = mc->hdr.patch_id;
+   *new_rev = rev;
}
 
offset  = header[1] + SECTION_HDR_SIZE;
data   += offset;
left   -= offset;
}
+
+   /* mark where this microcode container file ends */
+   offset  = *usize - (data - (u8 *)ucode);
+   *usize -= offset;
+
+   if (!(*new_rev))
+   *usize = 0;
 }
 
 void __init load_ucode_amd_bsp(void)
-- 
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 V3 1/2] x86/microcode/amd: make find_ucode_in_initrd() __init

[Jacob Shin]

Change find_ucode_in_initrd() to __init and only let BSP call it
during cold boot. This is the right thing to do because only BSP will
see initrd loaded by the boot loader. APs will offset into
initrd_start to find the microcode patch binary.

Reported-by: Yinghai Lu 
Signed-off-by: Jacob Shin 
---
 arch/x86/kernel/microcode_amd_early.c |  102 ++---
 1 file changed, 69 insertions(+), 33 deletions(-)

diff --git a/arch/x86/kernel/microcode_amd_early.c 
b/arch/x86/kernel/microcode_amd_early.c
index 9618805..c783248 100644
--- a/arch/x86/kernel/microcode_amd_early.c
+++ b/arch/x86/kernel/microcode_amd_early.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 
 #include 
 #include 
@@ -16,40 +17,59 @@
 
 static bool ucode_loaded;
 static u32 ucode_new_rev;
+static unsigned long ucode_offset;
+static size_t ucode_size;
 
 /*
  * Microcode patch container file is prepended to the initrd in cpio format.
  * See Documentation/x86/early-microcode.txt
  */
-static __cpuinitdata char ucode_path[] = 
"kernel/x86/microcode/AuthenticAMD.bin";
+static __initdata char ucode_path[] = "kernel/x86/microcode/AuthenticAMD.bin";
 
-static struct cpio_data __cpuinit find_ucode_in_initrd(void)
+static struct cpio_data __init find_ucode_in_initrd(void)
 {
long offset = 0;
+   char *path;
+   void *start;
+   size_t size;
+   unsigned long *uoffset;
+   size_t *usize;
struct cpio_data cd;
 
 #ifdef CONFIG_X86_32
+   struct boot_params *p;
+
/*
 * On 32-bit, early load occurs before paging is turned on so we need
 * to use physical addresses.
 */
-   if (!(read_cr0() & X86_CR0_PG)) {
-   struct boot_params *p;
-   p  = (struct boot_params *)__pa_nodebug(&boot_params);
-   cd = find_cpio_data((char *)__pa_nodebug(ucode_path),
-   (void *)p->hdr.ramdisk_image, p->hdr.ramdisk_size,
-   &offset);
-   } else
+   p   = (struct boot_params *)__pa_nodebug(&boot_params);
+   path= (char *)__pa_nodebug(ucode_path);
+   start   = (void *)p->hdr.ramdisk_image;
+   size= p->hdr.ramdisk_size;
+   uoffset = (unsigned long *)__pa_nodebug(&ucode_offset);
+   usize   = (size_t *)__pa_nodebug(&ucode_size);
+#else
+   path= ucode_path;
+   start   = (void *)(boot_params.hdr.ramdisk_image + PAGE_OFFSET);
+   size= boot_params.hdr.ramdisk_size;
+   uoffset = &ucode_offset;
+   usize   = &ucode_size;
 #endif
-   cd = find_cpio_data(ucode_path,
-   (void *)(boot_params.hdr.ramdisk_image + PAGE_OFFSET),
-   boot_params.hdr.ramdisk_size, &offset);
+
+   cd = find_cpio_data(path, start, size, &offset);
+   if (!cd.data)
+   return cd;
 
if (*(u32 *)cd.data != UCODE_MAGIC) {
cd.data = NULL;
cd.size = 0;
+   return cd;
}
 
+   *uoffset = (u8 *)cd.data - (u8 *)start;
+   *usize   = cd.size;
+
return cd;
 }
 
@@ -62,9 +82,8 @@ static struct cpio_data __cpuinit find_ucode_in_initrd(void)
  * load_microcode_amd() to save equivalent cpu table and microcode patches in
  * kernel heap memory.
  */
-static void __cpuinit apply_ucode_in_initrd(void)
+static void __cpuinit apply_ucode_in_initrd(void *ucode, size_t size)
 {
-   struct cpio_data cd;
struct equiv_cpu_entry *eq;
u32 *header;
u8  *data;
@@ -78,12 +97,9 @@ static void __cpuinit apply_ucode_in_initrd(void)
 #else
new_rev = &ucode_new_rev;
 #endif
-   cd = find_ucode_in_initrd();
-   if (!cd.data)
-   return;
 
-   data   = cd.data;
-   left   = cd.size;
+   data   = ucode;
+   left   = size;
header = (u32 *)data;
 
/* find equiv cpu table */
@@ -129,7 +145,11 @@ static void __cpuinit apply_ucode_in_initrd(void)
 
 void __init load_ucode_amd_bsp(void)
 {
-   apply_ucode_in_initrd();
+   struct cpio_data cd = find_ucode_in_initrd();
+   if (!cd.data)
+   return;
+
+   apply_ucode_in_initrd(cd.data, cd.size);
 }
 
 #ifdef CONFIG_X86_32
@@ -145,12 +165,26 @@ u8 amd_bsp_mpb[MPB_MAX_SIZE];
 void __cpuinit load_ucode_amd_ap(void)
 {
struct microcode_amd *mc;
+   unsigned long *initrd;
+   unsigned long *uoffset;
+   size_t *usize;
+   void *ucode;
 
-   mc = (struct microcode_amd *)__pa_nodebug(amd_bsp_mpb);
-   if (mc->hdr.patch_id && mc->hdr.processor_rev_id)
+   mc = (struct microcode_amd *)__pa(amd_bsp_mpb);
+   if (mc->hdr.patch_id && mc->hdr.processor_rev_id) {
__apply_microcode_amd(mc);
-   else
-   apply_ucode_in_initrd();
+   return;
+   }
+
+   initrd  = (unsigned long *)__pa(&initrd_start);
+   uoffset = (unsigned long *)__pa(&ucode_offset);
+   usize   = (size_t *)__pa(&ucode_size);
+
+   if (!*usize || !*

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

[Alex Shi]

On 06/07/2013 05:07 PM, Vincent Guittot wrote:
> On 7 June 2013 09:29, Alex Shi  wrote:
>> > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are
>> > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64
>> > vaiables to describe them. unsigned long is more efficient and convenience.
>> >
> Hi Alex,
> 
> I just want to point out that we can't have more than 48388 tasks with
> highest priority on a runqueue with an unsigned long on a 32 bits
> system.  I don't know if we can reach such kind of limit on a 32bits
> machine ? For sure, not on an embedded system.

Thanks question!
It should be a talked problem. I just remember the conclusion is when
you get the up bound task number, you already run out the memory space
on 32 bit.

Just for kernel resource for a process, it need 2 pages stack.
mm_struct, task_struct, task_stats, vm_area_struct, page table etc.
these are already beyond 4 pages. so 4 * 4k * 48388 = 774MB. plus user
level resources.

So, usually the limited task number in Linux is often far lower this
number: $ulimit -u.

Anyway, at least, the runnable_load_avg is smaller then load.weight. if
load.weight can use long type, runablle_load_avg is no reason can't.

-- 
Thanks
Alex
--
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] thinkpad_acpi: return -NODEV while operating uninitialized LEDs

[Amos Kong]

On Fri, Jun 7, 2013 at 5:05 PM, Adam Lee  wrote:
>
> Not all 0-15 LEDs are available for all models, sometimes it's even not
> safe. This patch return -NODEV while operating uninitialized LEDs.
>
> Signed-off-by: Adam Lee 
> ---
>  drivers/platform/x86/thinkpad_acpi.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index 54d31c0..d2ac4e8 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -5401,9 +5401,12 @@ static int led_write(char *buf)
> return -ENODEV;
>
> while ((cmd = next_cmd(&buf))) {
> -   if (sscanf(cmd, "%d", &led) != 1 || led < 0 || led > 15)
> +   if (sscanf(cmd, "%d", &led) != 1 || led < 0 || led > 
> (TPACPI_LED_NUMLEDS -1))
> return -EINVAL;
>
> +   if (!tpacpi_leds[led].led)


The .led filed might be set to '0' in led_init(), how about set the
uninitiated .led to -1? and check by "if (tpacpi_leds[led].led < 0)"

for (i = 0; i < TPACPI_LED_NUMLEDS; i++) {
if (!tpacpi_is_led_restricted(i) &&
test_bit(i, &useful_leds)) {
rc = tpacpi_init_led(i);
if (rc < 0) {
led_exit();
return rc;
-   }
+   } else
+   tpacpi_leds[led].led = -1;

} else tpacpi_leds[led].led = -1;
}


> +   return -ENODEV;
> +
> if (strstr(cmd, "off")) {
> s = TPACPI_LED_OFF;
> } else if (strstr(cmd, "on")) {
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Change the internal SRAM memory type MT_MEMORY_NONCACHED

[Wenyou Yang]

Because MT_DEVICE is not executable in armv7, we change
the internal SRAM memory type to MT_MEMORY_NONCACHED.
As it seems that caching this internal SRAM memory is not necessary,
we chose the this memory type.

Signed-off-by: Wenyou Yang 
---
 arch/arm/mach-at91/setup.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/setup.c b/arch/arm/mach-at91/setup.c
index a33d4b5..98d55ef 100644
--- a/arch/arm/mach-at91/setup.c
+++ b/arch/arm/mach-at91/setup.c
@@ -84,7 +84,7 @@ void __init at91_init_sram(int bank, unsigned long base, 
unsigned int length)
 
desc->pfn = __phys_to_pfn(base);
desc->length = length;
-   desc->type = MT_DEVICE;
+   desc->type = MT_MEMORY_NONCACHED;
 
pr_info("AT91: sram at 0x%lx of 0x%x mapped at 0x%lx\n",
base, length, desc->virtual);
-- 
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: kernel/workqueue.c:4435:61: sparse: expression using sizeof bool

[Fengguang Wu]

// CC sparse people.

On Fri, Jun 07, 2013 at 07:05:49PM -0700, Tejun Heo wrote:
> Hello, Andrew.
> 
> On Fri, Jun 07, 2013 at 06:46:14PM -0700, Andrew Morton wrote:
> > I believe sizeof(bool) can vary between compilers (on gcc it's 1) but
> > that doesn't matter here.
> 
> Looking at the warning, I originally suspected that maybe the standard
> was crazy enough to allow mixed usages of different sizes for bool as
> the compiler sees fit.  Just scanned the spec, nothing that insane.
> It's a proper integeral type, so I'm now more puzzled why sparse is
> warning about sizeof(bool).
> 
> > sizeof(enum) can vary between compilers as well.  In fact I've seen a
> > compiler which used 2 if the enumerated values were 0..65535, and 4
> > otherwise.  So warning about sizeof(enum) would be a bit more useful
> > than about sizeof(bool).
> 
> Oh yeah, gcc does that too.  If the enum definition contains a number
> larger than 32bit, it'll grow it to 64bit.
> 
>  #include 
> 
>  enum { ENUM_A = 1LU };
>  enum { ENUM_B = 1LU << 31 };
>  enum { ENUM_C = 1LU << 32 };
> 
>  int main(void)
>  {
>printf("%zu %zu %zu\n", sizeof(ENUM_A), sizeof(ENUM_B), 
> sizeof(ENUM_C));
>return 0;
>  }
> 
>  $ ./a.out
>  4 4 8
> 
> Whether sparse should trigger a warning on it, I don't know.
> 
> Thanks.
> 
> -- 
> tejun
--
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/

[PATCHv2] irqchip: Add support for TI-NSPIRE irqchip

[Daniel Tang]

This patch adds support for the interrupt controllers found in some
TI-Nspire models.

FIQ support was taken out to simplify the driver
code and may be added in later. Since Linux on this platform doesn't
really use FIQs, this wasn't really that important in the first
place.

Changes from v1 to v2:
* Converted to use generic IRQ chips.
* Removed FIQ for now to simplify driver code.
* Based against tip/irq/core and uses IRQ domain support for generic 
  chips.


Signed-off-by: Daniel Tang 
---
 .../interrupt-controller/lsi,zevio-intc.txt|  18 +++
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-zevio.c| 129 +
 3 files changed, 148 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
 create mode 100644 drivers/irqchip/irq-zevio.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
new file mode 100644
index 000..aee38e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/lsi,zevio-intc.txt
@@ -0,0 +1,18 @@
+TI-NSPIRE interrupt controller
+
+Required properties:
+- compatible: Compatible property value should be "lsi,zevio-intc".
+
+- reg: Physical base address of the controller and length of memory mapped
+   region.
+
+- interrupt-controller : Identifies the node as an interrupt controller
+
+Example:
+
+interrupt-controller {
+   compatible = "lsi,zevio-intc";
+   interrupt-controller;
+   reg = <0xDC00 0x1000>;
+   #interrupt-cells = <1>;
+};
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index cda4cb5..f313d14 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -15,4 +15,5 @@ obj-$(CONFIG_SIRF_IRQ)+= irq-sirfsoc.o
 obj-$(CONFIG_RENESAS_INTC_IRQPIN)  += irq-renesas-intc-irqpin.o
 obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)   += irq-versatile-fpga.o
+obj-$(CONFIG_ARCH_NSPIRE)  += irq-zevio.o
 obj-$(CONFIG_ARCH_VT8500)  += irq-vt8500.o
diff --git a/drivers/irqchip/irq-zevio.c b/drivers/irqchip/irq-zevio.c
new file mode 100644
index 000..92e6c7b
--- /dev/null
+++ b/drivers/irqchip/irq-zevio.c
@@ -0,0 +1,129 @@
+/*
+ *  linux/drivers/irqchip/irq-zevio.c
+ *
+ *  Copyright (C) 2013 Daniel Tang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "irqchip.h"
+
+#define IO_STATUS  0x000
+#define IO_RAW_STATUS  0x004
+#define IO_ENABLE  0x008
+#define IO_DISABLE 0x00C
+#define IO_CURRENT 0x020
+#define IO_RESET   0x028
+#define IO_MAX_PRIOTY  0x02C
+
+#define IO_IRQ_BASE0x000
+#define IO_FIQ_BASE0x100
+
+#define IO_INVERT_SEL  0x200
+#define IO_STICKY_SEL  0x204
+#define IO_PRIORITY_SEL0x300
+
+#define MAX_INTRS  32
+#define FIQ_START  MAX_INTRS
+
+static struct irq_domain *zevio_irq_domain;
+static void __iomem *zevio_irq_io;
+
+static void zevio_irq_ack(struct irq_data *irqd)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(irqd);
+   struct irq_chip_regs *regs =
+   &container_of(irqd->chip, struct irq_chip_type, chip)->regs;
+
+   irq_gc_lock(gc);
+   readl(gc->reg_base + regs->ack);
+   irq_gc_unlock(gc);
+}
+
+static void init_base(void __iomem *base)
+{
+   /* Disable all interrupts */
+   writel(~0, base + IO_DISABLE);
+
+   /* Accept interrupts of all priorities */
+   writel(0xF, base + IO_MAX_PRIOTY);
+
+   /* Reset existing interrupts */
+   readl(base + IO_RESET);
+}
+
+asmlinkage void __exception_irq_entry zevio_handle_irq(struct pt_regs *regs)
+{
+   int irqnr;
+
+   while (readl(zevio_irq_io + IO_STATUS)) {
+   irqnr = readl(zevio_irq_io + IO_CURRENT);
+   irqnr = irq_find_mapping(zevio_irq_domain, irqnr);
+   handle_IRQ(irqnr, regs);
+   };
+}
+
+static int __init zevio_of_init(struct device_node *node,
+   struct device_node *parent)
+{
+   unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
+   struct irq_chip_generic *gc;
+   int ret;
+
+   if (WARN_ON(zevio_irq_io || zevio_irq_domain))
+   return -EBUSY;
+
+   zevio_irq_io = of_iomap(node, 0);
+   BUG_ON(!zevio_irq_io);
+
+   /* Do not invert interrupt status bits */
+   writel(~0, zevio_irq_io + IO_INVERT_SEL);
+
+   /* Disable sticky interrupts */
+   writel(0, zevio_irq_io + IO_STICKY_SEL);
+
+   /* We don't use IRQ priorities. Set each IRQ to highest priority. */
+   memset_io(zevio_irq_io + IO_

Re: [PATCH] Add TI-Nspire irqchip support

[Daniel Tang]

Hi,

On 31/05/2013, at 10:06 PM, Grant Likely  wrote:

> 
> Hi Daniel,
> 
> What is the SoC used in the Nspire? Is it something custom for the
> calculator, or does it use an existing SoC?

It seems to be a custom SoC from what I can see.

> I'm just surprised that this
> device needs a new interrupt controller driver rather than one of the
> drivers that is already in the tree.

I had a brief look in the other driver code and there doesn't seem to be a 
existing driver for this interrupt controller.

> 
> If it is a new device, then that is fine, but you should follow the
> discussion that Thomas pointed you at below.
> 
> g.
> 

Cheers,
Daniel Tang--
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] Run callback of device_prepare/complete consistently

[Rafael J. Wysocki]

On Saturday, June 08, 2013 09:36:03 AM Yanmin Zhang wrote:
> On Sat, 2013-06-08 at 03:30 +0200, Rafael J. Wysocki wrote:
> > On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
> > > On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> > > > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > > > dpm_run_callback is used in other stages of power states changing.
> > > > > > It provides debug info message and time measurement when call these
> > > > > > callback. We also want to benefit ->prepare and ->complete.
> > > > > > 
> > > > > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > > > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in 
> > > > > > device_complete
> > > > > 
> > > > > Is this an "Oh, why don't we do that?" series, or is it useful for 
> > > > > anything
> > > > > in practice?  I'm asking, because we haven't added that stuff to 
> > > > > start with
> > > > > since we didn't see why it would be useful to anyone.
> > > > > 
> > > > > And while patch [1/2] reduces the code size (by 1 line), so I can see 
> > > > > some
> > > > > (tiny) benefit from applying it, patch [2/2] adds more code and is 
> > > > > there any
> > > > > paractical reason?
> > > > Sometimes, suspend-to-ram path spends too much time (either suspend 
> > > > slowly
> > > > or wakeup slowly) and we need optimize it.
> > > > With the 2 patches, we could collect initcall_debug printk info and 
> > > > manually
> > > > check what prepare/complete callbacks consume too much time.
> > > 
> > > But initcall information is for initialization stuff, not suspend/resume
> > > things, right?  Doesn't the existing tools for parsing this choke if it
> > > sees the information at suspend/resume time?
> > 
> > We've been using that for suspend/resume for quite some time too, but not
> > for the prepare/complete phases (because we still believe that's not really
> > useful for them). 
> > 
> > Well, I'll be handling patches changing code under drivers/base/power,
> > I promise. :-)
> > 
> > I've been doing that for quite a few years now ...
> Yes, indeed. Power is one of the most important features on embedded devices.
> Lots of smart phones don't really go through the full cycles of 
> suspend-to-ram.
> We are following the full steps of the suspend.

But if you go through the code, you'll see that alomost no drivers actually
implemet .prepare() and .complete().  Some subsystems do, but they really don't
take too much time to execute.  Which means that your patches with
initcall_debug will add quite a pile of useless garbage to the kernel log and
I'm not sure how that helps?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, 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] Add Initial TI-Nspire support

[Daniel Tang]

Hi,

On 08/06/2013, at 3:55 AM, Arnd Bergmann  wrote:

> On Friday 07 June 2013, Daniel Tang wrote:
>> Hi,
>> 
>> I was wondering if this patch had gone through yet.
> 
> Sorry, not yet.

A few things have changed since I sent in this patch so I need to add some 
adjustments to the patch. There's a few Kconfig options that need adding and 
some device tree bindings that need to be changed.

If it hasn't been merged yet, would it be possible for me to send version 2 of 
the patches? Or would you rather I wait until it is merged and send in a 
separate patch to fix them?

> Olof and I are usually taking turns with merging things
> into the arm-soc tree, but in the past few weeks he has done all of it,
> and he was not on Cc the patch. Please make sure you always send submissions
> for inclusion (as opposed to submissions for review purposes) to
> a...@kernel.org so it reaches both of us.

Ah my apologies. I will do that next time.

> 
> We are also sometimes missing requests for merging for patches (rather
> than git pull requests), so if you don't see your code show up in
> linux-next when it should, just send a friendly reminder like
> this one. I don't currently have a good overview of what pull
> requests are missing, so I think Olof should apply this one, or
> we can do a handover next week so I do the merging again for some
> time.
> 
>   Arnd

Cheers,
Daniel Tang--
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] Run callback of device_prepare/complete consistently

[Yanmin Zhang]

On Sat, 2013-06-08 at 03:30 +0200, Rafael J. Wysocki wrote:
> On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
> > On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> > > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > > dpm_run_callback is used in other stages of power states changing.
> > > > > It provides debug info message and time measurement when call these
> > > > > callback. We also want to benefit ->prepare and ->complete.
> > > > > 
> > > > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in 
> > > > > device_complete
> > > > 
> > > > Is this an "Oh, why don't we do that?" series, or is it useful for 
> > > > anything
> > > > in practice?  I'm asking, because we haven't added that stuff to start 
> > > > with
> > > > since we didn't see why it would be useful to anyone.
> > > > 
> > > > And while patch [1/2] reduces the code size (by 1 line), so I can see 
> > > > some
> > > > (tiny) benefit from applying it, patch [2/2] adds more code and is 
> > > > there any
> > > > paractical reason?
> > > Sometimes, suspend-to-ram path spends too much time (either suspend slowly
> > > or wakeup slowly) and we need optimize it.
> > > With the 2 patches, we could collect initcall_debug printk info and 
> > > manually
> > > check what prepare/complete callbacks consume too much time.
> > 
> > But initcall information is for initialization stuff, not suspend/resume
> > things, right?  Doesn't the existing tools for parsing this choke if it
> > sees the information at suspend/resume time?
> 
> We've been using that for suspend/resume for quite some time too, but not
> for the prepare/complete phases (because we still believe that's not really
> useful for them). 
> 
> Well, I'll be handling patches changing code under drivers/base/power,
> I promise. :-)
> 
> I've been doing that for quite a few years now ...
Yes, indeed. Power is one of the most important features on embedded devices.
Lots of smart phones don't really go through the full cycles of suspend-to-ram.
We are following the full steps of the suspend.


--
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] Run callback of device_prepare/complete consistently

[Yanmin Zhang]

On Fri, 2013-06-07 at 18:16 -0700, Greg KH wrote:
> On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > dpm_run_callback is used in other stages of power states changing.
> > > > It provides debug info message and time measurement when call these
> > > > callback. We also want to benefit ->prepare and ->complete.
> > > > 
> > > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in device_complete
> > > 
> > > Is this an "Oh, why don't we do that?" series, or is it useful for 
> > > anything
> > > in practice?  I'm asking, because we haven't added that stuff to start 
> > > with
> > > since we didn't see why it would be useful to anyone.
> > > 
> > > And while patch [1/2] reduces the code size (by 1 line), so I can see some
> > > (tiny) benefit from applying it, patch [2/2] adds more code and is there 
> > > any
> > > paractical reason?
> > Sometimes, suspend-to-ram path spends too much time (either suspend slowly
> > or wakeup slowly) and we need optimize it.
> > With the 2 patches, we could collect initcall_debug printk info and manually
> > check what prepare/complete callbacks consume too much time.
> 
> But initcall information is for initialization stuff, not suspend/resume
> things, right? 
initcall_debug also controls shutdown callbacks, and suspend/resume callbacks.
See __device_suspend=>dpm_run_callback. It's very useful when we want to 
optimize
suspend-to-ram, or debug some hard issues which happen when async suspend is 
enabled.

>  Doesn't the existing tools for parsing this choke if it
> sees the information at suspend/resume time?
Current kernel doesn't print out info around prepare/complete.


--
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] Run callback of device_prepare/complete consistently

[Rafael J. Wysocki]

On Friday, June 07, 2013 06:16:25 PM Greg KH wrote:
> On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > dpm_run_callback is used in other stages of power states changing.
> > > > It provides debug info message and time measurement when call these
> > > > callback. We also want to benefit ->prepare and ->complete.
> > > > 
> > > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in device_complete
> > > 
> > > Is this an "Oh, why don't we do that?" series, or is it useful for 
> > > anything
> > > in practice?  I'm asking, because we haven't added that stuff to start 
> > > with
> > > since we didn't see why it would be useful to anyone.
> > > 
> > > And while patch [1/2] reduces the code size (by 1 line), so I can see some
> > > (tiny) benefit from applying it, patch [2/2] adds more code and is there 
> > > any
> > > paractical reason?
> > Sometimes, suspend-to-ram path spends too much time (either suspend slowly
> > or wakeup slowly) and we need optimize it.
> > With the 2 patches, we could collect initcall_debug printk info and manually
> > check what prepare/complete callbacks consume too much time.
> 
> But initcall information is for initialization stuff, not suspend/resume
> things, right?  Doesn't the existing tools for parsing this choke if it
> sees the information at suspend/resume time?

We've been using that for suspend/resume for quite some time too, but not
for the prepare/complete phases (because we still believe that's not really
useful for them). 

Well, I'll be handling patches changing code under drivers/base/power,
I promise. :-)

I've been doing that for quite a few years now ...

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, 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/2] PM: use dpm_run_callback in device_prepare

[Yanmin Zhang]

On Fri, 2013-06-07 at 18:15 -0700, Greg KH wrote:
> On Sat, Jun 08, 2013 at 08:43:55AM +0800, Yanmin Zhang wrote:
> > On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
> > > On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
> > > > From: ShuoX Liu 
> > > > 
> > > > dpm_run_callback could show more debug info around prepare stage.
> > > 
> > > Why?  Who needs this?  What problem does it solve?
> > > 
> > > Without answers to this, why would you expect us to accept such a
> > > change?
> > It's to provide more debug info and developers can quickly find what
> > prepare/complete callback consumes too much time.
> 
> What exact debug info is this providing, and why wouldn't you say all of
> this in the original changelog information?
Thanks for the reminder.

Below are examples, after applying the patches. We can see clearly
how much time every device prepare callback consumes.

[  600.384779] sr 1:0:0:0: preparing bus suspend
[  600.384780] call 1:0:0:0+ returned 0 after 2 usecs
[  600.384785] calling  2-1+ @ 2556, parent: usb2
[  600.384788] usb 2-1: preparing type suspend
[  600.384789] call 2-1+ returned 0 after 2 usecs
[  600.384794] calling  1-1.1+ @ 2556, parent: 1-1
[  600.384797] usb 1-1.1: preparing type suspend
[  600.384799] call 1-1.1+ returned 0 after 2 usecs
[  600.384802] calling  1-1.3+ @ 2556, parent: 1-1
[  600.384804] usb 1-1.3: preparing type suspend
[  600.384805] call 1-1.3+ returned 0 after 2 usecs
[  600.384809] calling  1-1.4+ @ 2556, parent: 1-1
[  600.384811] usb 1-1.4: preparing type suspend
[  600.384813] call 1-1.4+ returned 0 after 2 usecs
[  600.384816] calling  1-1.5+ @ 2556, parent: 1-1
[  600.384819] usb 1-1.5: preparing type suspend, may wakeup
[  600.384820] call 1-1.5+ returned 0 after 2 usecs
[  600.384823] calling  1-1.4.1+ @ 2556, parent: 1-1.4
[  600.384825] usb 1-1.4.1: preparing type suspend
[  600.384827] call 1-1.4.1+ returned 0 after 2 usecs
[  600.384829] calling  1-1.4.2+ @ 2556, parent: 1-1.4
[  600.384831] usb 1-1.4.2: preparing type suspend
[  600.384833] call 1-1.4.2+ returned 0 after 2 usecs
[  600.384865] PM: prepare suspend of devices complete after 0.471 msecs

--
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] Run callback of device_prepare/complete consistently

[Rafael J. Wysocki]

On Saturday, June 08, 2013 09:17:13 AM Yanmin Zhang wrote:
> On Sat, 2013-06-08 at 02:54 +0200, Rafael J. Wysocki wrote:
> > On Saturday, June 08, 2013 08:42:12 AM Yanmin Zhang wrote:
> > > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > > dpm_run_callback is used in other stages of power states changing.
> > > > > It provides debug info message and time measurement when call these
> > > > > callback. We also want to benefit ->prepare and ->complete.
> > > > > 
> > > > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in 
> > > > > device_complete
> > > > 
> > > > Is this an "Oh, why don't we do that?" series, or is it useful for 
> > > > anything
> > > > in practice?  I'm asking, because we haven't added that stuff to start 
> > > > with
> > > > since we didn't see why it would be useful to anyone.
> > > > 
> > > > And while patch [1/2] reduces the code size (by 1 line), so I can see 
> > > > some
> > > > (tiny) benefit from applying it, patch [2/2] adds more code and is 
> > > > there any
> > > > paractical reason?
> > > Sometimes, suspend-to-ram path spends too much time (either suspend slowly
> > > or wakeup slowly) and we need optimize it.
> > > With the 2 patches, we could collect initcall_debug printk info and 
> > > manually
> > > check what prepare/complete callbacks consume too much time.
> > 
> > Well, can you point me to a single driver where prepare/complete causes this
> > type of problems to happen?
> 
> That's a good question. We are enabling Android mobiles and need optimize
> suspend-to-ram. In the current upstream, we don't find a driver's 
> prepare/complete
> callback spends too much time.

I understand your needs, but I don't think prepare/complete are likely to take
too much time on Android either.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, 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] Run callback of device_prepare/complete consistently

[Greg KH]

On Sat, Jun 08, 2013 at 08:42:12AM +0800, Yanmin Zhang wrote:
> On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > dpm_run_callback is used in other stages of power states changing.
> > > It provides debug info message and time measurement when call these
> > > callback. We also want to benefit ->prepare and ->complete.
> > > 
> > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in device_complete
> > 
> > Is this an "Oh, why don't we do that?" series, or is it useful for anything
> > in practice?  I'm asking, because we haven't added that stuff to start with
> > since we didn't see why it would be useful to anyone.
> > 
> > And while patch [1/2] reduces the code size (by 1 line), so I can see some
> > (tiny) benefit from applying it, patch [2/2] adds more code and is there any
> > paractical reason?
> Sometimes, suspend-to-ram path spends too much time (either suspend slowly
> or wakeup slowly) and we need optimize it.
> With the 2 patches, we could collect initcall_debug printk info and manually
> check what prepare/complete callbacks consume too much time.

But initcall information is for initialization stuff, not suspend/resume
things, right?  Doesn't the existing tools for parsing this choke if it
sees the information at suspend/resume time?

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 0/2] Run callback of device_prepare/complete consistently

[Yanmin Zhang]

On Sat, 2013-06-08 at 02:54 +0200, Rafael J. Wysocki wrote:
> On Saturday, June 08, 2013 08:42:12 AM Yanmin Zhang wrote:
> > On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > > dpm_run_callback is used in other stages of power states changing.
> > > > It provides debug info message and time measurement when call these
> > > > callback. We also want to benefit ->prepare and ->complete.
> > > > 
> > > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in device_complete
> > > 
> > > Is this an "Oh, why don't we do that?" series, or is it useful for 
> > > anything
> > > in practice?  I'm asking, because we haven't added that stuff to start 
> > > with
> > > since we didn't see why it would be useful to anyone.
> > > 
> > > And while patch [1/2] reduces the code size (by 1 line), so I can see some
> > > (tiny) benefit from applying it, patch [2/2] adds more code and is there 
> > > any
> > > paractical reason?
> > Sometimes, suspend-to-ram path spends too much time (either suspend slowly
> > or wakeup slowly) and we need optimize it.
> > With the 2 patches, we could collect initcall_debug printk info and manually
> > check what prepare/complete callbacks consume too much time.
> 
> Well, can you point me to a single driver where prepare/complete causes this
> type of problems to happen?

That's a good question. We are enabling Android mobiles and need optimize
suspend-to-ram. In the current upstream, we don't find a driver's 
prepare/complete
callback spends too much time.


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

Re: [PATCH 1/2] PM: use dpm_run_callback in device_prepare

[Greg KH]

On Sat, Jun 08, 2013 at 08:43:55AM +0800, Yanmin Zhang wrote:
> On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
> > On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
> > > From: ShuoX Liu 
> > > 
> > > dpm_run_callback could show more debug info around prepare stage.
> > 
> > Why?  Who needs this?  What problem does it solve?
> > 
> > Without answers to this, why would you expect us to accept such a
> > change?
> It's to provide more debug info and developers can quickly find what
> prepare/complete callback consumes too much time.

What exact debug info is this providing, and why wouldn't you say all of
this in the original changelog information?

{hint}

--
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] ARM: exynos: add debug_ll_io_init() call in exynos_init_io()

[Olof Johansson]

On Thu, Jun 06, 2013 at 08:32:04AM +0900, Kukjin Kim wrote:
> Olof Johansson wrote:
> > 
> > On Wed, Jun 5, 2013 at 1:56 PM, Doug Anderson 
> > wrote:
> > > If the early MMU mapping of the UART happens to get booted out of the
> > > TLB between the start of paging_init() and when we finally re-add the
> > > UART at the very end of s3c_init_cpu(), we'll get a hang at bootup if
> > > we've got early_printk enabled.  Avoid this hang by calling
> > > debug_ll_io_init() early.
> > >
> > > Without this patch, you can reliably reproduce a hang when early
> > > printk is enabled by adding flush_tlb_all() at the start of
> > > exynos_init_io().  After this patch the hang goes away.
> > >
> > > Signed-off-by: Doug Anderson 
> > 
> > Acked-by: Olof Johansson 
> > 
> > 
> > Kukjin, this seems appropriate for 3.10. Do you have other fixes
> > queued or should I apply this directly?
> > 
> If I remember correctly, nothing in my tree for 3.10.
> 
> So please go ahead with my ack if you want,
> 
> Acked-by: Kukjin Kim 
> 

Applied for 3.10 (together with the uncompress.h fix from Tushar)


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

Re: [PATCH 2/2 v2] f2fs: support xattr security labels

[Jaegeuk Kim]

Change log from v2:
 o fix description and simplify a code line (commented by Casey
Schaufler)

Change log from v1:
 o fix a bug

From 9f889afcd74a58d9a538fa02f4af31d11eb17c54 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Mon, 3 Jun 2013 19:46:19 +0900
Subject: [PATCH] f2fs: support xattr security labels
Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org, 
linux-f2fs-de...@lists.sourceforge.net

This patch adds the support of security labels for f2fs, which will be used
by Linus Security Models (LSMs).

Quote from http://en.wikipedia.org/wiki/Linux_Security_Modules:
"Linux Security Modules (LSM) is a framework that allows the Linux kernel to
support a variety of computer security models while avoiding favoritism toward
any single security implementation. The framework is licensed under the terms of
the GNU General Public License and is standard part of the Linux kernel since
Linux 2.6. AppArmor, SELinux, Smack and TOMOYO Linux are the currently accepted
modules in the official kernel.".

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/Kconfig | 12 +++
 fs/f2fs/dir.c   |  5 +
 fs/f2fs/xattr.c | 62 ++---
 fs/f2fs/xattr.h | 12 ++-
 4 files changed, 87 insertions(+), 4 deletions(-)

diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
index fd27e7e..e06e099 100644
--- a/fs/f2fs/Kconfig
+++ b/fs/f2fs/Kconfig
@@ -51,3 +51,15 @@ config F2FS_FS_POSIX_ACL
  Linux website .
 
  If you don't know what Access Control Lists are, say N
+
+config F2FS_FS_SECURITY
+   bool "F2FS Security Labels"
+   depends on F2FS_FS_XATTR
+   help
+ Security labels provide an access control facility to support Linux
+ Security Models (LSMs) accepted by AppArmor, SELinux, Smack and TOMOYO
+ Linux. This option enables an extended attribute handler for file
+ security labels in the f2fs filesystem, so that it requires enabling
+ the extended attribute support in advance.
+
+ If you are not using a security module, say N.
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 67e2d13..81a1d6f 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -13,6 +13,7 @@
 #include "f2fs.h"
 #include "node.h"
 #include "acl.h"
+#include "xattr.h"
 
 static unsigned long dir_blocks(struct inode *inode)
 {
@@ -334,6 +335,10 @@ static struct page *init_inode_metadata(struct inode 
*inode,
if (err)
goto error;
 
+   err = f2fs_init_security(inode, dir, name);
+   if (err)
+   goto error;
+
wait_on_page_writeback(page);
} else {
page = get_node_page(F2FS_SB(dir->i_sb), inode->i_ino);
diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index ae61f35..c06e8a3 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -20,6 +20,7 @@
  */
 #include 
 #include 
+#include 
 #include "f2fs.h"
 #include "xattr.h"
 
@@ -43,6 +44,10 @@ static size_t f2fs_xattr_generic_list(struct dentry *dentry, 
char *list,
prefix = XATTR_TRUSTED_PREFIX;
prefix_len = XATTR_TRUSTED_PREFIX_LEN;
break;
+   case F2FS_XATTR_INDEX_SECURITY:
+   prefix = XATTR_SECURITY_PREFIX;
+   prefix_len = XATTR_SECURITY_PREFIX_LEN;
+   break;
default:
return -EINVAL;
}
@@ -50,7 +55,7 @@ static size_t f2fs_xattr_generic_list(struct dentry *dentry, 
char *list,
total_len = prefix_len + name_len + 1;
if (list && total_len <= list_size) {
memcpy(list, prefix, prefix_len);
-   memcpy(list+prefix_len, name, name_len);
+   memcpy(list + prefix_len, name, name_len);
list[prefix_len + name_len] = '\0';
}
return total_len;
@@ -70,13 +75,14 @@ static int f2fs_xattr_generic_get(struct dentry *dentry, 
const char *name,
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
break;
+   case F2FS_XATTR_INDEX_SECURITY:
+   break;
default:
return -EINVAL;
}
if (strcmp(name, "") == 0)
return -EINVAL;
-   return f2fs_getxattr(dentry->d_inode, type, name,
-   buffer, size);
+   return f2fs_getxattr(dentry->d_inode, type, name, buffer, size);
 }
 
 static int f2fs_xattr_generic_set(struct dentry *dentry, const char *name,
@@ -93,6 +99,8 @@ static int f2fs_xattr_generic_set(struct dentry *dentry, 
const char *name,
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
break;
+   case F2FS_XATTR_INDEX_SECURITY:
+   break;
default:
return -EINVAL;
}
@@ -145,6 +153,40 @@ static int f2fs_xattr_advise_set(struct dentry *dentry, 
const char *name,
return 0;
 }
 
+#ifdef CONFIG_F2FS_FS_SECURITY
+static int f

Re: [PATCH v2 1/3] ARM: EXYNOS: uncompress - print debug messages if DEBUG_LL is defined

[Olof Johansson]

On Thu, Jun 06, 2013 at 02:37:01PM +0530, Tushar Behera wrote:
> On 06/04/2013 09:49 AM, Tushar Behera wrote:
> > Printing low-level debug messages make an assumption that the specified
> > UART port has been preconfigured by the bootloader. Incorrectly
> > specified UART port results in system getting stalled while printing the
> > message "Uncompressing Linux... done, booting the kernel"
> > This UART port number is specified through S3C_LOWLEVEL_UART_PORT. Since
> > the UART port might different for different board, it is not possible to
> > specify it correctly for every board that use a common defconfig file.
> > 
> > Calling this print subroutine only when DEBUG_LL fixes the problem. By
> > disabling DEBUG_LL in default config file, we would be able to boot
> > multiple boards with different default UART ports.
> > 
> > With this current approach, we miss the print "Uncompressing Linux...
> > done, booting the kernel." when DEBUG_LL is not defined.
> > 
> > Signed-off-by: Tushar Behera 
> > ---
> > Change for v2:
> > * Instead of checking value of uart_base, now check if DEBUG_LL
> > is enabled. This removes the ifdef's from mach/uncompress.h
> > 
> > 
> >  arch/arm/plat-samsung/include/plat/uncompress.h |   10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> 
> If there are no concerns, would it be possible to queue this patch [1/3]
> for 3.10?
> 
> The other two patches can wait for 3.11.

Sure, I've applied it to fixes for 3.10.


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

Re: [PATCH v2] ARM: mmp: bring up pxa988 with device tree support

[Chao Xie]

hi, Arnd
Thanks for your review.

On Fri, Jun 7, 2013 at 12:26 AM, Arnd Bergmann  wrote:
> On Thursday 06 June 2013, Neil Zhang wrote:
>> > > diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig
>> > > index ebdda83..0955191 100644
>> > > --- a/arch/arm/mach-mmp/Kconfig
>> > > +++ b/arch/arm/mach-mmp/Kconfig
>> > > @@ -107,6 +107,16 @@ config MACH_MMP2_DT
>> > > Include support for Marvell MMP2 based platforms using
>> > > the device tree.
>> > >
>> > > +config MACH_MMPX_DT
>> > > + bool "Support no-PJ/PJ4(ARMv7) platforms from device tree"
>> > > + depends on !CPU_MOHAWK && !CPU_PJ4
>> > > + select CPU_PXA988
>> > > + select USE_OF
>> > > + select PINCTRL
>> > > + select PINCTRL_SINGLE
>> >
>> > Why would this be mutually exclusive with PJ4? Cortex-A9 and PJ4 are both
>> > ARMv7 based, so we should be able to have them in the same kernel.
>>
>> The MACH_MMPX_DT here is for standard ARM core based SoC.
>> But PJ4 is modified by Marvell, which includes IWMMXT.
>
> That should not stop us from supporting them with the same kernel.
> We can already build a kernel that will work with IWMMXT on
> ArmadaXP (PJ4B) and Calxeda Highbank (Cortex-A9) for instance.
>
Yes. We can compile it, because will fail to boot up the core.
The correct way to adding device tree support for
iwmmx(arch/arm/kernel/pj4-cp0.c).
I think we can do it if you agree with us.

>> > __initdata = {
>> > >   .virtual= (unsigned long)AXI_VIRT_BASE,
>> > >   .length = AXI_PHYS_SIZE,
>> > >   .type   = MT_DEVICE,
>> > > - },
>> > > + }, {
>> > > + .pfn= __phys_to_pfn(MMP_CORE_PERIPH_PHYS_BASE),
>> > > + .virtual= (unsigned long)MMP_CORE_PERIPH_VIRT_BASE,
>> > > + .length = MMP_CORE_PERIPH_PHYS_SIZE,
>> > > + .type   = MT_DEVICE,
>> > > + }
>> > >  };
>> > >
>> > >  void __init mmp_map_io(void)
>> >
>> > What is this needed for?
>>
>> This function is used to static map the device registers.
>
> I understand what map_io does. Why do you need a static mapping?
>

The AXI and APB bus register mapping, It does not need to be static mapping.
Because we define the registers for each peripharals in device tree.
The device driver can map it.
There is a exception. The address space used by core for example CPU
SCU registers for CA9.
We have to read/write the registers even device tree has not been
build up in kernel, for example ->smp_prepare_cpus.
At this point, how can we get the base address for SCU?

>> > > +/* PXA988 */
>> > > +static const struct of_dev_auxdata pxa988_auxdata_lookup[] __initconst
>> > = {
>> > > + OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4017000, "pxa2xx-uart.0",
>> > NULL),
>> > > + OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4018000, "pxa2xx-uart.1",
>> > NULL),
>> > > + OF_DEV_AUXDATA("mrvl,mmp-uart", 0xd4036000, "pxa2xx-uart.2",
>> > NULL),
>> > > + OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4011000, "pxa2xx-i2c.0",
>> > NULL),
>> > > + OF_DEV_AUXDATA("mrvl,mmp-twsi", 0xd4037000, "pxa2xx-i2c.1",
>> > NULL),
>> > > + OF_DEV_AUXDATA("mrvl,mmp-gpio", 0xd4019000, "pxa-gpio", NULL),
>> > > + OF_DEV_AUXDATA("mrvl,mmp-rtc", 0xd401, "sa1100-rtc", NULL),
>> > > + {}
>> > > +};
>> >
>> > Why do you need auxdata?
>>
>> Two reasons:
>> 1. some of the device still need platform data at this time.
>
> None of the ones above do apparently.
>
Now, some devices are not added. For example, USB.
I am trying to modify the USB driver to make it support device tree.
For example, separate the phy and PMIC support from USB driver.
The patches have been reviewed in USB maillist for a long time.
Now it is hold because the maintainer think HCD and PHY need do some fix.
So as a temporaty solution before us pushing USB patches, we have to
use platform data for USB.

>> 2. we use device name as clk name.
>> Will change it later, but need some time.
>
> If you have no platform_data, I think you should modify the clkdev
> lookup table to refer to the DT based names so you no longer have
> to pass auxdata.
>
> The long term solution of course is to describe the clocks in the
> device tree as well.
>
Thanks for your comments. Now we are doing the clock tree changing.
Haojian has sent some patches adding device tree support for clock
tree, but pxa988 are not included.
We will do the clock changes for pxa988 after Haojian's patches been
reviewed and merged.

I hope that we can fully support device tree for pxa988 and the next
generation SOCes including all the peripahrals.
In our local code base for development, we are doing this, but it is
not that easy.

>> > > +void __init pxa988_dt_init_timer(void) {
>> > > + extern void __init mmp_dt_init_timer(void);
>> >
>> > You should never put 'extern' declarations into a .c file.
>> >
>> > > + /*
>> > > +  * Is is a SOC timer, and will be used for broadcasting
>> > > +  * when local timers are disabled.
>> > > +  */
>> > > + mmp_dt_init_timer();
>> > > +
>> > > + clocksource_of_init();
>> > > +}
>> >
>>

Re: [PATCH] xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it.

[Bob Liu]

On 06/08/2013 03:45 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 07, 2013 at 12:29:15PM -0700, Konrad Rzeszutek Wilk wrote:
> 
> CC-ing Bob.
> 
>> Commit 10a7a0771399a57a297fca9615450dbb3f88081a ("xen: tmem: enable Xen
>> tmem shim to be built/loaded as a module") allows the tmem module
>> to be loaded any time. For this work the frontswap API had to
>> be able to asynchronously to call tmem_frontswap_init before
>> or after the swap image had been set. That was added in git
>> commit 905cd0e1bf9ffe82d6906a01fd974ea0f70be97a
>> ("mm: frontswap: lazy initialization to allow tmem backends to build/run as 
>> modules").
>>
>> Which means we could do this (The common case):
>>
>>  modprobe tmem   [so calls frontswap_register_ops, no ->init]
>>   modifies tmem_frontswap_poolid = -1
>>  swapon /dev/xvda1   [__frontswap_init, calls -> init, tmem_frontswap_poolid 
>> is
>>   < 0 so tmem hypercall done]
>>
>> Or the failing one:
>>
>>  swapon /dev/xvda1   [calls __frontswap_init, sets the need_init bitmap]
>>  modprobe tmem   [calls frontswap_register_ops, -->init calls, 
>> finds out
>>  tmem_frontswap_poolid is 0, does not make a hypercall.
>>  Later in the module_init, sets tmem_frontswap_poolid=-1]
>>
>> Which meant that in the failing case we would not call the hypercall
>> to initialize the pool and never be able to make any frontswap
>> backend calls.
>>
>> Moving the frontswap_register_ops after setting the tmem_frontswap_poolid
>> fixes it.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk 

Nice catch!
Reviewed-by: Bob Liu 

>> ---
>>  drivers/xen/tmem.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
>> index cc072c6..0f0493c 100644
>> --- a/drivers/xen/tmem.c
>> +++ b/drivers/xen/tmem.c
>> @@ -379,10 +379,10 @@ static int xen_tmem_init(void)
>>  #ifdef CONFIG_FRONTSWAP
>>  if (tmem_enabled && frontswap) {
>>  char *s = "";
>> -struct frontswap_ops *old_ops =
>> -frontswap_register_ops(&tmem_frontswap_ops);
>> +struct frontswap_ops *old_ops;
>>  
>>  tmem_frontswap_poolid = -1;
>> +old_ops = frontswap_register_ops(&tmem_frontswap_ops);
>>  if (IS_ERR(old_ops) || old_ops) {
>>  if (IS_ERR(old_ops))
>>  return PTR_ERR(old_ops);
>> -- 
>> 1.8.1.4
>>

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

Re: [PATCH 2/2] f2fs: support xattr security labels

[Jaegeuk Kim]

Hi,
Thank you for the review.
I agreed all, and will submit v3.
Thanks,

2013-06-07 (금), 15:13 -0700, Casey Schaufler:
> On 6/6/2013 10:55 PM, Jaegeuk Kim wrote:
> > This patch adds the support of security labels for f2fs, which will be used
> > by SElinux.
> 
> Please be inclusive. Security xattrs are used by LSMs other than SELinux.

> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/Kconfig |  9 +
> >  fs/f2fs/dir.c   |  5 +
> >  fs/f2fs/xattr.c | 59 
> > +++--
> >  fs/f2fs/xattr.h | 12 +++-
> >  4 files changed, 82 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
> > index fd27e7e..2214cc9 100644
> > --- a/fs/f2fs/Kconfig
> > +++ b/fs/f2fs/Kconfig
> > @@ -51,3 +51,12 @@ config F2FS_FS_POSIX_ACL
> >   Linux website .
> >  
> >   If you don't know what Access Control Lists are, say N
> > +
> > +config F2FS_FS_SECURITY
> > +   bool "F2FS Security Labels"
> > +   depends on F2FS_FS_XATTR
> > +   help
> > + Security labels provide acls used by the security modules
> > + like SELinux. This option should be used with the xattr mode.
> 
> This description missuses the term "acl". Security labels are not
> Access Control Lists (ACLs). What is the "xattr mode"? If this option
> depends on xattr support "should" is not correct.
> 
> > +
> > + If you are not using a security module, say N.
> > diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
> > index 67e2d13..81a1d6f 100644
> > --- a/fs/f2fs/dir.c
> > +++ b/fs/f2fs/dir.c
> > @@ -13,6 +13,7 @@
> >  #include "f2fs.h"
> >  #include "node.h"
> >  #include "acl.h"
> > +#include "xattr.h"
> >  
> >  static unsigned long dir_blocks(struct inode *inode)
> >  {
> > @@ -334,6 +335,10 @@ static struct page *init_inode_metadata(struct inode 
> > *inode,
> > if (err)
> > goto error;
> >  
> > +   err = f2fs_init_security(inode, dir, name);
> > +   if (err)
> > +   goto error;
> > +
> > wait_on_page_writeback(page);
> > } else {
> > page = get_node_page(F2FS_SB(dir->i_sb), inode->i_ino);
> > diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
> > index ae61f35..b5292fa 100644
> > --- a/fs/f2fs/xattr.c
> > +++ b/fs/f2fs/xattr.c
> > @@ -20,6 +20,7 @@
> >   */
> >  #include 
> >  #include 
> > +#include 
> >  #include "f2fs.h"
> >  #include "xattr.h"
> >  
> > @@ -43,6 +44,10 @@ static size_t f2fs_xattr_generic_list(struct dentry 
> > *dentry, char *list,
> > prefix = XATTR_TRUSTED_PREFIX;
> > prefix_len = XATTR_TRUSTED_PREFIX_LEN;
> > break;
> > +   case F2FS_XATTR_INDEX_SECURITY:
> > +   prefix = XATTR_SECURITY_PREFIX;
> > +   prefix_len = XATTR_SECURITY_PREFIX_LEN;
> > +   break;
> > default:
> > return -EINVAL;
> > }
> > @@ -70,13 +75,14 @@ static int f2fs_xattr_generic_get(struct dentry 
> > *dentry, const char *name,
> > if (!capable(CAP_SYS_ADMIN))
> > return -EPERM;
> > break;
> > +   case F2FS_XATTR_INDEX_SECURITY:
> > +   break;
> > default:
> > return -EINVAL;
> > }
> > if (strcmp(name, "") == 0)
> > return -EINVAL;
> > -   return f2fs_getxattr(dentry->d_inode, type, name,
> > -   buffer, size);
> > +   return f2fs_getxattr(dentry->d_inode, type, name, buffer, size);
> >  }
> >  
> >  static int f2fs_xattr_generic_set(struct dentry *dentry, const char *name,
> > @@ -93,6 +99,8 @@ static int f2fs_xattr_generic_set(struct dentry *dentry, 
> > const char *name,
> > if (!capable(CAP_SYS_ADMIN))
> > return -EPERM;
> > break;
> > +   case F2FS_XATTR_INDEX_SECURITY:
> > +   break;
> > default:
> > return -EINVAL;
> > }
> > @@ -145,6 +153,40 @@ static int f2fs_xattr_advise_set(struct dentry 
> > *dentry, const char *name,
> > return 0;
> >  }
> >  
> > +#ifdef CONFIG_F2FS_FS_SECURITY
> > +static int f2fs_initxattrs(struct inode *inode, const struct xattr 
> > *xattr_array,
> > +   void *fs_info)
> > +{
> > +   const struct xattr *xattr;
> > +   char *name;
> > +   int err = 0;
> > +
> > +   for (xattr = xattr_array; xattr->name != NULL; xattr++) {
> > +   name = kmalloc(XATTR_SECURITY_PREFIX_LEN +
> > +  strlen(xattr->name) + 1, GFP_NOFS);
> > +   if (!name) {
> > +   err = -ENOMEM;
> > +   break;
> > +   }
> > +   strcpy(name, XATTR_SECURITY_PREFIX);
> > +   strcpy(name + XATTR_SECURITY_PREFIX_LEN, xattr->name);
> 
>   sprintf(name, XATTR_SECURITY_PREFIX "%s", xattr->name);
> 
> might look simpler.
> 
> > +   err = f2fs_setxattr(inode, F2FS_XATTR_INDEX_SECURITY, name,
> > +   xattr->value, xattr->value_len);
> > +   kfree(name);

[PATCH, revert] ACPI / scan: Revert scan handler check in acpi_bus_match()

[Rafael J. Wysocki]

On Friday, June 07, 2013 03:23:44 PM Tony Luck wrote:
> On Fri, Jun 7, 2013 at 5:51 AM, Rafael J. Wysocki  wrote:
> > Aaron Lu (1):
> >   ACPI / scan: do not match drivers against objects having scan handlers
> 
> This patch showed up in linux-next tag next-20130605 and appears to be the
> cause of a boot failure on my ia64 HP rx2600 system.  It panics with
> the message:
> 
> Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or
> DIG kernel
> 
> Reverting this from next-20130605 fixes my problem and I can boot again.
> 
> So please don't pull.

Sorry about this.

I don't think we will find out what's wrong here before -rc5, so please apply
the appended revert.

Rafael


---
From: Rafael J. Wysocki 
Subject: ACPI / scan: Revert scan handler check in acpi_bus_match()

Commit 9f29ab1 (ACPI / scan: do not match drivers against objects
having scan handlers) introduced a boot regression on Tony's
ia64 HP rx2600.  Tony says:

  "It panics with the message:

   Kernel panic - not syncing: Unable to find SBA IOMMU: Try a generic or DIG 
kernel

   [...] my problem comes from arch/ia64/hp/common/sba_iommu.c
   where the code in sba_init() says:

acpi_bus_register_driver(&acpi_sba_ioc_driver);
if (!ioc_list) {

   but because of this change we never managed to call ioc_init()
   so ioc_list doesn't get set up, and we die."

Revert commit 9f29ab1 to avoid this breakage and we'll fix the
problem it attempted to address later.

Reported-by: Tony Luck 
Cc: 3.9+ 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/scan.c |4 
 1 file changed, 4 deletions(-)

Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -857,10 +857,6 @@ static int acpi_bus_match(struct device
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = to_acpi_driver(drv);
 
-   /* Skip ACPI device objects with scan handlers attached. */
-   if (acpi_dev->handler)
-   return 0;
-
return acpi_dev->flags.match_driver
&& !acpi_match_device_ids(acpi_dev, acpi_drv->ids);
 }

--
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] Run callback of device_prepare/complete consistently

[Rafael J. Wysocki]

On Saturday, June 08, 2013 08:42:12 AM Yanmin Zhang wrote:
> On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> > On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > > dpm_run_callback is used in other stages of power states changing.
> > > It provides debug info message and time measurement when call these
> > > callback. We also want to benefit ->prepare and ->complete.
> > > 
> > > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > > [PATCH 2/2] PM: add dpm_run_callback_void and use it in device_complete
> > 
> > Is this an "Oh, why don't we do that?" series, or is it useful for anything
> > in practice?  I'm asking, because we haven't added that stuff to start with
> > since we didn't see why it would be useful to anyone.
> > 
> > And while patch [1/2] reduces the code size (by 1 line), so I can see some
> > (tiny) benefit from applying it, patch [2/2] adds more code and is there any
> > paractical reason?
> Sometimes, suspend-to-ram path spends too much time (either suspend slowly
> or wakeup slowly) and we need optimize it.
> With the 2 patches, we could collect initcall_debug printk info and manually
> check what prepare/complete callbacks consume too much time.

Well, can you point me to a single driver where prepare/complete causes this
type of problems to happen?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, 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/2] PM: use dpm_run_callback in device_prepare

[Yanmin Zhang]

On Fri, 2013-06-07 at 10:37 -0700, Greg KH wrote:
> On Fri, Jun 07, 2013 at 04:20:31PM +0800, shuox@intel.com wrote:
> > From: ShuoX Liu 
> > 
> > dpm_run_callback could show more debug info around prepare stage.
> 
> Why?  Who needs this?  What problem does it solve?
> 
> Without answers to this, why would you expect us to accept such a
> change?
It's to provide more debug info and developers can quickly find what
prepare/complete callback consumes too much time.


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

Re: [PATCH 0/2] Run callback of device_prepare/complete consistently

[Yanmin Zhang]

On Fri, 2013-06-07 at 12:36 +0200, Rafael J. Wysocki wrote:
> On Friday, June 07, 2013 04:20:30 PM shuox@intel.com wrote:
> > dpm_run_callback is used in other stages of power states changing.
> > It provides debug info message and time measurement when call these
> > callback. We also want to benefit ->prepare and ->complete.
> > 
> > [PATCH 1/2] PM: use dpm_run_callback in device_prepare
> > [PATCH 2/2] PM: add dpm_run_callback_void and use it in device_complete
> 
> Is this an "Oh, why don't we do that?" series, or is it useful for anything
> in practice?  I'm asking, because we haven't added that stuff to start with
> since we didn't see why it would be useful to anyone.
> 
> And while patch [1/2] reduces the code size (by 1 line), so I can see some
> (tiny) benefit from applying it, patch [2/2] adds more code and is there any
> paractical reason?
Sometimes, suspend-to-ram path spends too much time (either suspend slowly
or wakeup slowly) and we need optimize it.
With the 2 patches, we could collect initcall_debug printk info and manually
check what prepare/complete callbacks consume too much time.

Thanks,
Yanmin


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

Re: [PATCH 2/2 v2] f2fs: support xattr security labels

[Jaegeuk Kim]

2013-06-07 (금), 19:50 +0900, Namjae Jeon:
> 2013/6/7, Jaegeuk Kim :
> > Change log from v1:
> >  o fix a bug
> >
> > From 901aea226653e26aa3556edd88ca1e48fa89eb5f Mon Sep 17 00:00:00 2001
> > From: Jaegeuk Kim 
> > Date: Mon, 3 Jun 2013 19:46:19 +0900
> > Subject: [PATCH 2/2] f2fs: support xattr security labels
> > Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
> > linux-f2fs-de...@lists.sourceforge.net
> >
> > This patch adds the support of security labels for f2fs, which will be used
> > by SElinux.
> >
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/Kconfig |  9 +
> >  fs/f2fs/dir.c   |  5 +
> >  fs/f2fs/xattr.c | 60
> > +++--
> >  fs/f2fs/xattr.h | 12 +++-
> >  4 files changed, 83 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
> > index fd27e7e..2214cc9 100644
> > --- a/fs/f2fs/Kconfig
> > +++ b/fs/f2fs/Kconfig
> > @@ -51,3 +51,12 @@ config F2FS_FS_POSIX_ACL
> >   Linux website .
> >
> >   If you don't know what Access Control Lists are, say N
> > +
> > +config F2FS_FS_SECURITY
> > +   bool "F2FS Security Labels"
> > +   depends on F2FS_FS_XATTR
> Hi Jaegeuk.
> Do we need to add "default y" as other xattr options ?

Hi Namjae,
Currently negative.
Most of xattr operations will be fine though, I'd like to test them more
intensively. After then, we'd better set *default y*.
Thanks, :)

> 
> Thanks.
> > +   help
> > + Security labels provide acls used by the security modules
> > + like SELinux. This option should be used with the xattr mode.
> > +
> > + If you are not using a security module, say N.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jaegeuk Kim
Samsung


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

Re: [PATCH 20/31] mips/kvm: Hook into TLB fault handlers.

[David Daney]

On 06/07/2013 04:34 PM, Sergei Shtylyov wrote:

Hello.

On 06/08/2013 03:03 AM, David Daney wrote:


From: David Daney 

If the CPU is operating in guest mode when a TLB related excpetion
occurs, give KVM a chance to do emulation.

Signed-off-by: David Daney 
---
  arch/mips/mm/fault.c   | 8 
  arch/mips/mm/tlbex-fault.S | 6 ++
  2 files changed, 14 insertions(+)

diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index 0fead53..9391da49 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c

[...]

@@ -50,6 +51,13 @@ asmlinkage void __kprobes do_page_fault(struct
pt_regs *regs, unsigned long writ
 field, regs->cp0_epc);
  #endif
+#ifdef CONFIG_KVM_MIPSVZ
+if (test_tsk_thread_flag(current, TIF_GUESTMODE)) {
+if (mipsvz_page_fault(regs, write, address))


Any reason not to collapse these into single *if*?



It makes the conditional call to mipsvz_page_fault() less obvious.

Certainly the same semantics can be achieved several different ways.

David Daney



+return;
+}
+#endif
+







--
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] list: add list_for_each_entry_del

[Andy Shevchenko]

On Fri, Jun 7, 2013 at 9:48 PM, Jörn Engel  wrote:
> On Fri, 7 June 2013 21:30:16 +0300, Andy Shevchenko wrote:
>> >
>> > spin_lock
>> > list_for_each_entry_safe
>> > list_del
>> > spin_unlock
>>
>> Who is doing such thing?
>
> Replace list_for_each_entry_safe with 'while (!list_empty(...))' and
> just grep.  My patch is about 'while (!list_empty(...))', not about
> list_for_each_entry_safe.

I saw your patch against btrfs.
I didn't see locking there.

Any excerpt like

 while (!list_empty(&prefs)) {
 ref = list_first_entry(&prefs, struct __prelim_ref, list);
 list_del(&ref->list);

could be transformed to
struct __prelim_ref *_ref;
list_for_each_entry_safe(ref, _ref, &prefs, list) {
 list_del(&ref->list);
 ...
}

but is it worth to do? (Same question to your approach)

I see two potential issues with while_list_drain_entry() or whatever
name you like:
 - you delete list as a first operation - you limit user to think in
that way, if you choose deletion as last operation, who will go to
free resources (call kfree() for example)?
- you always use the same ordering (list_first_entry() call), someone
may not be satisfied by that

So, the approach with while (!list_empty()) { e = list_entry();
list_del(&e->list); ... }
actually not bad. If there any bugs in code, better to fix those bugs
explicitly.

What do I not understand?

--
With Best Regards,
Andy Shevchenko
--
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 6/6] isdn: clean up debug format string usage

[Kees Cook]

Avoid unneeded local string buffers for constructing debug output. Also
cleans up debug calls that contain a single parameter so that they cannot
be accidentally parsed as format strings.

Signed-off-by: Kees Cook 
Cc: Karsten Keil 
---
 drivers/isdn/hisax/amd7930_fn.c |4 ++--
 drivers/isdn/hisax/avm_pci.c|4 ++--
 drivers/isdn/hisax/config.c |2 +-
 drivers/isdn/hisax/diva.c   |4 ++--
 drivers/isdn/hisax/elsa.c   |2 +-
 drivers/isdn/hisax/elsa_ser.c   |2 +-
 drivers/isdn/hisax/hfc_pci.c|2 +-
 drivers/isdn/hisax/hfc_sx.c |2 +-
 drivers/isdn/hisax/hscx_irq.c   |4 ++--
 drivers/isdn/hisax/icc.c|4 ++--
 drivers/isdn/hisax/ipacx.c  |8 +++
 drivers/isdn/hisax/isac.c   |4 ++--
 drivers/isdn/hisax/isar.c   |6 ++---
 drivers/isdn/hisax/jade.c   |   18 --
 drivers/isdn/hisax/jade_irq.c   |4 ++--
 drivers/isdn/hisax/l3_1tr6.c|   50 ++-
 drivers/isdn/hisax/netjet.c |2 +-
 drivers/isdn/hisax/q931.c   |6 ++---
 drivers/isdn/hisax/w6692.c  |8 +++
 19 files changed, 57 insertions(+), 79 deletions(-)

diff --git a/drivers/isdn/hisax/amd7930_fn.c b/drivers/isdn/hisax/amd7930_fn.c
index 1063bab..36817e0 100644
--- a/drivers/isdn/hisax/amd7930_fn.c
+++ b/drivers/isdn/hisax/amd7930_fn.c
@@ -314,7 +314,7 @@ Amd7930_empty_Dfifo(struct IsdnCardState *cs, int flag)
 
t += sprintf(t, 
"Amd7930: empty_Dfifo cnt: %d |", cs->rcvidx);
QuickHex(t, cs->rcvbuf, 
cs->rcvidx);
-   debugl1(cs, cs->dlog);
+   debugl1(cs, "%s", 
cs->dlog);
}
/* moves received data in 
sk-buffer */
memcpy(skb_put(skb, 
cs->rcvidx), cs->rcvbuf, cs->rcvidx);
@@ -406,7 +406,7 @@ Amd7930_fill_Dfifo(struct IsdnCardState *cs)
 
t += sprintf(t, "Amd7930: fill_Dfifo cnt: %d |", count);
QuickHex(t, deb_ptr, count);
-   debugl1(cs, cs->dlog);
+   debugl1(cs, "%s", cs->dlog);
}
/* AMD interrupts on */
AmdIrqOn(cs);
diff --git a/drivers/isdn/hisax/avm_pci.c b/drivers/isdn/hisax/avm_pci.c
index ee9b9a0..d1427bd 100644
--- a/drivers/isdn/hisax/avm_pci.c
+++ b/drivers/isdn/hisax/avm_pci.c
@@ -285,7 +285,7 @@ hdlc_empty_fifo(struct BCState *bcs, int count)
t += sprintf(t, "hdlc_empty_fifo %c cnt %d",
 bcs->channel ? 'B' : 'A', count);
QuickHex(t, p, count);
-   debugl1(cs, bcs->blog);
+   debugl1(cs, "%s", bcs->blog);
}
 }
 
@@ -345,7 +345,7 @@ hdlc_fill_fifo(struct BCState *bcs)
t += sprintf(t, "hdlc_fill_fifo %c cnt %d",
 bcs->channel ? 'B' : 'A', count);
QuickHex(t, p, count);
-   debugl1(cs, bcs->blog);
+   debugl1(cs, "%s", bcs->blog);
}
 }
 
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index bf04d2a..b33f53b 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -1896,7 +1896,7 @@ static void EChannel_proc_rcv(struct hisax_d_if *d_if)
ptr--;
*ptr++ = '\n';
*ptr = 0;
-   HiSax_putstatus(cs, NULL, cs->dlog);
+   HiSax_putstatus(cs, NULL, "%s", cs->dlog);
} else
HiSax_putstatus(cs, "LogEcho: ",
"warning Frame too big (%d)",
diff --git a/drivers/isdn/hisax/diva.c b/drivers/isdn/hisax/diva.c
index 8d0cf6e..4fc90de6 100644
--- a/drivers/isdn/hisax/diva.c
+++ b/drivers/isdn/hisax/diva.c
@@ -427,7 +427,7 @@ Memhscx_empty_fifo(struct BCState *bcs, int count)
t += sprintf(t, "hscx_empty_fifo %c cnt %d",
 bcs->hw.hscx.hscx ? 'B' : 'A', count);
QuickHex(t, ptr, count);
-   debugl1(cs, bcs->blog);
+   debugl1(cs, "%s", bcs->blog);
}
 }
 
@@ -469,7 +469,7 @@ Memhscx_fill_fifo(struct BCState *bcs)
t += sprintf(t, "hscx_fill_fifo %c cnt %d",
 bcs->hw.hscx.hscx ? 'B' : 'A', count);
QuickHex(t, ptr, count);
-   debugl1(cs, bcs->blog);
+   debugl1(cs, "%s", bcs->blog);
}
 }
 
diff --git a/drivers/isdn/hisax/elsa.c b/drivers/isdn/hisax/elsa.c
index 1df6f9a..2be1c8a 100644
--- a/drivers/isdn/hisax/elsa.c
+++ b/drivers/isdn/hisax/elsa.c
@@ -535,7 +535,7 @@ check_arcofi(struct IsdnCardState *cs)
t = tmp

Re: [PATCH v2 5/8] pinctrl: add pinctrl driver for Rockchip SoCs

[Heiko Stübner]

Am Samstag, 8. Juni 2013, 01:13:48 schrieb Heiko Stübner:
> Am Freitag, 7. Juni 2013, 14:53:51 schrieb Linus Walleij:
> > On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner  wrote:
> > > +   for (i = 0, j = 0; i < size; i += 4, j++) {
> > > +   unsigned long pinconf;
> > > +
> > > +   num = be32_to_cpu(*list++);
> > > +   bank = bank_num_to_bank(info, num);
> > > +   if (IS_ERR(bank))
> > > +   return PTR_ERR(bank);
> > > +
> > > +   pin = be32_to_cpu(*list++);
> > > +   grp->pins[j] = bank->pin_base + pin;
> > > +   grp->func[j] = be32_to_cpu(*list++);
> > > +
> > > +   pinconf = be32_to_cpu(*list++);
> > > +   switch(pinconf) {
> > > +   case RK_PINCTRL_NONE:
> > > +   bias = PIN_CONFIG_BIAS_DISABLE;
> > > +   break;
> > > +   case RK_PINCTRL_PULL_PIN_DEFAULT:
> > > +   bias = PIN_CONFIG_BIAS_PULL_PIN_DEFAULT;
> > > +   break;
> > > +   case RK_PINCTRL_PULL_UP:
> > > +   bias = PIN_CONFIG_BIAS_PULL_UP;
> > > +   break;
> > > +   case RK_PINCTRL_PULL_DOWN:
> > > +   bias = PIN_CONFIG_BIAS_PULL_DOWN;
> > > +   break;
> > > +   }
> > > +
> > > +   grp->configs[j] = pinconf_to_config_packed(bias, 0);
> > > +   }
> > 
> > I would like this to be added to
> > drivers/pinctrl/pinconf-generic.c
> > as a utility function, with the header in
> > drivers/pinctrl/pinconf.h
> > 
> > Also in a separate patch.
> > 
> > > +++ b/include/dt-bindings/pinctrl/rockchip.h
> > 
> > (...)
> > 
> > > +#define RK_PINCTRL_NONE0
> > > +#define RK_PINCTRL_PULL_PIN_DEFAULT(1 << 0)
> > > +#define RK_PINCTRL_PULL_UP (1 << 1)
> > > +#define RK_PINCTRL_PULL_DOWN   (1 << 2)
> > 
> > So I'd like these moved to /include/dt-bindings/pinctrl/pinconfig.h
> > and used as a separete include. Drop the RK_* prefix as it
> > will be universal and use a PINCONFIG_* prefix instead
> > of PINCTRL_*.
> > 
> > I think that is the route we need to take.
> > 
> > Bonus if you implement more config options from
> > pinconf-generic.h but otherwise me and others will have
> > to do it.
> 
> Gah, damn me for always wanting to get bonus points ;-),
> 
> I did play around a bit with the idea you described above and came up
> with the stuff a bit below. This is in no way meant to be finished, I
> also only was able to compile test it yet, but it looks like it might
> work when I test it tomorrow.
> 
> So if possible I would just like to get a "looks halfway sane, continue"
> or "completely wrong track" please :-) :
> 
> 
> constants in dt-bindings/pinctrl/pinconfig.h:
> -
> #define PINCONFIG_NONE0
> #define PINCONFIG_BIAS_DISABLE(1 << 0)
> #define PINCONFIG_BIAS_HIGH_IMPEDANCE (1 << 1)
> #define PINCONFIG_BIAS_BUS_HOLD   (1 << 2)
> #define PINCONFIG_BIAS_PULL_PIN_DEFAULT   (1 << 3)
> #define PINCONFIG_BIAS_PULL_UP(1 << 4)
> #define PINCONFIG_BIAS_PULL_DOWN  (1 << 5)
> #define PINCONFIG_DRIVE_PUSH_PULL (1 << 6)
> #define PINCONFIG_DRIVE_OPEN_DRAIN(1 << 7)
> #define PINCONFIG_DRIVE_OPEN_SOURCE   (1 << 8)
> #define PINCONFIG_INPUT_SCHMITT_ENABLE(1 << 9)
> #define PINCONFIG_INPUT_SCHMITT_DISABLE   (1 << 10)
> #define PINCONFIG_LOW_POWER_MODE  (1 << 11)
> #define PINCONFIG_OUTPUT_LOW  (1 << 12)
> #define PINCONFIG_OUTPUT_HIGH (1 << 13)
> 
> 
> and code including how the rockchip driver could look like:
> -
> diff --git a/drivers/pinctrl/pinconf-generic.c
> b/drivers/pinctrl/pinconf-generic.c index 9a6812b..35c40be 100644
> --- a/drivers/pinctrl/pinconf-generic.c
> +++ b/drivers/pinctrl/pinconf-generic.c
> @@ -139,3 +139,61 @@ void pinconf_generic_dump_config(struct pinctrl_dev
> *pctldev, }
>  EXPORT_SYMBOL_GPL(pinconf_generic_dump_config);
>  #endif
> +
> +/*
> + * Maps the devicetree config bits to actual pinconf values.
> + * The array indizes match the bits set in dt-bindings/pinctrl/pinconf.h
> + * and the array should contain an entry for each bit defined there
> + */
> +static unsigned long conf_map[] = {
> + PIN_CONF_PACKED(PIN_CONFIG_BIAS_DISABLE, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_BIAS_HIGH_IMPEDANCE, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_BIAS_BUS_HOLD, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_DOWN, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_DRIVE_OPEN_DRAIN, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_DRIVE_OPEN_SOURCE, 0),
> + PIN_CONF_PACKED(PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1),
> + PIN_CONF_PACKED(PIN_CONFIG_INPUT_SCHM

[PATCH 3/6] device: avoid format string in dev_set_name

[Kees Cook]

Calling dev_set_name with a single paramter causes it to be handled as
a format string. Many callers are passing potentially dynamic string
content, so use "%s" in those cases to avoid any potential accidents,
including wrappers like device_create*() and bdi_register().

Signed-off-by: Kees Cook 
---
 drivers/base/attribute_container.c   |2 +-
 drivers/devfreq/devfreq.c|2 +-
 drivers/extcon/extcon-class.c|2 +-
 drivers/hsi/hsi.c|2 +-
 drivers/ide/ide-cd.c |2 +-
 drivers/ide/ide-gd.c |2 +-
 drivers/ide/ide-probe.c  |4 ++--
 drivers/ide/ide-tape.c   |2 +-
 drivers/infiniband/core/sysfs.c  |2 +-
 drivers/infiniband/hw/qib/qib_file_ops.c |2 +-
 drivers/isdn/mISDN/dsp_pipeline.c|2 +-
 drivers/mtd/mtdcore.c|2 +-
 drivers/platform/x86/wmi.c   |2 +-
 drivers/scsi/sd.c|2 +-
 drivers/staging/android/timed_output.c   |2 +-
 drivers/staging/dgrp/dgrp_sysfs.c|2 +-
 drivers/uwb/lc-dev.c |2 +-
 drivers/video/backlight/backlight.c  |2 +-
 drivers/video/backlight/lcd.c|2 +-
 drivers/video/output.c   |2 +-
 drivers/xen/xenbus/xenbus_probe.c|2 +-
 mm/backing-dev.c |5 ++---
 sound/sound_core.c   |2 +-
 23 files changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/base/attribute_container.c 
b/drivers/base/attribute_container.c
index d78b204..ecc1929 100644
--- a/drivers/base/attribute_container.c
+++ b/drivers/base/attribute_container.c
@@ -167,7 +167,7 @@ attribute_container_add_device(struct device *dev,
ic->classdev.parent = get_device(dev);
ic->classdev.class = cont->class;
cont->class->dev_release = attribute_container_release;
-   dev_set_name(&ic->classdev, dev_name(dev));
+   dev_set_name(&ic->classdev, "%s", dev_name(dev));
if (fn)
fn(cont, dev, &ic->classdev);
else
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 3b36797..af8372f 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -477,7 +477,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
GFP_KERNEL);
devfreq->last_stat_updated = jiffies;
 
-   dev_set_name(&devfreq->dev, dev_name(dev));
+   dev_set_name(&devfreq->dev, "%s", dev_name(dev));
err = device_register(&devfreq->dev);
if (err) {
put_device(&devfreq->dev);
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 60adc04..8b77e60 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -620,7 +620,7 @@ int extcon_dev_register(struct extcon_dev *edev, struct 
device *dev)
edev->dev->class = extcon_class;
edev->dev->release = extcon_dev_release;
 
-   dev_set_name(edev->dev, edev->name ? edev->name : dev_name(dev));
+   dev_set_name(edev->dev, "%s", edev->name ? edev->name : dev_name(dev));
 
if (edev->max_supported) {
char buf[10];
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 833dd1a..66d4458 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -75,7 +75,7 @@ static void hsi_new_client(struct hsi_port *port, struct 
hsi_board_info *info)
cl->device.bus = &hsi_bus_type;
cl->device.parent = &port->device;
cl->device.release = hsi_client_release;
-   dev_set_name(&cl->device, info->name);
+   dev_set_name(&cl->device, "%s", info->name);
cl->device.platform_data = info->platform_data;
if (info->archdata)
cl->device.archdata = *info->archdata;
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 2ff6204..0b510ba 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1756,7 +1756,7 @@ static int ide_cd_probe(ide_drive_t *drive)
 
info->dev.parent = &drive->gendev;
info->dev.release = ide_cd_release;
-   dev_set_name(&info->dev, dev_name(&drive->gendev));
+   dev_set_name(&info->dev, "%s", dev_name(&drive->gendev));
 
if (device_register(&info->dev))
goto out_free_disk;
diff --git a/drivers/ide/ide-gd.c b/drivers/ide/ide-gd.c
index de86631..838996a 100644
--- a/drivers/ide/ide-gd.c
+++ b/drivers/ide/ide-gd.c
@@ -392,7 +392,7 @@ static int ide_gd_probe(ide_drive_t *drive)
 
idkp->dev.parent = &drive->gendev;
idkp->dev.release = ide_disk_release;
-   dev_set_name(&idkp->dev, dev_name(&drive->gendev));
+   dev_set_name(&idkp->dev, "%s", dev_name(&drive->gendev));
 
if (device_register(&idkp->dev))
goto out_free_disk;
diff --git a/drivers/ide/ide

[PATCH 2/6] crypto: sanitize argument for format string

[Kees Cook]

The template lookup interface does not provide a way to use format
strings, so make sure that the interface cannot be abused accidentally.

Signed-off-by: Kees Cook 
Cc: sta...@vger.kernel.org
Cc: Herbert Xu 
Cc: "David S. Miller" 
---
 crypto/algapi.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/crypto/algapi.c b/crypto/algapi.c
index 6149a6e..7a1ae87 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -495,7 +495,8 @@ static struct crypto_template 
*__crypto_lookup_template(const char *name)
 
 struct crypto_template *crypto_lookup_template(const char *name)
 {
-   return try_then_request_module(__crypto_lookup_template(name), name);
+   return try_then_request_module(__crypto_lookup_template(name), "%s",
+  name);
 }
 EXPORT_SYMBOL_GPL(crypto_lookup_template);
 
-- 
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 4/6] workqueue: avoid format strings in names

[Kees Cook]

For the workqueue creation interfaces that do not expect format strings,
make sure they cannot accidently be parsed that way. Additionally, clean
up calls made with a single parameter that would be handled as a format
string. Many callers are passing potentially dynamic string content,
so use "%s" in those cases to avoid any potential accidents.

Signed-off-by: Kees Cook 
---
 crypto/pcrypt.c |4 ++--
 drivers/media/pci/cx18/cx18-driver.c|2 +-
 drivers/message/i2o/driver.c|4 ++--
 drivers/net/wireless/rt2x00/rt2x00dev.c |2 +-
 drivers/net/wireless/rtlwifi/base.c |2 +-
 drivers/pci/hotplug/pciehp_hpc.c|4 +---
 drivers/pci/hotplug/shpchp_core.c   |3 +--
 drivers/scsi/be2iscsi/be_main.c |2 +-
 drivers/scsi/qla4xxx/ql4_os.c   |4 ++--
 drivers/scsi/scsi_transport_fc.c|6 +++---
 include/linux/workqueue.h   |7 ---
 net/bluetooth/hci_core.c|9 -
 net/mac80211/main.c |2 +-
 13 files changed, 24 insertions(+), 27 deletions(-)

diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c
index b2c99dc..f8c920c 100644
--- a/crypto/pcrypt.c
+++ b/crypto/pcrypt.c
@@ -455,8 +455,8 @@ static int pcrypt_init_padata(struct padata_pcrypt *pcrypt,
 
get_online_cpus();
 
-   pcrypt->wq = alloc_workqueue(name,
-WQ_MEM_RECLAIM | WQ_CPU_INTENSIVE, 1);
+   pcrypt->wq = alloc_workqueue("%s", WQ_MEM_RECLAIM | WQ_CPU_INTENSIVE,
+1, name);
if (!pcrypt->wq)
goto err;
 
diff --git a/drivers/media/pci/cx18/cx18-driver.c 
b/drivers/media/pci/cx18/cx18-driver.c
index 67b61cf..004d8ac 100644
--- a/drivers/media/pci/cx18/cx18-driver.c
+++ b/drivers/media/pci/cx18/cx18-driver.c
@@ -695,7 +695,7 @@ static int cx18_create_in_workq(struct cx18 *cx)
 {
snprintf(cx->in_workq_name, sizeof(cx->in_workq_name), "%s-in",
 cx->v4l2_dev.name);
-   cx->in_work_queue = alloc_ordered_workqueue(cx->in_workq_name, 0);
+   cx->in_work_queue = alloc_ordered_workqueue("%s", 0, cx->in_workq_name);
if (cx->in_work_queue == NULL) {
CX18_ERR("Unable to create incoming mailbox handler thread\n");
return -ENOMEM;
diff --git a/drivers/message/i2o/driver.c b/drivers/message/i2o/driver.c
index 8a5b2d8..813eaa3 100644
--- a/drivers/message/i2o/driver.c
+++ b/drivers/message/i2o/driver.c
@@ -84,8 +84,8 @@ int i2o_driver_register(struct i2o_driver *drv)
osm_debug("Register driver %s\n", drv->name);
 
if (drv->event) {
-   drv->event_queue = alloc_workqueue(drv->name,
-  WQ_MEM_RECLAIM, 1);
+   drv->event_queue = alloc_workqueue("%s", WQ_MEM_RECLAIM, 1,
+  drv->name);
if (!drv->event_queue) {
osm_err("Could not initialize event queue for driver "
"%s\n", drv->name);
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c 
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 90dc143..c8b9ef0 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -1321,7 +1321,7 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
 * Initialize work.
 */
rt2x00dev->workqueue =
-   alloc_ordered_workqueue(wiphy_name(rt2x00dev->hw->wiphy), 0);
+   alloc_ordered_workqueue("%s", 0, wiphy_name(rt2x00dev->hw->wiphy));
if (!rt2x00dev->workqueue) {
retval = -ENOMEM;
goto exit;
diff --git a/drivers/net/wireless/rtlwifi/base.c 
b/drivers/net/wireless/rtlwifi/base.c
index af59dd5..a5f2231 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -380,7 +380,7 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
 
/* <2> work queue */
rtlpriv->works.hw = hw;
-   rtlpriv->works.rtl_wq = alloc_workqueue(rtlpriv->cfg->name, 0, 0);
+   rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
INIT_DELAYED_WORK(&rtlpriv->works.watchdog_wq,
  (void *)rtl_watchdog_wq_callback);
INIT_DELAYED_WORK(&rtlpriv->works.ips_nic_off_wq,
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 5127f3f..b225573 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -773,14 +773,12 @@ static void pcie_shutdown_notification(struct controller 
*ctrl)
 static int pcie_init_slot(struct controller *ctrl)
 {
struct slot *slot;
-   char name[32];
 
slot = kzalloc(sizeof(*slot), GFP_KERNEL);
if (!slot)
return -ENOMEM;
 
-   snprintf(name, sizeof(name), "pciehp-%u", PSN(ctrl));
-   slot->wq = alloc_workqueue(name, 0, 0)

[PATCH 5/6] kthread: avoid parsing names as format strings

[Kees Cook]

Calling kthread_run with a single name parameter causes it to be handled
as a format string. Many callers are passing potentially dynamic string
content, so use "%s" in those cases to avoid any potential accidents.

Signed-off-by: Kees Cook 
---
 drivers/block/aoe/aoecmd.c   |2 +-
 drivers/block/mtip32xx/mtip32xx.c|3 ++-
 drivers/block/xen-blkback/xenbus.c   |2 +-
 drivers/hwmon/adt7470.c  |2 +-
 drivers/media/i2c/tvaudio.c  |3 ++-
 drivers/media/pci/ivtv/ivtv-driver.c |2 +-
 drivers/media/platform/vivi.c|3 ++-
 drivers/mtd/ubi/build.c  |2 +-
 drivers/net/wireless/airo.c  |3 ++-
 drivers/scsi/aacraid/commctrl.c  |3 ++-
 drivers/scsi/aacraid/commsup.c   |3 ++-
 drivers/spi/spi.c|2 +-
 drivers/staging/rtl8712/os_intfs.c   |2 +-
 drivers/usb/atm/usbatm.c |5 +++--
 fs/lockd/svc.c   |2 +-
 fs/nfs/callback.c|5 ++---
 fs/nfs/nfs4state.c   |2 +-
 kernel/rcutree.c |2 +-
 net/sunrpc/svc.c |2 +-
 19 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
index fc803ec..b75c7db 100644
--- a/drivers/block/aoe/aoecmd.c
+++ b/drivers/block/aoe/aoecmd.c
@@ -1340,7 +1340,7 @@ aoe_ktstart(struct ktstate *k)
struct task_struct *task;
 
init_completion(&k->rendez);
-   task = kthread_run(kthread, k, k->name);
+   task = kthread_run(kthread, k, "%s", k->name);
if (task == NULL || IS_ERR(task))
return -ENOMEM;
k->task = task;
diff --git a/drivers/block/mtip32xx/mtip32xx.c 
b/drivers/block/mtip32xx/mtip32xx.c
index 847107e..81ce4c0 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -4085,7 +4085,8 @@ skip_create_disk:
 start_service_thread:
sprintf(thd_name, "mtip_svc_thd_%02d", index);
dd->mtip_svc_handler = kthread_create_on_node(mtip_service_thread,
-   dd, dd->numa_node, thd_name);
+   dd, dd->numa_node, "%s",
+   thd_name);
 
if (IS_ERR(dd->mtip_svc_handler)) {
dev_err(&dd->pdev->dev, "service thread failed to start\n");
diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 8bfd1bc..04608a6 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -93,7 +93,7 @@ static void xen_update_blkif_status(struct xen_blkif *blkif)
}
invalidate_inode_pages2(blkif->vbd.bdev->bd_inode->i_mapping);
 
-   blkif->xenblkd = kthread_run(xen_blkif_schedule, blkif, name);
+   blkif->xenblkd = kthread_run(xen_blkif_schedule, blkif, "%s", name);
if (IS_ERR(blkif->xenblkd)) {
err = PTR_ERR(blkif->xenblkd);
blkif->xenblkd = NULL;
diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
index b83bf4b..0f34bca 100644
--- a/drivers/hwmon/adt7470.c
+++ b/drivers/hwmon/adt7470.c
@@ -1285,7 +1285,7 @@ static int adt7470_probe(struct i2c_client *client,
}
 
init_completion(&data->auto_update_stop);
-   data->auto_update = kthread_run(adt7470_update_thread, client,
+   data->auto_update = kthread_run(adt7470_update_thread, client, "%s",
dev_name(data->hwmon_dev));
if (IS_ERR(data->auto_update)) {
err = PTR_ERR(data->auto_update);
diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c
index b72a59d..e0634c8 100644
--- a/drivers/media/i2c/tvaudio.c
+++ b/drivers/media/i2c/tvaudio.c
@@ -2020,7 +2020,8 @@ static int tvaudio_probe(struct i2c_client *client, const 
struct i2c_device_id *
/* start async thread */
chip->wt.function = chip_thread_wake;
chip->wt.data = (unsigned long)chip;
-   chip->thread = kthread_run(chip_thread, chip, client->name);
+   chip->thread = kthread_run(chip_thread, chip, "%s",
+  client->name);
if (IS_ERR(chip->thread)) {
v4l2_warn(sd, "failed to create kthread\n");
chip->thread = NULL;
diff --git a/drivers/media/pci/ivtv/ivtv-driver.c 
b/drivers/media/pci/ivtv/ivtv-driver.c
index 07b8460..b809bc8 100644
--- a/drivers/media/pci/ivtv/ivtv-driver.c
+++ b/drivers/media/pci/ivtv/ivtv-driver.c
@@ -753,7 +753,7 @@ static int ivtv_init_struct1(struct ivtv *itv)
 
init_kthread_worker(&itv->irq_worker);
itv->irq_worker_task = kthread_run(kthread_worker_fn, &itv->irq_worker,
-  itv->v4l2_dev.name);
+  "%s", itv->v4l2_dev.name);
if (

[PATCH 1/6] block: do not pass disk names as format strings

[Kees Cook]

Disk names may contain arbitrary strings, so they must not be interpreted
as format strings. It seems that only md allows arbitrary strings to be
used for disk names, but this could allow for a local memory corruption
from uid 0 into ring 0.

CVE-2013-2851

Signed-off-by: Kees Cook 
Cc: sta...@vger.kernel.org
Cc: Jens Axboe 
---
 block/genhd.c  |2 +-
 drivers/block/nbd.c|3 ++-
 drivers/scsi/osd/osd_uld.c |2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 20625ee..cdeb527 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -512,7 +512,7 @@ static void register_disk(struct gendisk *disk)
 
ddev->parent = disk->driverfs_dev;
 
-   dev_set_name(ddev, disk->disk_name);
+   dev_set_name(ddev, "%s", disk->disk_name);
 
/* delay uevents, until we scanned partition table */
dev_set_uevent_suppress(ddev, 1);
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 037288e..46b35f7 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -714,7 +714,8 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
nbd_device *nbd,
else
blk_queue_flush(nbd->disk->queue, 0);
 
-   thread = kthread_create(nbd_thread, nbd, nbd->disk->disk_name);
+   thread = kthread_create(nbd_thread, nbd, "%s",
+   nbd->disk->disk_name);
if (IS_ERR(thread)) {
mutex_lock(&nbd->tx_lock);
return PTR_ERR(thread);
diff --git a/drivers/scsi/osd/osd_uld.c b/drivers/scsi/osd/osd_uld.c
index 0fab6b5..9d86947 100644
--- a/drivers/scsi/osd/osd_uld.c
+++ b/drivers/scsi/osd/osd_uld.c
@@ -485,7 +485,7 @@ static int osd_probe(struct device *dev)
oud->class_dev.class = &osd_uld_class;
oud->class_dev.parent = dev;
oud->class_dev.release = __remove;
-   error = dev_set_name(&oud->class_dev, disk->disk_name);
+   error = dev_set_name(&oud->class_dev, "%s", disk->disk_name);
if (error) {
OSD_ERR("dev_set_name failed => %d\n", error);
goto err_put_cdev;
-- 
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 v2 0/6] format string usage clean ups

[Kees Cook]

Version 2 of this series. Originally: https://lkml.org/lkml/2013/6/6/614

Changes:
 - "power: ensure event is not used as format string" taken by maintainer.
 - "kobject: sanitize argument for format string" taken by maintainer.
 - "device: avoid format string in dev_set_name" fixed for newly uncovered
   additional error in format string.
 - "isdn: clean up debug format string usage" accidental dev_set_name
   revert chunk dropped.

Thanks,

-Kees

--
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/workqueue.c:4435:61: sparse: expression using sizeof bool

[Fengguang Wu]

On Fri, Jun 07, 2013 at 03:03:51PM -0700, Tejun Heo wrote:
> On Fri, Jun 07, 2013 at 02:15:21PM -0700, Andrew Morton wrote:
> > >   4434/* copy worker description */
> > > > 4435probe_kernel_read(&desc_valid, &worker->desc_valid, 
> > > > sizeof(desc_valid));
> > 
> > I don't understand the rationale for the sparse test, really.  This
> > code seems unproblematic.
> 
> Yeah, I've gotten that warning a couple times now and am just ignoring
> it at this point.  Maybe the standard says bool isn't a proper
> integeral type and its size isn't precisely defined or something?  I
> don't know.

Hmm, I'd better disable the warnings that are normally ignored anyway..

Thanks,
Fengguang
--
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: adjusting the monotonic system time (from inside the kernel)

[John Stultz]

On 05/06/2013 07:02 AM, Alexander Holler wrote:

Hello,

I'm looking at how to adjust the (monotonic) system time from inside 
the kernel.


Use case is that I have a hw-clock which (not necessarily) regulary 
sends a timestamp with millisecond precision which I want to use to 
adjust the system time.


It seems the usual solution to do such, is to use NTP which uses it's 
own driver (which usually seems to be based on some serial connection):


hw-clock --serial--> kernel --serial-device--> ntpd -> kernel -> 
system-time


So one solution would be to emulate such a serial device:

hw-clock --> kernel --emulated-serial-device--> ntpd -> kernel -> 
system-time


Another solution would be to "invent" a ntp-device and write a driver 
for ntpd to use it:


hw-clock --> kernel --ntp-device--> ntpd -> kernel -> system-time

But I would prefer the following:

hw-clock --> kernel -> system-time

Problem is that the hw-clock in question doesn't offer something like 
a tick. It just might send a timestamp with millisecond precision 
whenever it wants.


Because I don't want to reinvent the wheel and because I think there 
are some people which already have spend some thoughts on similiar 
things, I'm asking here before I try to implement something which then 
never might find it's way into the mainline kernel.


Any hints, suggestions, whatever?


Sorry on the delay to reply here, just noticed this in my spam folder 
(hopefully I've trained it not to catch your mails now).


You probably want to check out do_adjtimex() in the kernel. It has a 
number of ways that allow for the clock to be slewed or jumped. 
Otherwise you probably should look into the PPS subsystems to see if it 
could be extended to support your needs.


thanks
-john


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

acpi_sba_ioc_driver breakage (was: Re: [GIT PULL] Power management and ACPI fixes for v3.10-rc5)

[Rafael J. Wysocki]

On Friday, June 07, 2013 04:02:11 PM Tony Luck wrote:
> On Fri, Jun 7, 2013 at 3:23 PM, Tony Luck  wrote:
> > So please don't pull.
> 
> Bother. I see I was a few hours late finding this, and commit 9f29ab11ddb
> is already in Linus' tree.
> 
> That's what happens when I get busy and skip a couple of days testing
> linux-next :-(
> 
> So my problem comes from
> arch/ia64/hp/common/sba_iommu.c
> 
> where the code in sba_init() says:
> 
> acpi_bus_register_driver(&acpi_sba_ioc_driver);
> if (!ioc_list) {
> 
> but because of this change we never managed to call ioc_init()
> so ioc_list doesn't get set up, and we die.
> Before this commit, the call chain looked like this:
> 
>  [] ioc_init+0x40/0xd00
>  [] acpi_sba_ioc_add+0x190/0x1c0
>  [] acpi_device_probe+0xa0/0x280
>  [] really_probe+0xe0/0x520
>  [] driver_probe_device+0x30/0x60
>  [] __driver_attach+0x110/0x160
>  [] bus_for_each_dev+0x110/0x180
>  [] driver_attach+0x40/0x60
>  [] bus_add_driver+0x230/0x580
>  [] driver_register+0xf0/0x400
>  [] acpi_bus_register_driver+0x50/0x80
>  [] sba_init+0x30/0x2d0
> 
> Is my problem that this driver has (or attaches) a "scan handler"
> where it shouldn't ... and I just need to stop it doing that?

The driver doesn't, but the device it attempts to bind to does.
It looks like that device object has multiple device IDs and one of them
matches one of the existing ACPI scan handlers, but I need a confirmation.

Can you please send me the output of

$ find /sys/devices/LNXSYSTM\:00/ -name modalias -print -exec cat {} \;

from the affected system?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, 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 RFC V9 0/19] Paravirtualized ticket spinlocks

[Jiannan Ouyang]

Raghu, thanks for you input. I'm more than glad to work together with
you to make this idea work better.

-Jiannan

On Thu, Jun 6, 2013 at 11:15 PM, Raghavendra K T
 wrote:
> On 06/03/2013 11:51 AM, Raghavendra K T wrote:
>>
>> On 06/03/2013 07:10 AM, Raghavendra K T wrote:
>>>
>>> On 06/02/2013 09:50 PM, Jiannan Ouyang wrote:

 On Sun, Jun 2, 2013 at 1:07 AM, Gleb Natapov  wrote:

> High level question here. We have a big hope for "Preemptable Ticket
> Spinlock" patch series by Jiannan Ouyang to solve most, if not all,
> ticketing spinlocks in overcommit scenarios problem without need for
> PV.
> So how this patch series compares with his patches on PLE enabled
> processors?
>

 No experiment results yet.

 An error is reported on a 20 core VM. I'm during an internship
 relocation, and will start work on it next week.
>>>
>>>
>>> Preemptable spinlocks' testing update:
>>> I hit the same softlockup problem while testing on 32 core machine with
>>> 32 guest vcpus that Andrew had reported.
>>>
>>> After that i started tuning TIMEOUT_UNIT, and when I went till (1<<8),
>>> things seemed to be manageable for undercommit cases.
>>> But I still see degradation for undercommit w.r.t baseline itself on 32
>>> core machine (after tuning).
>>>
>>> (37.5% degradation w.r.t base line).
>>> I can give the full report after the all tests complete.
>>>
>>> For over-commit cases, I again started hitting softlockups (and
>>> degradation is worse). But as I said in the preemptable thread, the
>>> concept of preemptable locks looks promising (though I am still not a
>>> fan of  embedded TIMEOUT mechanism)
>>>
>>> Here is my opinion of TODOs for preemptable locks to make it better ( I
>>> think I need to paste in the preemptable thread also)
>>>
>>> 1. Current TIMEOUT UNIT seem to be on higher side and also it does not
>>> scale well with large guests and also overcommit. we need to have a
>>> sort of adaptive mechanism and better is sort of different TIMEOUT_UNITS
>>> for different types of lock too. The hashing mechanism that was used in
>>> Rik's spinlock backoff series fits better probably.
>>>
>>> 2. I do not think TIMEOUT_UNIT itself would work great when we have a
>>> big queue (for large guests / overcommits) for lock.
>>> one way is to add a PV hook that does yield hypercall immediately for
>>> the waiters above some THRESHOLD so that they don't burn the CPU.
>>> ( I can do POC to check if  that idea works in improving situation
>>> at some later point of time)
>>>
>>
>> Preemptable-lock results from my run with 2^8 TIMEOUT:
>>
>> +---+---+---++---+
>>   ebizzy (records/sec) higher is better
>> +---+---+---++---+
>>  basestdevpatchedstdev%improvement
>> +---+---+---++---+
>> 1x  5574.9000   237.49973484.2000   113.4449   -37.50202
>> 2x  2741.5000   561.3090 351.5000   140.5420   -87.17855
>> 3x  2146.2500   216.7718 194.833385.0303   -90.92215
>> 4x  1663.   141.9235 101.57.7853   -93.92664
>> +---+---+---++---+
>> +---+---+---++---+
>> dbench  (Throughput) higher is better
>> +---+---+---++---+
>>   basestdevpatchedstdev%improvement
>> +---+---+---++---+
>> 1x  14111.5600   754.4525   3930.1602   2547.2369-72.14936
>> 2x  2481.627071.2665  181.181689.5368-92.69908
>> 3x  1510.248331.8634  104.724353.2470-93.06576
>> 4x  1029.487516.9166   72.373838.2432-92.96992
>> +---+---+---++---+
>>
>> Note we can not trust on overcommit results because of softlock-ups
>>
>
> Hi, I tried
> (1) TIMEOUT=(2^7)
>
> (2) having yield hypercall that uses kvm_vcpu_on_spin() to do directed yield
> to other vCPUs.
>
> Now I do not see any soft-lockup in overcommit cases and results are better
> now (except ebizzy 1x). and for dbench I see now it is closer to base and
> even improvement in 4x
>
>
> +---+---+---++---+
>ebizzy (records/sec) higher is better
> +---+---+---++---+
>   basestdevpatchedstdev%improvement
> +---+---+---++---+
>   5574.9000   237.4997 523.7000 1.4181   -90.60611
>   2741.5000   561.3090 597.800034.9755   -78.19442
>   2146.2500   216.7718 902.666782.4228   -57.94215
>   1663.   141.92351245.67.2989   -25.13530
>
> +---+---+---++---+
> +---+---+---+-

Re: [PATCH 20/31] mips/kvm: Hook into TLB fault handlers.

[Sergei Shtylyov]

Hello.

On 06/08/2013 03:03 AM, David Daney wrote:


From: David Daney 

If the CPU is operating in guest mode when a TLB related excpetion
occurs, give KVM a chance to do emulation.

Signed-off-by: David Daney 
---
  arch/mips/mm/fault.c   | 8 
  arch/mips/mm/tlbex-fault.S | 6 ++
  2 files changed, 14 insertions(+)

diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index 0fead53..9391da49 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c

[...]

@@ -50,6 +51,13 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs 
*regs, unsigned long writ
   field, regs->cp0_epc);
  #endif
  
+#ifdef CONFIG_KVM_MIPSVZ

+   if (test_tsk_thread_flag(current, TIF_GUESTMODE)) {
+   if (mipsvz_page_fault(regs, write, address))


   Any reason not to collapse these into single *if*?


+   return;
+   }
+#endif
+



--
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: race condition in schedule_on_each_cpu()

[Tejun Heo]

On Fri, Jun 07, 2013 at 10:24:50AM +0800, we...@kylinos.com.cn wrote:
> >Before the commit you originally quoted, the calling thread could be
> preempted and migrated to another CPU before get_online_cpus() thus
> ending up executing the function twice on the new cpu but skipping the
> old one.
> 
> does this situation will happen in "Full preemption" config, on 3.0.30-rt50?

Sure, if the fix hasn't been backported.

Thanks.

-- 
tejun
--
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: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

[luke.leighton]

On Sat, Jun 8, 2013 at 12:09 AM, Dennis Lan (dlan)
 wrote:
>
>
> On Saturday, June 8, 2013, luke.leighton wrote:
>>
>> right - too many people contributed to this, input from jon smirl,
>> wookie, maxime, tomasz, henrik, i've made a start here and will
>> continue editing: this is notes for me to put forward an agenda for
>> discussion:
>>
>> http://hands.com/~lkcl/allwinner_linux_proposal.txt
>>
>> i'm setting a rule that each section *has* to have a list of clear
>> benefits, otherwise it'll have to be removed before it goes on to
>> their Directors.
>>
>> so - even if there are any allwinner engineers reading this who would
>> like something put forward please also speak up! :)
>>
>> l.
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> Hi luke
>  I'm not a allwinner employer :-)$. but pretty much in the same position
> as they are.

 thanks for chipping in.

>  I'd like to add a few comments about the risk of adopting the device
> tree(from allwinner side)
> 1) current using fdt in bootloader(uboot) is not mature, I'm not saying
> about passing the fdt data to kernel.

  fdt.  could you provide some context here?  what is it?
(apart from being a TLA)

>   But the bootloader itself need information from device tree, say boot0/1
> phase (boot device type, DDR initialization...)
>   since fdt is not ready, and SRAM space is very limited ... I'm afraid
> 'fex' may co-exist with device tree.
>   still, they receive benefits if they can adopt device tree, at least
> minimal the kernel side migration effort
>   Generally this info already been pointed out by steppen warren in previous
> email...

 ... which i have to admit i may have missed the significance of or
possibly just missed it entirely.

 what's the main concern you have, here; what's the potential
solution, and what's the benefit of that potential solution, to
allwinner [direct or indirect]?

> 2) device tree may not been understood by third vendors (who previus produce
> shoes or ? :-$),

 :)

>   they are real old 'Fex' scheme user, they like edit the data in windows
> with dos format
>   So, how to fill this gaps, make them happy? Creat another tool to handle
> device tree modification?
>   Then it's another price they have to pay...

 yehh... that kinda looks unavoidable, although it would ultimately
only inconvenience the developers of the proprietary firmware-flashing
tools [livesuite, phoenix] and so would be transparent to the
factories and so on.  i've mentioned the idea of having an in-kernel
translation tool rather than an external (pre-runtime) one, i've yet
to get some feedback on that.

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

[PATCH 05/31] mips/kvm: Use generic cache flushing functions.

[David Daney]

From: David Daney 

We don't know if we have the r4k specific functions available, so use
universally available __flush_cache_all() instead.  This takes longer
as it flushes both i-cache and d-cache, but is available for all CPUs.

Signed-off-by: David Daney 
---
 arch/mips/kvm/kvm_mips_emul.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/mips/kvm/kvm_mips_emul.c b/arch/mips/kvm/kvm_mips_emul.c
index af9a661..a2c6687 100644
--- a/arch/mips/kvm/kvm_mips_emul.c
+++ b/arch/mips/kvm/kvm_mips_emul.c
@@ -916,8 +916,6 @@ kvm_mips_emulate_cache(uint32_t inst, uint32_t *opc, 
uint32_t cause,
   struct kvm_run *run, struct kvm_vcpu *vcpu)
 {
struct mips_coproc *cop0 = vcpu->arch.cop0;
-   extern void (*r4k_blast_dcache) (void);
-   extern void (*r4k_blast_icache) (void);
enum emulation_result er = EMULATE_DONE;
int32_t offset, cache, op_inst, op, base;
struct kvm_vcpu_arch *arch = &vcpu->arch;
@@ -954,9 +952,9 @@ kvm_mips_emulate_cache(uint32_t inst, uint32_t *opc, 
uint32_t cause,
 arch->gprs[base], offset);
 
if (cache == MIPS_CACHE_DCACHE)
-   r4k_blast_dcache();
+   __flush_cache_all();
else if (cache == MIPS_CACHE_ICACHE)
-   r4k_blast_icache();
+   __flush_cache_all();
else {
printk("%s: unsupported CACHE INDEX operation\n",
   __func__);
-- 
1.7.11.7

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

[PATCH 04/31] mips/kvm: Add casts to avoid pointer width mismatch build failures.

[David Daney]

From: David Daney 

When building for 64-bits we need these cases to make it build.

Signed-off-by: David Daney 
---
 arch/mips/kvm/kvm_mips.c  | 4 ++--
 arch/mips/kvm/kvm_mips_dyntrans.c | 4 ++--
 arch/mips/kvm/kvm_mips_emul.c | 2 +-
 arch/mips/kvm/kvm_tlb.c   | 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index d934b01..6018e2a 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
@@ -303,7 +303,7 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, 
unsigned int id)
}
 
/* Save Linux EBASE */
-   vcpu->arch.host_ebase = (void *)read_c0_ebase();
+   vcpu->arch.host_ebase = (void *)(long)(read_c0_ebase() & 0x3ff);
 
gebase = kzalloc(ALIGN(size, PAGE_SIZE), GFP_KERNEL);
 
@@ -339,7 +339,7 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, 
unsigned int id)
offset = 0x2000;
kvm_info("Installing KVM Exception handlers @ %p, %#x bytes\n",
 gebase + offset,
-mips32_GuestExceptionEnd - mips32_GuestException);
+(unsigned)(mips32_GuestExceptionEnd - mips32_GuestException));
 
memcpy(gebase + offset, mips32_GuestException,
   mips32_GuestExceptionEnd - mips32_GuestException);
diff --git a/arch/mips/kvm/kvm_mips_dyntrans.c 
b/arch/mips/kvm/kvm_mips_dyntrans.c
index 96528e2..dd0b8f9 100644
--- a/arch/mips/kvm/kvm_mips_dyntrans.c
+++ b/arch/mips/kvm/kvm_mips_dyntrans.c
@@ -94,7 +94,7 @@ kvm_mips_trans_mfc0(uint32_t inst, uint32_t *opc, struct 
kvm_vcpu *vcpu)
  cop0);
}
 
-   if (KVM_GUEST_KSEGX(opc) == KVM_GUEST_KSEG0) {
+   if (KVM_GUEST_KSEGX((unsigned long)opc) == KVM_GUEST_KSEG0) {
kseg0_opc =
CKSEG0ADDR(kvm_mips_translate_guest_kseg0_to_hpa
   (vcpu, (unsigned long) opc));
@@ -129,7 +129,7 @@ kvm_mips_trans_mtc0(uint32_t inst, uint32_t *opc, struct 
kvm_vcpu *vcpu)
offsetof(struct mips_coproc,
 reg[rd][sel]) + offsetof(struct kvm_mips_commpage, cop0);
 
-   if (KVM_GUEST_KSEGX(opc) == KVM_GUEST_KSEG0) {
+   if (KVM_GUEST_KSEGX((unsigned long)opc) == KVM_GUEST_KSEG0) {
kseg0_opc =
CKSEG0ADDR(kvm_mips_translate_guest_kseg0_to_hpa
   (vcpu, (unsigned long) opc));
diff --git a/arch/mips/kvm/kvm_mips_emul.c b/arch/mips/kvm/kvm_mips_emul.c
index 4b6274b..af9a661 100644
--- a/arch/mips/kvm/kvm_mips_emul.c
+++ b/arch/mips/kvm/kvm_mips_emul.c
@@ -892,7 +892,7 @@ int kvm_mips_sync_icache(unsigned long va, struct kvm_vcpu 
*vcpu)
pfn = kvm->arch.guest_pmap[gfn];
pa = (pfn << PAGE_SHIFT) | offset;
 
-   printk("%s: va: %#lx, unmapped: %#x\n", __func__, va, CKSEG0ADDR(pa));
+   printk("%s: va: %#lx, unmapped: %#lx\n", __func__, va, CKSEG0ADDR(pa));
 
mips32_SyncICache(CKSEG0ADDR(pa), 32);
return 0;
diff --git a/arch/mips/kvm/kvm_tlb.c b/arch/mips/kvm/kvm_tlb.c
index c777dd3..5e189be 100644
--- a/arch/mips/kvm/kvm_tlb.c
+++ b/arch/mips/kvm/kvm_tlb.c
@@ -353,7 +353,7 @@ int kvm_mips_handle_commpage_tlb_fault(unsigned long 
badvaddr,
unsigned long entrylo0 = 0, entrylo1 = 0;
 
 
-   pfn0 = CPHYSADDR(vcpu->arch.kseg0_commpage) >> PAGE_SHIFT;
+   pfn0 = CPHYSADDR((unsigned long)vcpu->arch.kseg0_commpage) >> 
PAGE_SHIFT;
pfn1 = 0;
entrylo0 = mips3_paddr_to_tlbpfn(pfn0 << PAGE_SHIFT) | (0x3 << 3) | (1 
<< 2) |
(0x1 << 1);
@@ -916,7 +916,7 @@ uint32_t kvm_get_inst(uint32_t *opc, struct kvm_vcpu *vcpu)
inst = *(opc);
}
local_irq_restore(flags);
-   } else if (KVM_GUEST_KSEGX(opc) == KVM_GUEST_KSEG0) {
+   } else if (KVM_GUEST_KSEGX((unsigned long)opc) == KVM_GUEST_KSEG0) {
paddr =
kvm_mips_translate_guest_kseg0_to_hpa(vcpu,
 (unsigned long) opc);
-- 
1.7.11.7

--
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 5/8] pinctrl: add pinctrl driver for Rockchip SoCs

[Heiko Stübner]

Am Freitag, 7. Juni 2013, 14:53:51 schrieb Linus Walleij:
> On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner  wrote:
> > +   for (i = 0, j = 0; i < size; i += 4, j++) {
> > +   unsigned long pinconf;
> > +
> > +   num = be32_to_cpu(*list++);
> > +   bank = bank_num_to_bank(info, num);
> > +   if (IS_ERR(bank))
> > +   return PTR_ERR(bank);
> > +
> > +   pin = be32_to_cpu(*list++);
> > +   grp->pins[j] = bank->pin_base + pin;
> > +   grp->func[j] = be32_to_cpu(*list++);
> > +
> > +   pinconf = be32_to_cpu(*list++);
> > +   switch(pinconf) {
> > +   case RK_PINCTRL_NONE:
> > +   bias = PIN_CONFIG_BIAS_DISABLE;
> > +   break;
> > +   case RK_PINCTRL_PULL_PIN_DEFAULT:
> > +   bias = PIN_CONFIG_BIAS_PULL_PIN_DEFAULT;
> > +   break;
> > +   case RK_PINCTRL_PULL_UP:
> > +   bias = PIN_CONFIG_BIAS_PULL_UP;
> > +   break;
> > +   case RK_PINCTRL_PULL_DOWN:
> > +   bias = PIN_CONFIG_BIAS_PULL_DOWN;
> > +   break;
> > +   }
> > +
> > +   grp->configs[j] = pinconf_to_config_packed(bias, 0);
> > +   }
> 
> I would like this to be added to
> drivers/pinctrl/pinconf-generic.c
> as a utility function, with the header in
> drivers/pinctrl/pinconf.h
> 
> Also in a separate patch.
> 
> > +++ b/include/dt-bindings/pinctrl/rockchip.h
> 
> (...)
> 
> > +#define RK_PINCTRL_NONE0
> > +#define RK_PINCTRL_PULL_PIN_DEFAULT(1 << 0)
> > +#define RK_PINCTRL_PULL_UP (1 << 1)
> > +#define RK_PINCTRL_PULL_DOWN   (1 << 2)
> 
> So I'd like these moved to /include/dt-bindings/pinctrl/pinconfig.h
> and used as a separete include. Drop the RK_* prefix as it
> will be universal and use a PINCONFIG_* prefix instead
> of PINCTRL_*.
> 
> I think that is the route we need to take.
> 
> Bonus if you implement more config options from
> pinconf-generic.h but otherwise me and others will have
> to do it.

Gah, damn me for always wanting to get bonus points ;-),

I did play around a bit with the idea you described above and came up
with the stuff a bit below. This is in no way meant to be finished, I
also only was able to compile test it yet, but it looks like it might
work when I test it tomorrow.

So if possible I would just like to get a "looks halfway sane, continue"
or "completely wrong track" please :-) :


constants in dt-bindings/pinctrl/pinconfig.h:
-
#define PINCONFIG_NONE  0
#define PINCONFIG_BIAS_DISABLE  (1 << 0)
#define PINCONFIG_BIAS_HIGH_IMPEDANCE   (1 << 1)
#define PINCONFIG_BIAS_BUS_HOLD (1 << 2)
#define PINCONFIG_BIAS_PULL_PIN_DEFAULT (1 << 3)
#define PINCONFIG_BIAS_PULL_UP  (1 << 4)
#define PINCONFIG_BIAS_PULL_DOWN(1 << 5)
#define PINCONFIG_DRIVE_PUSH_PULL   (1 << 6)
#define PINCONFIG_DRIVE_OPEN_DRAIN  (1 << 7)
#define PINCONFIG_DRIVE_OPEN_SOURCE (1 << 8)
#define PINCONFIG_INPUT_SCHMITT_ENABLE  (1 << 9)
#define PINCONFIG_INPUT_SCHMITT_DISABLE (1 << 10)
#define PINCONFIG_LOW_POWER_MODE(1 << 11)
#define PINCONFIG_OUTPUT_LOW(1 << 12)
#define PINCONFIG_OUTPUT_HIGH   (1 << 13)


and code including how the rockchip driver could look like:
-
diff --git a/drivers/pinctrl/pinconf-generic.c 
b/drivers/pinctrl/pinconf-generic.c
index 9a6812b..35c40be 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -139,3 +139,61 @@ void pinconf_generic_dump_config(struct pinctrl_dev 
*pctldev,
 }
 EXPORT_SYMBOL_GPL(pinconf_generic_dump_config);
 #endif
+
+/*
+ * Maps the devicetree config bits to actual pinconf values.
+ * The array indizes match the bits set in dt-bindings/pinctrl/pinconf.h
+ * and the array should contain an entry for each bit defined there
+ */
+static unsigned long conf_map[] = {
+   PIN_CONF_PACKED(PIN_CONFIG_BIAS_DISABLE, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_BIAS_HIGH_IMPEDANCE, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_BIAS_BUS_HOLD, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_PIN_DEFAULT, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_UP, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_BIAS_PULL_DOWN, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_DRIVE_OPEN_DRAIN, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_DRIVE_OPEN_SOURCE, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1),
+   PIN_CONF_PACKED(PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_LOW_POWER_MODE, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
+   PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 1),
+};
+
+/*
+ * Parse a pinconf bitmap from a devicetree entry into individual pin configs.
+ * @pinconf: the bitmap containing conf

[PATCH 03/31] mips/kvm: Fix 32-bitisms in kvm_locore.S

[David Daney]

From: David Daney 

For a warning free compile, we need to use the width aware PTR_LI and
PTR_LA macros.  Use LI variant for immediate data and LA variant for
addresses.

Signed-off-by: David Daney 
---
 arch/mips/kvm/kvm_locore.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/mips/kvm/kvm_locore.S b/arch/mips/kvm/kvm_locore.S
index dca2aa6..e86fa2a 100644
--- a/arch/mips/kvm/kvm_locore.S
+++ b/arch/mips/kvm/kvm_locore.S
@@ -310,7 +310,7 @@ NESTED (MIPSX(GuestException), CALLFRAME_SIZ, ra)
 LONG_S  t0, VCPU_R26(k1)
 
 /* Get GUEST k1 and save it in VCPU */
-la  t1, ~0x2ff
+   PTR_LI  t1, ~0x2ff
 mfc0t0, CP0_EBASE
 and t0, t0, t1
 LONG_L  t0, 0x3000(t0)
@@ -384,14 +384,14 @@ NESTED (MIPSX(GuestException), CALLFRAME_SIZ, ra)
 mtc0k0, CP0_DDATA_LO
 
 /* Restore RDHWR access */
-la  k0, 0x200F
+   PTR_LI  k0, 0x200F
 mtc0k0,  CP0_HWRENA
 
 /* Jump to handler */
 FEXPORT(__kvm_mips_jump_to_handler)
 /* XXXKYMA: not sure if this is safe, how large is the stack?? */
 /* Now jump to the kvm_mips_handle_exit() to see if we can deal with this 
in the kernel */
-la  t9,kvm_mips_handle_exit
+   PTR_LA  t9, kvm_mips_handle_exit
 jalr.hb t9
 addiu   sp,sp, -CALLFRAME_SIZ   /* BD Slot */
 
@@ -566,7 +566,7 @@ __kvm_mips_return_to_host:
 mtlok0
 
 /* Restore RDHWR access */
-la  k0, 0x200F
+   PTR_LI  k0, 0x200F
 mtc0k0,  CP0_HWRENA
 
 
-- 
1.7.11.7

--
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 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.

[David Daney]

I should also add that I will shortly send patches for the kvm tool 
required to drive this VM as well as a small set of patches that create 
a para-virtualized MIPS/Linux guest kernel.


The idea is that because there is no standard SMP linux system, we 
create a standard para-virtualized system that uses a handful of 
hypercalls, but mostly just uses virtio devices.  It has no emulated 
real hardware (no 8250 UART, no emulated legacy anything...)


David Daney


On 06/07/2013 04:03 PM, David Daney wrote:

From: David Daney 

These patches take a somewhat different approach to MIPS
virtualization via the MIPS-VZ extensions than the patches previously
sent by Sanjay Lal.

Several facts about the code:

o Existing exception handlers are modified to hook in to KVM instead
   of intercepting all exceptions via the EBase register, and then
   chaining to real exception handlers.

o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way
   SMP 64-bit MIPS/Linux).

o Additional overhead on every exception even when *no* vCPU is running.

o Lower interrupt overhead, than the EBase interception method, when
   vCPU *is* running.

o This code is somewhat smaller than the existing trap/emulate
   implementation (about 2100 lines vs. about 5300 lines)

o Currently probably only usable on the OCTEON III CPU model, as some
   MIPS-VZ implementation-defined behaviors were assumed to have the
   OCTEON III behavior.

Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig
symbols in uapi headers.) queued, but I also include it here.

David Daney (31):
   MIPS: Move allocate_kscratch to cpu-probe.c and make it public.
   MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ
   mips/kvm: Fix 32-bitisms in kvm_locore.S
   mips/kvm: Add casts to avoid pointer width mismatch build failures.
   mips/kvm: Use generic cache flushing functions.
   mips/kvm: Rename kvm_vcpu_arch.pc to  kvm_vcpu_arch.epc
   mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername
   mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S
   mips/kvm: Factor trap-and-emulate support into a pluggable
 implementation.
   mips/kvm: Implement ioctls to get and set FPU registers.
   MIPS: Rearrange branch.c so it can be used by kvm code.
   MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al.
   mips/kvm: Add accessors for MIPS VZ registers.
   mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest
 Mode.
   mips/kvm: Exception handling to leave and reenter guest mode.
   mips/kvm: Add exception handler for MIPSVZ Guest exceptions.
   MIPS: Quit exposing Kconfig symbols in uapi headers.
   mips/kvm: Add pt_regs slots for BadInstr and BadInstrP
   mips/kvm: Add host definitions for MIPS VZ based host.
   mips/kvm: Hook into TLB fault handlers.
   mips/kvm: Allow set_except_vector() to be used from MIPSVZ code.
   mips/kvm: Split get_new_mmu_context into two parts.
   mips/kvm: Hook into CP unusable exception handler.
   mips/kvm: Add thread_struct fields used by MIPSVZ hosts.
   mips/kvm: Add some asm-offsets constants used by MIPSVZ.
   mips/kvm: Split up Kconfig and Makefile definitions in preperation
 for MIPSVZ.
   mips/kvm: Gate the use of kvm_local_flush_tlb_all() by KVM_MIPSTE
   mips/kvm: Only use KVM_COALESCED_MMIO_PAGE_OFFSET with KVM_MIPSTE
   mips/kvm: Add MIPSVZ support.
   mips/kvm: Enable MIPSVZ in Kconfig/Makefile
   mips/kvm: Allow for upto 8 KVM vcpus per vm.

  arch/mips/Kconfig   |1 +
  arch/mips/include/asm/branch.h  |7 +
  arch/mips/include/asm/kvm_host.h|  622 +---
  arch/mips/include/asm/kvm_mips_te.h |  589 +++
  arch/mips/include/asm/kvm_mips_vz.h |   29 +
  arch/mips/include/asm/mipsregs.h|  264 +
  arch/mips/include/asm/mmu_context.h |   12 +-
  arch/mips/include/asm/processor.h   |6 +
  arch/mips/include/asm/ptrace.h  |   36 +
  arch/mips/include/asm/stackframe.h  |  150 ++-
  arch/mips/include/asm/thread_info.h |2 +
  arch/mips/include/asm/uasm.h|2 +-
  arch/mips/include/uapi/asm/inst.h   |   23 +-
  arch/mips/include/uapi/asm/ptrace.h |   17 +-
  arch/mips/kernel/asm-offsets.c  |  124 ++-
  arch/mips/kernel/branch.c   |   63 +-
  arch/mips/kernel/cpu-probe.c|   34 +
  arch/mips/kernel/genex.S|8 +
  arch/mips/kernel/scall64-64.S   |   12 +
  arch/mips/kernel/scall64-n32.S  |   12 +
  arch/mips/kernel/traps.c|   15 +-
  arch/mips/kvm/Kconfig   |   23 +-
  arch/mips/kvm/Makefile  |   15 +-
  arch/mips/kvm/kvm_locore.S  |  980 +-
  arch/mips/kvm/kvm_mips.c|  768 ++
  arch/mips/kvm/kvm_mips_comm.h   |1 +
  arch/mips/kvm/kvm_mips_commpage.c   |9 +-
  arch/mips/kvm/kvm_mips_dyntrans.c   |4 +-
  arch/mips/kvm/kvm_mips_emul.c   |  312 +++---
  arch/mips/kvm/kvm_mips_int.c|   53 +-
  arch/mips/kvm/kvm_mips_int.h|  

[PATCH 02/31] MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ

[David Daney]

From: David Daney 

We cannot clobber any registers on exceptions as any guest will need
them all.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/mipsregs.h   |  2 ++
 arch/mips/include/asm/stackframe.h | 15 +++
 arch/mips/kernel/cpu-probe.c   |  7 ++-
 arch/mips/kernel/genex.S   |  5 +
 arch/mips/kernel/scall64-64.S  | 12 
 arch/mips/kernel/scall64-n32.S | 12 
 arch/mips/kernel/traps.c   |  5 +
 arch/mips/mm/tlbex.c   | 25 +
 8 files changed, 82 insertions(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index 6e0da5aa..6f03c72 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -73,6 +73,8 @@
 #define CP0_TAGHI $29
 #define CP0_ERROREPC $30
 #define CP0_DESAVE $31
+#define CP0_KSCRATCH1 $31, 2
+#define CP0_KSCRATCH2 $31, 3
 
 /*
  * R4640/R4650 cp0 register names.  These registers are listed
diff --git a/arch/mips/include/asm/stackframe.h 
b/arch/mips/include/asm/stackframe.h
index a89d1b1..20627b2 100644
--- a/arch/mips/include/asm/stackframe.h
+++ b/arch/mips/include/asm/stackframe.h
@@ -181,6 +181,16 @@
 #endif
LONG_S  k0, PT_R29(sp)
LONG_S  $3, PT_R3(sp)
+#ifdef CONFIG_KVM_MIPSVZ
+   /*
+* With KVM_MIPSVZ, we must not clobber k0/k1
+* they were saved before they were used
+*/
+   MFC0k0, CP0_KSCRATCH1
+   MFC0$3, CP0_KSCRATCH2
+   LONG_S  k0, PT_R26(sp)
+   LONG_S  $3, PT_R27(sp)
+#endif
/*
 * You might think that you don't need to save $0,
 * but the FPU emulator and gdb remote debug stub
@@ -447,6 +457,11 @@
.endm
 
.macro  RESTORE_SP_AND_RET
+
+#ifdef CONFIG_KVM_MIPSVZ
+   LONG_L  k0, PT_R26(sp)
+   LONG_L  k1, PT_R27(sp)
+#endif
LONG_L  sp, PT_R29(sp)
.setmips3
eret
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index ee1014e..7a07edb 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1067,7 +1067,12 @@ __cpuinit void cpu_report(void)
 
 static DEFINE_SPINLOCK(kscratch_used_lock);
 
-static unsigned int kscratch_used_mask;
+static unsigned int kscratch_used_mask
+#ifdef CONFIG_KVM_MIPSVZ
+/* KVM_MIPSVZ implemtation uses these two statically. */
+= 0xc
+#endif
+;
 
 int allocate_kscratch(void)
 {
diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S
index 31fa856..163e299 100644
--- a/arch/mips/kernel/genex.S
+++ b/arch/mips/kernel/genex.S
@@ -46,6 +46,11 @@
 NESTED(except_vec3_generic, 0, sp)
.setpush
.setnoat
+#ifdef CONFIG_KVM_MIPSVZ
+   /* With KVM_MIPSVZ, we must not clobber k0/k1 */
+   MTC0k0, CP0_KSCRATCH1
+   MTC0k1, CP0_KSCRATCH2
+#endif
 #if R5432_CP0_INTERRUPT_WAR
mfc0k0, CP0_INDEX
 #endif
diff --git a/arch/mips/kernel/scall64-64.S b/arch/mips/kernel/scall64-64.S
index 97a5909..5ff4882 100644
--- a/arch/mips/kernel/scall64-64.S
+++ b/arch/mips/kernel/scall64-64.S
@@ -62,6 +62,9 @@ NESTED(handle_sys64, PT_SIZE, sp)
jalrt2  # Do The Real Thing (TM)
 
li  t0, -EMAXERRNO - 1  # error?
+#if defined(CONFIG_KVM_MIPSVZ) && defined(CONFIG_FAST_ACCESS_TO_THREAD_POINTER)
+   ld  t2, TI_TP_VALUE($28)
+#endif
sltut0, t0, v0
sd  t0, PT_R7(sp)   # set error flag
beqzt0, 1f
@@ -70,6 +73,9 @@ NESTED(handle_sys64, PT_SIZE, sp)
dnegu   v0  # error
sd  t1, PT_R0(sp)   # save it for syscall restarting
 1: sd  v0, PT_R2(sp)   # result
+#if defined(CONFIG_KVM_MIPSVZ) && defined(CONFIG_FAST_ACCESS_TO_THREAD_POINTER)
+   sd  t2, PT_R26(sp)
+#endif
 
 n64_syscall_exit:
j   syscall_exit_partial
@@ -93,6 +99,9 @@ syscall_trace_entry:
jalrt0
 
li  t0, -EMAXERRNO - 1  # error?
+#if defined(CONFIG_KVM_MIPSVZ) && defined(CONFIG_FAST_ACCESS_TO_THREAD_POINTER)
+   ld  t2, TI_TP_VALUE($28)
+#endif
sltut0, t0, v0
sd  t0, PT_R7(sp)   # set error flag
beqzt0, 1f
@@ -101,6 +110,9 @@ syscall_trace_entry:
dnegu   v0  # error
sd  t1, PT_R0(sp)   # save it for syscall restarting
 1: sd  v0, PT_R2(sp)   # result
+#if defined(CONFIG_KVM_MIPSVZ) && defined(CONFIG_FAST_ACCESS_TO_THREAD_POINTER)
+   sd  t2, PT_R26(sp)
+#endif
 
j   syscall_exit
 
diff --git a/arch/mips/kernel/scall64-n32.S b/arch/mips/kernel/scall64-n32.S
index edcb659..cba35b4 100644
--- a/arch/mips/kernel/scall64-n32.S
+++ b/arch/mips/kernel/scall64-n32.S
@@ -55,6 +55,9 @@ NESTED(handle_sysn3

[PATCH 07/31] mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername

[David Daney]

From: David Daney 

This makes it follow the pattern where the structure name is the
symbol name prefix.

Signed-off-by: David Daney 
---
 arch/mips/kernel/asm-offsets.c |  68 +++---
 arch/mips/kvm/kvm_locore.S | 206 -
 2 files changed, 137 insertions(+), 137 deletions(-)

diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c
index 22bf8f5..a0aa12c 100644
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -351,40 +351,40 @@ void output_kvm_defines(void)
 
OFFSET(VCPU_GUEST_INST, kvm_vcpu_arch, guest_inst);
 
-   OFFSET(VCPU_R0, kvm_vcpu_arch, gprs[0]);
-   OFFSET(VCPU_R1, kvm_vcpu_arch, gprs[1]);
-   OFFSET(VCPU_R2, kvm_vcpu_arch, gprs[2]);
-   OFFSET(VCPU_R3, kvm_vcpu_arch, gprs[3]);
-   OFFSET(VCPU_R4, kvm_vcpu_arch, gprs[4]);
-   OFFSET(VCPU_R5, kvm_vcpu_arch, gprs[5]);
-   OFFSET(VCPU_R6, kvm_vcpu_arch, gprs[6]);
-   OFFSET(VCPU_R7, kvm_vcpu_arch, gprs[7]);
-   OFFSET(VCPU_R8, kvm_vcpu_arch, gprs[8]);
-   OFFSET(VCPU_R9, kvm_vcpu_arch, gprs[9]);
-   OFFSET(VCPU_R10, kvm_vcpu_arch, gprs[10]);
-   OFFSET(VCPU_R11, kvm_vcpu_arch, gprs[11]);
-   OFFSET(VCPU_R12, kvm_vcpu_arch, gprs[12]);
-   OFFSET(VCPU_R13, kvm_vcpu_arch, gprs[13]);
-   OFFSET(VCPU_R14, kvm_vcpu_arch, gprs[14]);
-   OFFSET(VCPU_R15, kvm_vcpu_arch, gprs[15]);
-   OFFSET(VCPU_R16, kvm_vcpu_arch, gprs[16]);
-   OFFSET(VCPU_R17, kvm_vcpu_arch, gprs[17]);
-   OFFSET(VCPU_R18, kvm_vcpu_arch, gprs[18]);
-   OFFSET(VCPU_R19, kvm_vcpu_arch, gprs[19]);
-   OFFSET(VCPU_R20, kvm_vcpu_arch, gprs[20]);
-   OFFSET(VCPU_R21, kvm_vcpu_arch, gprs[21]);
-   OFFSET(VCPU_R22, kvm_vcpu_arch, gprs[22]);
-   OFFSET(VCPU_R23, kvm_vcpu_arch, gprs[23]);
-   OFFSET(VCPU_R24, kvm_vcpu_arch, gprs[24]);
-   OFFSET(VCPU_R25, kvm_vcpu_arch, gprs[25]);
-   OFFSET(VCPU_R26, kvm_vcpu_arch, gprs[26]);
-   OFFSET(VCPU_R27, kvm_vcpu_arch, gprs[27]);
-   OFFSET(VCPU_R28, kvm_vcpu_arch, gprs[28]);
-   OFFSET(VCPU_R29, kvm_vcpu_arch, gprs[29]);
-   OFFSET(VCPU_R30, kvm_vcpu_arch, gprs[30]);
-   OFFSET(VCPU_R31, kvm_vcpu_arch, gprs[31]);
-   OFFSET(VCPU_LO, kvm_vcpu_arch, lo);
-   OFFSET(VCPU_HI, kvm_vcpu_arch, hi);
+   OFFSET(KVM_VCPU_ARCH_R0, kvm_vcpu_arch, gprs[0]);
+   OFFSET(KVM_VCPU_ARCH_R1, kvm_vcpu_arch, gprs[1]);
+   OFFSET(KVM_VCPU_ARCH_R2, kvm_vcpu_arch, gprs[2]);
+   OFFSET(KVM_VCPU_ARCH_R3, kvm_vcpu_arch, gprs[3]);
+   OFFSET(KVM_VCPU_ARCH_R4, kvm_vcpu_arch, gprs[4]);
+   OFFSET(KVM_VCPU_ARCH_R5, kvm_vcpu_arch, gprs[5]);
+   OFFSET(KVM_VCPU_ARCH_R6, kvm_vcpu_arch, gprs[6]);
+   OFFSET(KVM_VCPU_ARCH_R7, kvm_vcpu_arch, gprs[7]);
+   OFFSET(KVM_VCPU_ARCH_R8, kvm_vcpu_arch, gprs[8]);
+   OFFSET(KVM_VCPU_ARCH_R9, kvm_vcpu_arch, gprs[9]);
+   OFFSET(KVM_VCPU_ARCH_R10, kvm_vcpu_arch, gprs[10]);
+   OFFSET(KVM_VCPU_ARCH_R11, kvm_vcpu_arch, gprs[11]);
+   OFFSET(KVM_VCPU_ARCH_R12, kvm_vcpu_arch, gprs[12]);
+   OFFSET(KVM_VCPU_ARCH_R13, kvm_vcpu_arch, gprs[13]);
+   OFFSET(KVM_VCPU_ARCH_R14, kvm_vcpu_arch, gprs[14]);
+   OFFSET(KVM_VCPU_ARCH_R15, kvm_vcpu_arch, gprs[15]);
+   OFFSET(KVM_VCPU_ARCH_R16, kvm_vcpu_arch, gprs[16]);
+   OFFSET(KVM_VCPU_ARCH_R17, kvm_vcpu_arch, gprs[17]);
+   OFFSET(KVM_VCPU_ARCH_R18, kvm_vcpu_arch, gprs[18]);
+   OFFSET(KVM_VCPU_ARCH_R19, kvm_vcpu_arch, gprs[19]);
+   OFFSET(KVM_VCPU_ARCH_R20, kvm_vcpu_arch, gprs[20]);
+   OFFSET(KVM_VCPU_ARCH_R21, kvm_vcpu_arch, gprs[21]);
+   OFFSET(KVM_VCPU_ARCH_R22, kvm_vcpu_arch, gprs[22]);
+   OFFSET(KVM_VCPU_ARCH_R23, kvm_vcpu_arch, gprs[23]);
+   OFFSET(KVM_VCPU_ARCH_R24, kvm_vcpu_arch, gprs[24]);
+   OFFSET(KVM_VCPU_ARCH_R25, kvm_vcpu_arch, gprs[25]);
+   OFFSET(KVM_VCPU_ARCH_R26, kvm_vcpu_arch, gprs[26]);
+   OFFSET(KVM_VCPU_ARCH_R27, kvm_vcpu_arch, gprs[27]);
+   OFFSET(KVM_VCPU_ARCH_R28, kvm_vcpu_arch, gprs[28]);
+   OFFSET(KVM_VCPU_ARCH_R29, kvm_vcpu_arch, gprs[29]);
+   OFFSET(KVM_VCPU_ARCH_R30, kvm_vcpu_arch, gprs[30]);
+   OFFSET(KVM_VCPU_ARCH_R31, kvm_vcpu_arch, gprs[31]);
+   OFFSET(KVM_VCPU_ARCH_LO, kvm_vcpu_arch, lo);
+   OFFSET(KVM_VCPU_ARCH_HI, kvm_vcpu_arch, hi);
OFFSET(KVM_VCPU_ARCH_EPC, kvm_vcpu_arch, epc);
OFFSET(VCPU_COP0, kvm_vcpu_arch, cop0);
OFFSET(VCPU_GUEST_KERNEL_ASID, kvm_vcpu_arch, guest_kernel_asid);
diff --git a/arch/mips/kvm/kvm_locore.S b/arch/mips/kvm/kvm_locore.S
index a434bbe..7a33ee7 100644
--- a/arch/mips/kvm/kvm_locore.S
+++ b/arch/mips/kvm/kvm_locore.S
@@ -175,52 +175,52 @@ FEXPORT(__kvm_mips_load_asid)
 mtc0zero,  CP0_HWRENA
 
 /* Now load up the Guest Context from VCPU */
-LONG_L $1, VCPU_R1(k1)
-LONG_L $2, VCPU_R2(k1)
-LONG_L $3, VCPU_R3(k1)
-
-LONG_L $4, VCPU_R4(k1)
-LONG_L $5, VC

[PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.

[David Daney]

From: David Daney 

These patches take a somewhat different approach to MIPS
virtualization via the MIPS-VZ extensions than the patches previously
sent by Sanjay Lal.

Several facts about the code:

o Existing exception handlers are modified to hook in to KVM instead
  of intercepting all exceptions via the EBase register, and then
  chaining to real exception handlers.

o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way
  SMP 64-bit MIPS/Linux).

o Additional overhead on every exception even when *no* vCPU is running.

o Lower interrupt overhead, than the EBase interception method, when
  vCPU *is* running.

o This code is somewhat smaller than the existing trap/emulate
  implementation (about 2100 lines vs. about 5300 lines)

o Currently probably only usable on the OCTEON III CPU model, as some
  MIPS-VZ implementation-defined behaviors were assumed to have the
  OCTEON III behavior.

Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig
symbols in uapi headers.) queued, but I also include it here.

David Daney (31):
  MIPS: Move allocate_kscratch to cpu-probe.c and make it public.
  MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ
  mips/kvm: Fix 32-bitisms in kvm_locore.S
  mips/kvm: Add casts to avoid pointer width mismatch build failures.
  mips/kvm: Use generic cache flushing functions.
  mips/kvm: Rename kvm_vcpu_arch.pc to  kvm_vcpu_arch.epc
  mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername
  mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S
  mips/kvm: Factor trap-and-emulate support into a pluggable
implementation.
  mips/kvm: Implement ioctls to get and set FPU registers.
  MIPS: Rearrange branch.c so it can be used by kvm code.
  MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al.
  mips/kvm: Add accessors for MIPS VZ registers.
  mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest
Mode.
  mips/kvm: Exception handling to leave and reenter guest mode.
  mips/kvm: Add exception handler for MIPSVZ Guest exceptions.
  MIPS: Quit exposing Kconfig symbols in uapi headers.
  mips/kvm: Add pt_regs slots for BadInstr and BadInstrP
  mips/kvm: Add host definitions for MIPS VZ based host.
  mips/kvm: Hook into TLB fault handlers.
  mips/kvm: Allow set_except_vector() to be used from MIPSVZ code.
  mips/kvm: Split get_new_mmu_context into two parts.
  mips/kvm: Hook into CP unusable exception handler.
  mips/kvm: Add thread_struct fields used by MIPSVZ hosts.
  mips/kvm: Add some asm-offsets constants used by MIPSVZ.
  mips/kvm: Split up Kconfig and Makefile definitions in preperation
for MIPSVZ.
  mips/kvm: Gate the use of kvm_local_flush_tlb_all() by KVM_MIPSTE
  mips/kvm: Only use KVM_COALESCED_MMIO_PAGE_OFFSET with KVM_MIPSTE
  mips/kvm: Add MIPSVZ support.
  mips/kvm: Enable MIPSVZ in Kconfig/Makefile
  mips/kvm: Allow for upto 8 KVM vcpus per vm.

 arch/mips/Kconfig   |1 +
 arch/mips/include/asm/branch.h  |7 +
 arch/mips/include/asm/kvm_host.h|  622 +---
 arch/mips/include/asm/kvm_mips_te.h |  589 +++
 arch/mips/include/asm/kvm_mips_vz.h |   29 +
 arch/mips/include/asm/mipsregs.h|  264 +
 arch/mips/include/asm/mmu_context.h |   12 +-
 arch/mips/include/asm/processor.h   |6 +
 arch/mips/include/asm/ptrace.h  |   36 +
 arch/mips/include/asm/stackframe.h  |  150 ++-
 arch/mips/include/asm/thread_info.h |2 +
 arch/mips/include/asm/uasm.h|2 +-
 arch/mips/include/uapi/asm/inst.h   |   23 +-
 arch/mips/include/uapi/asm/ptrace.h |   17 +-
 arch/mips/kernel/asm-offsets.c  |  124 ++-
 arch/mips/kernel/branch.c   |   63 +-
 arch/mips/kernel/cpu-probe.c|   34 +
 arch/mips/kernel/genex.S|8 +
 arch/mips/kernel/scall64-64.S   |   12 +
 arch/mips/kernel/scall64-n32.S  |   12 +
 arch/mips/kernel/traps.c|   15 +-
 arch/mips/kvm/Kconfig   |   23 +-
 arch/mips/kvm/Makefile  |   15 +-
 arch/mips/kvm/kvm_locore.S  |  980 +-
 arch/mips/kvm/kvm_mips.c|  768 ++
 arch/mips/kvm/kvm_mips_comm.h   |1 +
 arch/mips/kvm/kvm_mips_commpage.c   |9 +-
 arch/mips/kvm/kvm_mips_dyntrans.c   |4 +-
 arch/mips/kvm/kvm_mips_emul.c   |  312 +++---
 arch/mips/kvm/kvm_mips_int.c|   53 +-
 arch/mips/kvm/kvm_mips_int.h|2 -
 arch/mips/kvm/kvm_mips_stats.c  |6 +-
 arch/mips/kvm/kvm_mipsvz.c  | 1894 +++
 arch/mips/kvm/kvm_mipsvz_guest.S|  234 +
 arch/mips/kvm/kvm_tlb.c |  140 +--
 arch/mips/kvm/kvm_trap_emul.c   |  932 +++--
 arch/mips/mm/fault.c|8 +
 arch/mips/mm/tlbex-fault.S  |6 +
 arch/mips/mm/tlbex.c|   45 +-
 39 files changed, 5299 insertions(+), 2161 deletions(-)
 create mode 100644 arch/mips/include/asm/kvm_mips_te.h
 create mode 100644 arch/mips/include/as

[PATCH 10/31] mips/kvm: Implement ioctls to get and set FPU registers.

[David Daney]

From: David Daney 

The current implementation does nothing with them, but future MIPSVZ
work need them.  Also add the asm-offsets accessors for the fields.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/kvm_host.h |  8 
 arch/mips/kernel/asm-offsets.c   |  8 
 arch/mips/kvm/kvm_mips.c | 26 --
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 16013c7..505b804 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -102,6 +102,14 @@ struct kvm_vcpu_arch {
unsigned long lo;
unsigned long epc;
 
+   /* FPU state */
+   u64 fpr[32];
+   u32 fir;
+   u32 fccr;
+   u32 fexr;
+   u32 fenr;
+   u32 fcsr;
+
void *impl;
 };
 
diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c
index 5a9222e..03bf363 100644
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -377,6 +377,14 @@ void output_kvm_defines(void)
OFFSET(KVM_VCPU_ARCH_HI, kvm_vcpu, arch.hi);
OFFSET(KVM_VCPU_ARCH_EPC, kvm_vcpu, arch.epc);
OFFSET(KVM_VCPU_ARCH_IMPL, kvm_vcpu, arch.impl);
+   BLANK();
+   OFFSET(KVM_VCPU_ARCH_FPR,   kvm_vcpu, arch.fpr);
+   OFFSET(KVM_VCPU_ARCH_FIR,   kvm_vcpu, arch.fir);
+   OFFSET(KVM_VCPU_ARCH_FCCR,  kvm_vcpu, arch.fccr);
+   OFFSET(KVM_VCPU_ARCH_FEXR,  kvm_vcpu, arch.fexr);
+   OFFSET(KVM_VCPU_ARCH_FENR,  kvm_vcpu, arch.fenr);
+   OFFSET(KVM_VCPU_ARCH_FCSR,  kvm_vcpu, arch.fcsr);
+   BLANK();
 
OFFSET(KVM_MIPS_VCPU_TE_HOST_EBASE, kvm_mips_vcpu_te, host_ebase);
OFFSET(KVM_MIPS_VCPU_TE_GUEST_EBASE, kvm_mips_vcpu_te, guest_ebase);
diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index 041caad..18c8dc8 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
@@ -465,12 +465,34 @@ int kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
 
 int kvm_arch_vcpu_ioctl_get_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
 {
-   return -ENOIOCTLCMD;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(vcpu->arch.fpr); i++)
+   fpu->fpr[i] = vcpu->arch.fpr[i];
+
+   fpu->fir = vcpu->arch.fir;
+   fpu->fccr = vcpu->arch.fccr;
+   fpu->fexr = vcpu->arch.fexr;
+   fpu->fenr = vcpu->arch.fenr;
+   fpu->fcsr = vcpu->arch.fcsr;
+
+   return 0;
 }
 
 int kvm_arch_vcpu_ioctl_set_fpu(struct kvm_vcpu *vcpu, struct kvm_fpu *fpu)
 {
-   return -ENOIOCTLCMD;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(vcpu->arch.fpr); i++)
+   vcpu->arch.fpr[i] = fpu->fpr[i];
+
+   vcpu->arch.fir = fpu->fir;
+   vcpu->arch.fccr = fpu->fccr;
+   vcpu->arch.fexr = fpu->fexr;
+   vcpu->arch.fenr = fpu->fenr;
+   vcpu->arch.fcsr = fpu->fcsr;
+
+   return 0;
 }
 
 int kvm_arch_vcpu_fault(struct kvm_vcpu *vcpu, struct vm_fault *vmf)
-- 
1.7.11.7

--
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 06/31] mips/kvm: Rename kvm_vcpu_arch.pc to kvm_vcpu_arch.epc

[David Daney]

From: David Daney 

The proper MIPS name for this register is EPC, so use that.

Change the asm-offsets name to KVM_VCPU_ARCH_EPC, so that the symbol
name prefix matches the structure name.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/kvm_host.h |   2 +-
 arch/mips/kernel/asm-offsets.c   |   2 +-
 arch/mips/kvm/kvm_locore.S   |   6 +-
 arch/mips/kvm/kvm_mips.c |  12 ++--
 arch/mips/kvm/kvm_mips_emul.c| 140 +++
 arch/mips/kvm/kvm_mips_int.c |   8 +--
 arch/mips/kvm/kvm_trap_emul.c|  20 +++---
 7 files changed, 95 insertions(+), 95 deletions(-)

diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 4d6fa0b..d9ee320 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -363,7 +363,7 @@ struct kvm_vcpu_arch {
unsigned long gprs[32];
unsigned long hi;
unsigned long lo;
-   unsigned long pc;
+   unsigned long epc;
 
/* FPU State */
struct mips_fpu_struct fpu;
diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c
index 0845091..22bf8f5 100644
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -385,7 +385,7 @@ void output_kvm_defines(void)
OFFSET(VCPU_R31, kvm_vcpu_arch, gprs[31]);
OFFSET(VCPU_LO, kvm_vcpu_arch, lo);
OFFSET(VCPU_HI, kvm_vcpu_arch, hi);
-   OFFSET(VCPU_PC, kvm_vcpu_arch, pc);
+   OFFSET(KVM_VCPU_ARCH_EPC, kvm_vcpu_arch, epc);
OFFSET(VCPU_COP0, kvm_vcpu_arch, cop0);
OFFSET(VCPU_GUEST_KERNEL_ASID, kvm_vcpu_arch, guest_kernel_asid);
OFFSET(VCPU_GUEST_USER_ASID, kvm_vcpu_arch, guest_user_asid);
diff --git a/arch/mips/kvm/kvm_locore.S b/arch/mips/kvm/kvm_locore.S
index e86fa2a..a434bbe 100644
--- a/arch/mips/kvm/kvm_locore.S
+++ b/arch/mips/kvm/kvm_locore.S
@@ -151,7 +151,7 @@ FEXPORT(__kvm_mips_vcpu_run)
 
 
/* Set Guest EPC */
-   LONG_L  t0, VCPU_PC(k1)
+   LONG_L  t0, KVM_VCPU_ARCH_EPC(k1)
mtc0t0, CP0_EPC
 
 FEXPORT(__kvm_mips_load_asid)
@@ -330,7 +330,7 @@ NESTED (MIPSX(GuestException), CALLFRAME_SIZ, ra)
 
 /* Save Host level EPC, BadVaddr and Cause to VCPU, useful to process the 
exception */
 mfc0k0,CP0_EPC
-LONG_S  k0, VCPU_PC(k1)
+LONG_S  k0, KVM_VCPU_ARCH_EPC(k1)
 
 mfc0k0, CP0_BADVADDR
 LONG_S  k0, VCPU_HOST_CP0_BADVADDR(k1)
@@ -438,7 +438,7 @@ __kvm_mips_return_to_guest:
 
 
/* Set Guest EPC */
-   LONG_L  t0, VCPU_PC(k1)
+   LONG_L  t0, KVM_VCPU_ARCH_EPC(k1)
mtc0t0, CP0_EPC
 
 /* Set the ASID for the Guest Kernel */
diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index 6018e2a..4ac5ab4 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
@@ -583,7 +583,7 @@ static int kvm_mips_get_reg(struct kvm_vcpu *vcpu,
v = (long)vcpu->arch.lo;
break;
case KVM_REG_MIPS_PC:
-   v = (long)vcpu->arch.pc;
+   v = (long)vcpu->arch.epc;
break;
 
case KVM_REG_MIPS_CP0_INDEX:
@@ -658,7 +658,7 @@ static int kvm_mips_set_reg(struct kvm_vcpu *vcpu,
vcpu->arch.lo = v;
break;
case KVM_REG_MIPS_PC:
-   vcpu->arch.pc = v;
+   vcpu->arch.epc = v;
break;
 
case KVM_REG_MIPS_CP0_INDEX:
@@ -890,7 +890,7 @@ int kvm_arch_vcpu_dump_regs(struct kvm_vcpu *vcpu)
return -1;
 
printk("VCPU Register Dump:\n");
-   printk("\tpc = 0x%08lx\n", vcpu->arch.pc);;
+   printk("\tepc = 0x%08lx\n", vcpu->arch.epc);;
printk("\texceptions: %08lx\n", vcpu->arch.pending_exceptions);
 
for (i = 0; i < 32; i += 4) {
@@ -920,7 +920,7 @@ int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, 
struct kvm_regs *regs)
vcpu->arch.gprs[0] = 0; /* zero is special, and cannot be set. */
vcpu->arch.hi = regs->hi;
vcpu->arch.lo = regs->lo;
-   vcpu->arch.pc = regs->pc;
+   vcpu->arch.epc = regs->pc;
 
return 0;
 }
@@ -934,7 +934,7 @@ int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, 
struct kvm_regs *regs)
 
regs->hi = vcpu->arch.hi;
regs->lo = vcpu->arch.lo;
-   regs->pc = vcpu->arch.pc;
+   regs->pc = vcpu->arch.epc;
 
return 0;
 }
@@ -1014,7 +1014,7 @@ int kvm_mips_handle_exit(struct kvm_run *run, struct 
kvm_vcpu *vcpu)
 {
uint32_t cause = vcpu->arch.host_cp0_cause;
uint32_t exccode = (cause >> CAUSEB_EXCCODE) & 0x1f;
-   uint32_t __user *opc = (uint32_t __user *) vcpu->arch.pc;
+   uint32_t __user *opc = (uint32_t __user *) vcpu->arch.epc;
unsigned long badvaddr = vcpu->arch.host_cp0_badvaddr;
enum emulation_result er = EMULATE_DONE;
int ret = RESUME_GUEST;
diff --git a/arch/mips/kvm/kvm_mips_emul.c b/arch/mips/kvm/kvm_mips_emul.c
index a2c6687..7cbc3b

[PATCH 08/31] mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S

[David Daney]

From: David Daney 

It was a completely inconsistent mix of spaces and tabs.

Signed-off-by: David Daney 
---
 arch/mips/kvm/kvm_locore.S | 921 +++--
 1 file changed, 464 insertions(+), 457 deletions(-)

diff --git a/arch/mips/kvm/kvm_locore.S b/arch/mips/kvm/kvm_locore.S
index 7a33ee7..7c2933a 100644
--- a/arch/mips/kvm/kvm_locore.S
+++ b/arch/mips/kvm/kvm_locore.S
@@ -1,13 +1,13 @@
 /*
-* This file is subject to the terms and conditions of the GNU General Public
-* License.  See the file "COPYING" in the main directory of this archive
-* for more details.
-*
-* Main entry point for the guest, exception handling.
-*
-* Copyright (C) 2012  MIPS Technologies, Inc.  All rights reserved.
-* Authors: Sanjay Lal 
-*/
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Main entry point for the guest, exception handling.
+ *
+ * Copyright (C) 2012  MIPS Technologies, Inc.  All rights reserved.
+ * Authors: Sanjay Lal 
+ */
 
 #include 
 #include 
@@ -57,172 +57,177 @@
  */
 
 FEXPORT(__kvm_mips_vcpu_run)
-.setpush
-.setnoreorder
-.setnoat
-
-/* k0/k1 not being used in host kernel context */
-   addiu   k1,sp, -PT_SIZE
-LONG_S $0, PT_R0(k1)
-LONG_S $1, PT_R1(k1)
-LONG_S $2, PT_R2(k1)
-LONG_S $3, PT_R3(k1)
-
-LONG_S $4, PT_R4(k1)
-LONG_S $5, PT_R5(k1)
-LONG_S $6, PT_R6(k1)
-LONG_S $7, PT_R7(k1)
-
-LONG_S $8,  PT_R8(k1)
-LONG_S $9,  PT_R9(k1)
-LONG_S $10, PT_R10(k1)
-LONG_S $11, PT_R11(k1)
-LONG_S $12, PT_R12(k1)
-LONG_S $13, PT_R13(k1)
-LONG_S $14, PT_R14(k1)
-LONG_S $15, PT_R15(k1)
-LONG_S $16, PT_R16(k1)
-LONG_S $17, PT_R17(k1)
-
-LONG_S $18, PT_R18(k1)
-LONG_S $19, PT_R19(k1)
-LONG_S $20, PT_R20(k1)
-LONG_S $21, PT_R21(k1)
-LONG_S $22, PT_R22(k1)
-LONG_S $23, PT_R23(k1)
-LONG_S $24, PT_R24(k1)
-LONG_S $25, PT_R25(k1)
+   .setpush
+   .setnoreorder
+   .setnoat
+
+   /* k0/k1 not being used in host kernel context */
+   addiu   k1, sp, -PT_SIZE
+   LONG_S  $0, PT_R0(k1)
+   LONG_S  $1, PT_R1(k1)
+   LONG_S  $2, PT_R2(k1)
+   LONG_S  $3, PT_R3(k1)
+
+   LONG_S  $4, PT_R4(k1)
+   LONG_S  $5, PT_R5(k1)
+   LONG_S  $6, PT_R6(k1)
+   LONG_S  $7, PT_R7(k1)
+
+   LONG_S  $8,  PT_R8(k1)
+   LONG_S  $9,  PT_R9(k1)
+   LONG_S  $10, PT_R10(k1)
+   LONG_S  $11, PT_R11(k1)
+   LONG_S  $12, PT_R12(k1)
+   LONG_S  $13, PT_R13(k1)
+   LONG_S  $14, PT_R14(k1)
+   LONG_S  $15, PT_R15(k1)
+   LONG_S  $16, PT_R16(k1)
+   LONG_S  $17, PT_R17(k1)
+
+   LONG_S  $18, PT_R18(k1)
+   LONG_S  $19, PT_R19(k1)
+   LONG_S  $20, PT_R20(k1)
+   LONG_S  $21, PT_R21(k1)
+   LONG_S  $22, PT_R22(k1)
+   LONG_S  $23, PT_R23(k1)
+   LONG_S  $24, PT_R24(k1)
+   LONG_S  $25, PT_R25(k1)
 
/* XXXKYMA k0/k1 not saved, not being used if we got here through an 
ioctl() */
 
-LONG_S $28, PT_R28(k1)
-LONG_S $29, PT_R29(k1)
-LONG_S $30, PT_R30(k1)
-LONG_S $31, PT_R31(k1)
+   LONG_S  $28, PT_R28(k1)
+   LONG_S  $29, PT_R29(k1)
+   LONG_S  $30, PT_R30(k1)
+   LONG_S  $31, PT_R31(k1)
 
-/* Save hi/lo */
-   mflov0
-   LONG_S  v0, PT_LO(k1)
-   mfhiv1
-   LONG_S  v1, PT_HI(k1)
+   /* Save hi/lo */
+   mflov0
+   LONG_S  v0, PT_LO(k1)
+   mfhiv1
+   LONG_S  v1, PT_HI(k1)
 
/* Save host status */
-   mfc0v0, CP0_STATUS
-   LONG_S  v0, PT_STATUS(k1)
+   mfc0v0, CP0_STATUS
+   LONG_S  v0, PT_STATUS(k1)
 
/* Save host ASID, shove it into the BVADDR location */
-   mfc0v1,CP0_ENTRYHI
-   andiv1, 0xff
-   LONG_S  v1, PT_HOST_ASID(k1)
+   mfc0v1, CP0_ENTRYHI
+   andiv1, 0xff
+   LONG_S  v1, PT_HOST_ASID(k1)
 
-/* Save DDATA_LO, will be used to store pointer to vcpu */
-mfc0v1, CP0_DDATA_LO
-LONG_S  v1, PT_HOST_USERLOCAL(k1)
+   /* Save DDATA_LO, will be used to store pointer to vcpu */
+   mfc0v1, CP0_DDATA_LO
+   LONG_S  v1, PT_HOST_USERLOCAL(k1)
 
-/* DDATA_LO has pointer to vcpu */
-mtc0a1,CP0_DDATA_LO
+   /* DDATA_LO has pointer to vcpu */
+   mtc0a1, CP0_DDATA_LO
 
-/* Offset into vcpu->arch */
-   addiu   k1, a1, VCPU_HOST_ARCH
+   /* Offset in

Re: [GIT PULL] Power management and ACPI fixes for v3.10-rc5

[Rafael J. Wysocki]

On Friday, June 07, 2013 04:02:11 PM Tony Luck wrote:
> On Fri, Jun 7, 2013 at 3:23 PM, Tony Luck  wrote:
> > So please don't pull.
> 
> Bother. I see I was a few hours late finding this, and commit 9f29ab11ddb
> is already in Linus' tree.
> 
> That's what happens when I get busy and skip a couple of days testing
> linux-next :-(
> 
> So my problem comes from
> arch/ia64/hp/common/sba_iommu.c
> 
> where the code in sba_init() says:
> 
> acpi_bus_register_driver(&acpi_sba_ioc_driver);
> if (!ioc_list) {
> 
> but because of this change we never managed to call ioc_init()
> so ioc_list doesn't get set up, and we die.
> Before this commit, the call chain looked like this:
> 
>  [] ioc_init+0x40/0xd00
>  [] acpi_sba_ioc_add+0x190/0x1c0
>  [] acpi_device_probe+0xa0/0x280
>  [] really_probe+0xe0/0x520
>  [] driver_probe_device+0x30/0x60
>  [] __driver_attach+0x110/0x160
>  [] bus_for_each_dev+0x110/0x180
>  [] driver_attach+0x40/0x60
>  [] bus_add_driver+0x230/0x580
>  [] driver_register+0xf0/0x400
>  [] acpi_bus_register_driver+0x50/0x80
>  [] sba_init+0x30/0x2d0
> 
> Is my problem that this driver has (or attaches) a "scan handler"
> where it shouldn't ... and I just need to stop it doing that?

Looking into that.

Thanks,
Rafael

--
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 17/31] MIPS: Quit exposing Kconfig symbols in uapi headers.

[David Daney]

From: David Daney 

The kernel's struct pt_regs has many fields conditional on various
Kconfig variables, we cannot be exporting this garbage to user-space.

Move the kernel's definition to asm/ptrace.h, and put a uapi only
version in uapi/asm/ptrace.h gated by #ifndef __KERNEL__

Signed-off-by: David Daney 
---
 arch/mips/include/asm/ptrace.h  | 32 
 arch/mips/include/uapi/asm/ptrace.h | 17 ++---
 2 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/arch/mips/include/asm/ptrace.h b/arch/mips/include/asm/ptrace.h
index a3186f2..5e6cd09 100644
--- a/arch/mips/include/asm/ptrace.h
+++ b/arch/mips/include/asm/ptrace.h
@@ -16,6 +16,38 @@
 #include 
 #include 
 
+/*
+ * This struct defines the way the registers are stored on the stack during a
+ * system call/exception. As usual the registers k0/k1 aren't being saved.
+ */
+struct pt_regs {
+#ifdef CONFIG_32BIT
+   /* Pad bytes for argument save space on the stack. */
+   unsigned long pad0[6];
+#endif
+
+   /* Saved main processor registers. */
+   unsigned long regs[32];
+
+   /* Saved special registers. */
+   unsigned long cp0_status;
+   unsigned long hi;
+   unsigned long lo;
+#ifdef CONFIG_CPU_HAS_SMARTMIPS
+   unsigned long acx;
+#endif
+   unsigned long cp0_badvaddr;
+   unsigned long cp0_cause;
+   unsigned long cp0_epc;
+#ifdef CONFIG_MIPS_MT_SMTC
+   unsigned long cp0_tcstatus;
+#endif /* CONFIG_MIPS_MT_SMTC */
+#ifdef CONFIG_CPU_CAVIUM_OCTEON
+   unsigned long long mpl[3];/* MTM{0,1,2} */
+   unsigned long long mtp[3];/* MTP{0,1,2} */
+#endif
+} __aligned(8);
+
 struct task_struct;
 
 extern int ptrace_getregs(struct task_struct *child, __s64 __user *data);
diff --git a/arch/mips/include/uapi/asm/ptrace.h 
b/arch/mips/include/uapi/asm/ptrace.h
index 4d58d84..b26f7e3 100644
--- a/arch/mips/include/uapi/asm/ptrace.h
+++ b/arch/mips/include/uapi/asm/ptrace.h
@@ -22,16 +22,12 @@
 #define DSP_CONTROL77
 #define ACX78
 
+#ifndef __KERNEL__
 /*
  * This struct defines the way the registers are stored on the stack during a
  * system call/exception. As usual the registers k0/k1 aren't being saved.
  */
 struct pt_regs {
-#ifdef CONFIG_32BIT
-   /* Pad bytes for argument save space on the stack. */
-   unsigned long pad0[6];
-#endif
-
/* Saved main processor registers. */
unsigned long regs[32];
 
@@ -39,20 +35,11 @@ struct pt_regs {
unsigned long cp0_status;
unsigned long hi;
unsigned long lo;
-#ifdef CONFIG_CPU_HAS_SMARTMIPS
-   unsigned long acx;
-#endif
unsigned long cp0_badvaddr;
unsigned long cp0_cause;
unsigned long cp0_epc;
-#ifdef CONFIG_MIPS_MT_SMTC
-   unsigned long cp0_tcstatus;
-#endif /* CONFIG_MIPS_MT_SMTC */
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-   unsigned long long mpl[3];/* MTM{0,1,2} */
-   unsigned long long mtp[3];/* MTP{0,1,2} */
-#endif
 } __attribute__ ((aligned (8)));
+#endif /* __KERNEL__ */
 
 /* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
 #define PTRACE_GETREGS 12
-- 
1.7.11.7

--
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/8] device: avoid format string in dev_set_name

[Greg Kroah-Hartman]

On Thu, Jun 06, 2013 at 01:52:22PM -0700, Kees Cook wrote:
> --- a/mm/backing-dev.c
> +++ b/mm/backing-dev.c
> @@ -515,7 +515,6 @@ EXPORT_SYMBOL(bdi_destroy);
>  int bdi_setup_and_register(struct backing_dev_info *bdi, char *name,
>  unsigned int cap)
>  {
> - char tmp[32];
>   int err;
>  
>   bdi->name = name;
> @@ -524,8 +523,8 @@ int bdi_setup_and_register(struct backing_dev_info *bdi, 
> char *name,
>   if (err)
>   return err;
>  
> - sprintf(tmp, "%.28s%s", name, "-%d");
> - err = bdi_register(bdi, NULL, tmp, atomic_long_inc_return(&bdi_seq));
> + err = bdi_register(bdi, NULL, "%.28s-%d", name,
> +atomic_long_inc_return(&bdi_seq));
>   if (err) {
>   bdi_destroy(bdi);
>   return err;

This chunk causes the following build warning to now show up:
mm/backing-dev.c: In function ‘bdi_setup_and_register’:
mm/backing-dev.c:527:7: warning: format ‘%d’ expects argument of type ‘int’, 
but argument 5 has type ‘long int’ [-Wformat]

Care to fix it up and resend it?

thanks,

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/

[PATCH 16/31] mips/kvm: Add exception handler for MIPSVZ Guest exceptions.

[David Daney]

From: David Daney 

Signed-off-by: David Daney 
---
 arch/mips/kernel/genex.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S
index 163e299..ce0be96 100644
--- a/arch/mips/kernel/genex.S
+++ b/arch/mips/kernel/genex.S
@@ -486,6 +486,9 @@ NESTED(nmi_handler, PT_SIZE, sp)
BUILD_HANDLER mcheck mcheck cli verbose /* #24 */
BUILD_HANDLER mt mt sti silent  /* #25 */
BUILD_HANDLER dsp dsp sti silent/* #26 */
+#ifdef CONFIG_KVM_MIPSVZ
+   BUILD_HANDLER hypervisor hypervisor cli silent  /* #27 */
+#endif
BUILD_HANDLER reserved reserved sti verbose /* others */
 
.align  5
-- 
1.7.11.7

--
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 14/31] mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest Mode.

[David Daney]

From: David Daney 

Signed-off-by: David Daney 
---
 arch/mips/include/asm/thread_info.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/include/asm/thread_info.h 
b/arch/mips/include/asm/thread_info.h
index 895320e..a7a894a 100644
--- a/arch/mips/include/asm/thread_info.h
+++ b/arch/mips/include/asm/thread_info.h
@@ -109,6 +109,7 @@ static inline struct thread_info *current_thread_info(void)
 #define TIF_RESTORE_SIGMASK9   /* restore signal mask in do_signal() */
 #define TIF_USEDFPU16  /* FPU was used by this task this 
quantum (SMP) */
 #define TIF_MEMDIE 18  /* is terminating due to OOM killer */
+#define TIF_GUESTMODE  19  /* If set, running in VZ Guest mode. */
 #define TIF_FIXADE 20  /* Fix address errors in software */
 #define TIF_LOGADE 21  /* Log address errors to syslog */
 #define TIF_32BIT_REGS 22  /* also implies 16/32 fprs */
@@ -124,6 +125,7 @@ static inline struct thread_info *current_thread_info(void)
 #define _TIF_SECCOMP   (1

[PATCH 15/31] mips/kvm: Exception handling to leave and reenter guest mode.

[David Daney]

From: David Daney 

Currently this is a little complex, here are the facts about how it works:

o When running in Guest mode we set the high bit of CP0_XCONTEXT.  If
  this bit is clear, we don't do anything special on an exception.

o If we are in guest mode, upon an exception we:

  1) load the stack pointer from the mips_kvm_rootsp array instead of
 kernelsp.

  2) Clear GuestCtl[GM] and high bit of CP0_XCONTEXT.

  3) Restore host ASID and PGD pointer.

o Upon restarting from an exception we test the task TIF_GUESTMODE
  flag if it is clear, nothing special is done.

o If Guest mode is active for the thread we:

  1) Compare the stack pointer to mips_kvm_rootsp, if it doesn't match
 we are not reentering guest mode, so no more special processing
 is done.

  2) If reentering guest mode:

  2a) Set high bit of CP0_XCONTEXT and GuestCtl[GM].

  2b) Set Guest mode ASID and PGD pointer.

This allows a single set of exception handlers to be used for both
host and guest mode operation.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/stackframe.h | 135 -
 1 file changed, 132 insertions(+), 3 deletions(-)

diff --git a/arch/mips/include/asm/stackframe.h 
b/arch/mips/include/asm/stackframe.h
index 20627b2..bf2ec48 100644
--- a/arch/mips/include/asm/stackframe.h
+++ b/arch/mips/include/asm/stackframe.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * For SMTC kernel, global IE should be left set, and interrupts
@@ -98,7 +99,9 @@
 #define CPU_ID_REG CP0_CONTEXT
 #define CPU_ID_MFC0 MFC0
 #endif
-   .macro  get_saved_sp/* SMP variation */
+#define CPU_ID_MASK ((1 << 13) - 1)
+
+   .macro  get_saved_sp_for_save_some  /* SMP variation */
CPU_ID_MFC0 k0, CPU_ID_REG
 #if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
lui k1, %hi(kernelsp)
@@ -110,15 +113,49 @@
dsllk1, 16
 #endif
LONG_SRLk0, PTEBASE_SHIFT
+#ifdef CONFIG_KVM_MIPSVZ
+   andik0, CPU_ID_MASK /* high bits indicate guest mode. */
+#endif
LONG_ADDU   k1, k0
LONG_L  k1, %lo(kernelsp)(k1)
.endm
 
+   .macro get_saved_sp
+   CPU_ID_MFC0 k0, CPU_ID_REG
+   get_saved_sp_for_save_some
+   .endm
+
+   .macro  get_mips_kvm_rootsp /* SMP variation */
+#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
+   lui k1, %hi(mips_kvm_rootsp)
+#else
+   lui k1, %highest(mips_kvm_rootsp)
+   daddiu  k1, %higher(mips_kvm_rootsp)
+   dsllk1, 16
+   daddiu  k1, %hi(mips_kvm_rootsp)
+   dsllk1, 16
+#endif
+   LONG_SRLk0, PTEBASE_SHIFT
+   andik0, CPU_ID_MASK /* high bits indicate guest mode. */
+   LONG_ADDU   k1, k0
+   LONG_L  k1, %lo(mips_kvm_rootsp)(k1)
+   .endm
+
.macro  set_saved_sp stackp temp temp2
CPU_ID_MFC0 \temp, CPU_ID_REG
LONG_SRL\temp, PTEBASE_SHIFT
+#ifdef CONFIG_KVM_MIPSVZ
+   andik0, CPU_ID_MASK /* high bits indicate guest mode. */
+#endif
LONG_S  \stackp, kernelsp(\temp)
.endm
+
+   .macro  set_mips_kvm_rootsp stackp temp
+   CPU_ID_MFC0 \temp, CPU_ID_REG
+   LONG_SRL\temp, PTEBASE_SHIFT
+   andik0, CPU_ID_MASK /* high bits indicate guest mode. */
+   LONG_S  \stackp, mips_kvm_rootsp(\temp)
+   .endm
 #else
.macro  get_saved_sp/* Uniprocessor variation */
 #ifdef CONFIG_CPU_JUMP_WORKAROUNDS
@@ -152,9 +189,27 @@
LONG_L  k1, %lo(kernelsp)(k1)
.endm
 
+   .macro  get_mips_kvm_rootsp /* Uniprocessor variation */
+#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32)
+   lui k1, %hi(mips_kvm_rootsp)
+#else
+   lui k1, %highest(mips_kvm_rootsp)
+   daddiu  k1, %higher(mips_kvm_rootsp)
+   dsllk1, k1, 16
+   daddiu  k1, %hi(mips_kvm_rootsp)
+   dsllk1, k1, 16
+#endif
+   LONG_L  k1, %lo(mips_kvm_rootsp)(k1)
+   .endm
+
+
.macro  set_saved_sp stackp temp temp2
LONG_S  \stackp, kernelsp
.endm
+
+   .macro  set_mips_kvm_rootsp stackp temp
+   LONG_S  \stackp, mips_kvm_rootsp
+   .endm
 #endif
 
.macro  SAVE_SOME
@@ -164,11 +219,21 @@
mfc0k0, CP0_STATUS
sll k0, 3   /* extract cu0 bit */
.setnoreorder
+#ifdef CONFIG_KVM_MIPSVZ
+   bgezk0, 7f
+CPU_ID_MFC0k0, CPU_ID_REG
+   bgezk0, 8f
+ 

[PATCH 13/31] mips/kvm: Add accessors for MIPS VZ registers.

[David Daney]

From: David Daney 

There are accessors for both the guest control registers as well as
guest CP0 context.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/mipsregs.h | 260 +++
 1 file changed, 260 insertions(+)

diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index 6f03c72..0addfec 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -50,10 +50,13 @@
 #define CP0_WIRED $6
 #define CP0_INFO $7
 #define CP0_BADVADDR $8
+#define CP0_BADINSTR $8, 1
+#define CP0_BADINSTRP $8, 2
 #define CP0_COUNT $9
 #define CP0_ENTRYHI $10
 #define CP0_COMPARE $11
 #define CP0_STATUS $12
+#define CP0_GUESTCTL0 $12, 6
 #define CP0_CAUSE $13
 #define CP0_EPC $14
 #define CP0_PRID $15
@@ -623,6 +626,10 @@
 #define MIPS_FPIR_L(_ULCAST_(1) << 21)
 #define MIPS_FPIR_F64  (_ULCAST_(1) << 22)
 
+/* Bits in the MIPS VZ GuestCtl0 Register */
+#define MIPS_GUESTCTL0B_GM 31
+#define MIPS_GUESTCTL0F_GM (_ULCAST_(1) << MIPS_GUESTCTL0B_GM)
+
 #ifndef __ASSEMBLY__
 
 /*
@@ -851,6 +858,144 @@ do {  
\
local_irq_restore(__flags); \
 } while (0)
 
+/*
+ * Macros to access the VZ Guest system control coprocessor
+ */
+
+#define __read_32bit_gc0_register(source, sel) \
+   ({ int __res;   \
+   __asm__ __volatile__(   \
+   ".set mips64r2\n\t" \
+   ".set\tvirt\n\t"\
+   ".ifeq 0-" #sel "\n\t"  \
+   "mfgc0\t%0, " #source ", 0\n\t" \
+   ".endif\n\t"\
+   ".ifeq 1-" #sel "\n\t"  \
+   "mfgc0\t%0, " #source ", 1\n\t" \
+   ".endif\n\t"\
+   ".ifeq 2-" #sel "\n\t"  \
+   "mfgc0\t%0, " #source ", 2\n\t" \
+   ".endif\n\t"\
+   ".ifeq 3-" #sel "\n\t"  \
+   "mfgc0\t%0, " #source ", 3\n\t" \
+   ".endif\n\t"\
+   ".ifeq 4-" #sel "\n\t"  \
+   "mfgc0\t%0, " #source ", 4\n\t" \
+   ".endif\n\t"\
+   ".ifeq 5-" #sel "\n\t"  \
+   "mfgc0\t%0, " #source ", 5\n\t" \
+   ".endif\n\t"\
+   ".ifeq 6-" #sel "\n\t"  \
+   "mfgc0\t%0, " #source ", 6\n\t" \
+   ".endif\n\t"\
+   ".ifeq 7-" #sel "\n\t"  \
+   "mfgc0\t%0, " #source ", 7\n\t" \
+   ".endif\n\t"\
+   ".set\tmips0"   \
+   : "=r" (__res));\
+   __res;  \
+})
+
+#define __read_64bit_gc0_register(source, sel) \
+   ({ unsigned long long __res;\
+   __asm__ __volatile__(   \
+   ".set mips64r2\n\t" \
+   ".set\tvirt\n\t"\
+   ".ifeq 0-" #sel "\n\t"  \
+   "dmfgc0\t%0, " #source ", 0\n\t"\
+   ".endif\n\t"\
+   ".ifeq 1-" #sel "\n\t"  \
+   "dmfgc0\t%0, " #source ", 1\n\t"\
+   ".endif\n\t"\
+   ".ifeq 2-" #sel "\n\t"  \
+   "dmfgc0\t%0, " #source ", 2\n\t"\
+   ".endif\n\t"\
+   ".ifeq 3-" #sel "\n\t"  \
+   "dmfgc0\t%0, " #source ", 3\n\t"\
+   ".endif\n\t"\
+   ".i

[PATCH 22/31] mips/kvm: Split get_new_mmu_context into two parts.

[David Daney]

From: David Daney 

The new function (part) get_new_asid() can now be used from MIPSVZ code.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/mmu_context.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/mmu_context.h 
b/arch/mips/include/asm/mmu_context.h
index 8201160..5609a32 100644
--- a/arch/mips/include/asm/mmu_context.h
+++ b/arch/mips/include/asm/mmu_context.h
@@ -108,8 +108,8 @@ static inline void enter_lazy_tlb(struct mm_struct *mm, 
struct task_struct *tsk)
 
 #ifndef CONFIG_MIPS_MT_SMTC
 /* Normal, classic MIPS get_new_mmu_context */
-static inline void
-get_new_mmu_context(struct mm_struct *mm, unsigned long cpu)
+static inline unsigned long
+get_new_asid(unsigned long cpu)
 {
extern void kvm_local_flush_tlb_all(void);
unsigned long asid = asid_cache(cpu);
@@ -125,7 +125,13 @@ get_new_mmu_context(struct mm_struct *mm, unsigned long 
cpu)
if (!asid)  /* fix version if needed */
asid = ASID_FIRST_VERSION;
}
+   return asid;
+}
 
+static inline void
+get_new_mmu_context(struct mm_struct *mm, unsigned long cpu)
+{
+   unsigned long asid = get_new_asid(cpu);
cpu_context(cpu, mm) = asid_cache(cpu) = asid;
 }
 
-- 
1.7.11.7

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

[PATCH 21/31] mips/kvm: Allow set_except_vector() to be used from MIPSVZ code.

[David Daney]

From: David Daney 

We need to move it out of __init so we don't have section mismatch problems.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/uasm.h | 2 +-
 arch/mips/kernel/traps.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/uasm.h b/arch/mips/include/asm/uasm.h
index 370d967..90b4f5e 100644
--- a/arch/mips/include/asm/uasm.h
+++ b/arch/mips/include/asm/uasm.h
@@ -11,7 +11,7 @@
 
 #include 
 
-#ifdef CONFIG_EXPORT_UASM
+#if defined(CONFIG_EXPORT_UASM) || IS_ENABLED(CONFIG_KVM_MIPSVZ)
 #include 
 #define __uasminit
 #define __uasminitdata
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index f008795..fca0a2f 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1457,7 +1457,7 @@ unsigned long ebase;
 unsigned long exception_handlers[32];
 unsigned long vi_handlers[64];
 
-void __init *set_except_vector(int n, void *addr)
+void __uasminit *set_except_vector(int n, void *addr)
 {
unsigned long handler = (unsigned long) addr;
unsigned long old_handler;
-- 
1.7.11.7

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

[PATCH 19/31] mips/kvm: Add host definitions for MIPS VZ based host.

[David Daney]

From: David Daney 

Signed-off-by: David Daney 
---
 arch/mips/include/asm/kvm_mips_vz.h | 29 +
 1 file changed, 29 insertions(+)
 create mode 100644 arch/mips/include/asm/kvm_mips_vz.h

diff --git a/arch/mips/include/asm/kvm_mips_vz.h 
b/arch/mips/include/asm/kvm_mips_vz.h
new file mode 100644
index 000..dfc6951
--- /dev/null
+++ b/arch/mips/include/asm/kvm_mips_vz.h
@@ -0,0 +1,29 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2013 Cavium, Inc.
+ */
+#ifndef _ASM_KVM_MIPS_VZ_H
+#define _ASM_KVM_MIPS_VZ_H
+
+struct kvm;
+
+struct kvm_mips_vz {
+   struct mutex guest_mm_lock;
+   pgd_t *pgd; /* Translations for this host. */
+   spinlock_t irq_chip_lock;
+   struct page *irq_chip;
+   unsigned int asid[NR_CPUS]; /* Per CPU ASIDs for pgd. */
+};
+
+bool mipsvz_page_fault(struct pt_regs *regs, unsigned long write,
+  unsigned long address);
+
+bool mipsvz_cp_unusable(struct pt_regs *regs);
+int mipsvz_arch_init(void *opaque);
+int mipsvz_arch_hardware_enable(void *garbage);
+int mipsvz_init_vm(struct kvm *kvm, unsigned long type);
+
+#endif /* _ASM_KVM_MIPS_VZ_H */
-- 
1.7.11.7

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

[PATCH 20/31] mips/kvm: Hook into TLB fault handlers.

[David Daney]

From: David Daney 

If the CPU is operating in guest mode when a TLB related excpetion
occurs, give KVM a chance to do emulation.

Signed-off-by: David Daney 
---
 arch/mips/mm/fault.c   | 8 
 arch/mips/mm/tlbex-fault.S | 6 ++
 2 files changed, 14 insertions(+)

diff --git a/arch/mips/mm/fault.c b/arch/mips/mm/fault.c
index 0fead53..9391da49 100644
--- a/arch/mips/mm/fault.c
+++ b/arch/mips/mm/fault.c
@@ -26,6 +26,7 @@
 #include 
 #include/* For VMALLOC_END */
 #include 
+#include 
 
 /*
  * This routine handles page faults.  It determines the address,
@@ -50,6 +51,13 @@ asmlinkage void __kprobes do_page_fault(struct pt_regs 
*regs, unsigned long writ
   field, regs->cp0_epc);
 #endif
 
+#ifdef CONFIG_KVM_MIPSVZ
+   if (test_tsk_thread_flag(current, TIF_GUESTMODE)) {
+   if (mipsvz_page_fault(regs, write, address))
+   return;
+   }
+#endif
+
 #ifdef CONFIG_KPROBES
/*
 * This is to notify the fault handler of the kprobes.  The
diff --git a/arch/mips/mm/tlbex-fault.S b/arch/mips/mm/tlbex-fault.S
index 318855e..df0f70b 100644
--- a/arch/mips/mm/tlbex-fault.S
+++ b/arch/mips/mm/tlbex-fault.S
@@ -14,6 +14,12 @@
NESTED(tlb_do_page_fault_\write, PT_SIZE, sp)
SAVE_ALL
MFC0a2, CP0_BADVADDR
+#ifdef CONFIG_KVM_MIPSVZ
+   mfc0v0, CP0_BADINSTR
+   mfc0v1, CP0_BADINSTRP
+   sw  v0, PT_BADINSTR(sp)
+   sw  v1, PT_BADINSTRP(sp)
+#endif
KMODE
movea0, sp
REG_S   a2, PT_BVADDR(sp)
-- 
1.7.11.7

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

[PATCH 18/31] mips/kvm: Add pt_regs slots for BadInstr and BadInstrP

[David Daney]

From: David Daney 

These save the instruction word to be used by MIPSVZ code for
instruction emulation.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/ptrace.h | 4 
 arch/mips/kernel/asm-offsets.c | 4 
 2 files changed, 8 insertions(+)

diff --git a/arch/mips/include/asm/ptrace.h b/arch/mips/include/asm/ptrace.h
index 5e6cd09..d080716 100644
--- a/arch/mips/include/asm/ptrace.h
+++ b/arch/mips/include/asm/ptrace.h
@@ -46,6 +46,10 @@ struct pt_regs {
unsigned long long mpl[3];/* MTM{0,1,2} */
unsigned long long mtp[3];/* MTP{0,1,2} */
 #endif
+#ifdef CONFIG_KVM_MIPSVZ
+   unsigned int cp0_badinstr;  /* Only populated on 
do_page_fault_{0,1} */
+   unsigned int cp0_badinstrp; /* Only populated on 
do_page_fault_{0,1} */
+#endif
 } __aligned(8);
 
 struct task_struct;
diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c
index 03bf363..c5cc28f 100644
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -71,6 +71,10 @@ void output_ptreg_defines(void)
OFFSET(PT_MPL, pt_regs, mpl);
OFFSET(PT_MTP, pt_regs, mtp);
 #endif /* CONFIG_CPU_CAVIUM_OCTEON */
+#ifdef CONFIG_KVM_MIPSVZ
+   OFFSET(PT_BADINSTR, pt_regs, cp0_badinstr);
+   OFFSET(PT_BADINSTRP, pt_regs, cp0_badinstrp);
+#endif
DEFINE(PT_SIZE, sizeof(struct pt_regs));
BLANK();
 }
-- 
1.7.11.7

--
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: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))

[luke.leighton]

On Fri, Jun 7, 2013 at 11:08 PM, Maxime Ripard
 wrote:
> On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote:
>>  maxime: we need to talk :)
>>
>>  please tell me in 4 or 5 sentences what you've managed to do so far,
>> expanding a little on what thomas says below, more specifically what
>> it achieves and/or allows rather than technically what it does
>> (suitable for managers and directors in other words), and what plans
>> you'd like to see happen.
>
> You mean something like http://linux-sunxi.org/Linux_mainlining_effort ?

 ahh, fantastic.  with references too.  magic.  exactly what i need.
thank you.  listed now at
http://hands.com/~lkcl/allwinner_linux_proposal.txt

> You should really do a bit of research before starting a thread like
> this one.

 then that gives you some idea of how busy i've been and still am, to
not be aware even of things like this, to have kicked a project off
some 18-24 months ago and not be able to keep up with one of the many
branches and initiatives that it's spawned.

 when i said i've been caught off-guard by this opportunity i meant
exactly what i said.

> This webpage has been around for like 9 monthes now on the wiki
> of a community you pretend to represent

 i pretend no such thing and apologise for giving any impression of such.

> (even though I fail to get how
> you can pretend such thing, but that's another topic).

 i have a different focus: a meta-project of sorts, where allwinner
happened to be the first.  look up rhombus-tech and EOMA68 and it'll
become a bit clearer.

>> > is the maintainer of the mainline Allwinner sunxi
>> > effort. It already supports a number of boards, has a pinctrl driver, a
>> > GPIO driver, serial port is working, network is working, I2C is
>> > working.
>> >
>> > All in mainline, completely Device Tree based.
>>
>>  great.  which version did it first hit, i.e. what will the first
>> signs of this be when allwinner begin doing "git pulls"?
>
> 3.8, as shown in the wiki page

 got that.

>>  and which boards.  bear in mind that one of those "boards" should
>> really be "the total range of products available across hundreds of
>> chinese tablet clone manufacturers".
>>
>>  specific question: is one of the "boards" the one that tom cubie
>> submitted, which covers virtually every android tablet product
>> manufactured in the millions by chinese tablet clone manufacturers?
>
> Again, wiki.

 yep, am there now.

>> > So isn't this entire discussion completely moot?
>>
>>  no because it's totally in isolation from allwinner.  i need to give
>> them a heads-up, and get them involved, giving them specific
>> incentives [which nobody's yet given!!] for following a particular
>> path [or paths] yet to be recommended.
>>
>> > The mainline support
>> > for sunxi has already started since 6 months or so, and has been Device
>> > Tree based from day one.
>>
>> to clarify: the *community-driven* mainline support for sunxi.  ok -
>> which chips?  sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
>> (Dual-Core Cortex A7)?  which ones are in?
>
> A10, A13 for the moment. I just received hardware with A10s, A20 and A31
> that I need to work on, but support should come quite soon.

 superb.  question: what help or other resources could you do with?
what additional information?


> I already
> have some patches pending to be tested on an A31 board, but didn't have
> as much time as I wanted lately to actually set a proper environment to
> test them.

 ok - good to know.  btw when you get to it please note a bug found in
the "vanilla" [allwinner-released] A20 3.3 tree where they reduced a
128 byte buffer to 78 bytes for spurious reasons; the critical fix is
at line 989, of the following patch:

 
http://git.rhombus-tech.net/?p=linux.git;a=commitdiff;h=refs/heads/lkcl-3.3-a20;hp=6c5753e5dc1fafff288d522c94b40a7dd2a81adc

 i found this by running a diff -u of sun4i_usb from the 3.4 sunxi
community tree against the sun7i_usb tree from the allwinner 3.3
release.  amongst the desperate attempts to disable DMA (probably due
to stack corruption of the above bug) and various renaming attempts of
*SUN4I* to *SUN7I*, that one stuck out like a sore thumb.  the other
bits - which may or may not be relevant - are the spinlock protection
and the call to sw_udc_enable which is present in the sun4i_usb 3.4
code but not the A20 3.3 code.

mileage may vary, and the buffer overrun only happens if you enable
the OTG interface as "dual" (auto-detect) because that's enough
features in the bitfield to cause there to be enough strcpy's... oops
:)

l.
--
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 28/31] mips/kvm: Only use KVM_COALESCED_MMIO_PAGE_OFFSET with KVM_MIPSTE

[David Daney]

From: David Daney 

The forthcoming MIPSVZ code doesn't currently use this, so it must
only be enabled for KVM_MIPSTE.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/kvm_host.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 505b804..9f209e1 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -25,7 +25,9 @@
 /* memory slots that does not exposed to userspace */
 #define KVM_PRIVATE_MEM_SLOTS  0
 
+#ifdef CONFIG_KVM_MIPSTE
 #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
+#endif
 
 /* Don't support huge pages */
 #define KVM_HPAGE_GFN_SHIFT(x) 0
-- 
1.7.11.7

--
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 25/31] mips/kvm: Add some asm-offsets constants used by MIPSVZ.

[David Daney]

From: David Daney 

Signed-off-by: David Daney 
---
 arch/mips/kernel/asm-offsets.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c
index 37fd9e2..db09376 100644
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 void output_ptreg_defines(void)
 {
@@ -345,6 +346,8 @@ void output_pbe_defines(void)
 void output_kvm_defines(void)
 {
COMMENT(" KVM/MIPS Specfic offsets. ");
+   OFFSET(KVM_ARCH_IMPL, kvm, arch.impl);
+   OFFSET(KVM_VCPU_KVM, kvm_vcpu, kvm);
DEFINE(VCPU_ARCH_SIZE, sizeof(struct kvm_vcpu_arch));
OFFSET(VCPU_RUN, kvm_vcpu, run);
OFFSET(VCPU_HOST_ARCH, kvm_vcpu, arch);
@@ -411,5 +414,9 @@ void output_kvm_defines(void)
OFFSET(COP0_TLB_HI, mips_coproc, reg[MIPS_CP0_TLB_HI][0]);
OFFSET(COP0_STATUS, mips_coproc, reg[MIPS_CP0_STATUS][0]);
BLANK();
+
+   COMMENT(" Linux struct kvm mipsvz offsets. ");
+   OFFSET(KVM_MIPS_VZ_PGD, kvm_mips_vz, pgd);
+   BLANK();
 }
 #endif
-- 
1.7.11.7

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

[PATCH 24/31] mips/kvm: Add thread_struct fields used by MIPSVZ hosts.

[David Daney]

From: David Daney 

... and their accessors in asm-offsets.c

Signed-off-by: David Daney 
---
 arch/mips/include/asm/processor.h | 6 ++
 arch/mips/kernel/asm-offsets.c| 5 +
 2 files changed, 11 insertions(+)

diff --git a/arch/mips/include/asm/processor.h 
b/arch/mips/include/asm/processor.h
index 1470b7b..e0aa198 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -198,6 +198,7 @@ typedef struct {
 #define ARCH_MIN_TASKALIGN 8
 
 struct mips_abi;
+struct kvm_vcpu;
 
 /*
  * If you change thread_struct remember to change the #defines below too!
@@ -230,6 +231,11 @@ struct thread_struct {
unsigned long cp0_badvaddr; /* Last user fault */
unsigned long cp0_baduaddr; /* Last kernel fault accessing USEG */
unsigned long error_code;
+#ifdef CONFIG_KVM_MIPSVZ
+   struct kvm_vcpu *vcpu;
+   unsigned int mm_asid;
+   unsigned int guest_asid;
+#endif
 #ifdef CONFIG_CPU_CAVIUM_OCTEON
 struct octeon_cop2_state cp2 __attribute__ ((__aligned__(128)));
 struct octeon_cvmseg_state cvmseg __attribute__ ((__aligned__(128)));
diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c
index c5cc28f..37fd9e2 100644
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -132,6 +132,11 @@ void output_thread_defines(void)
   thread.cp0_baduaddr);
OFFSET(THREAD_ECODE, task_struct, \
   thread.error_code);
+#ifdef CONFIG_KVM_MIPSVZ
+   OFFSET(THREAD_VCPU, task_struct, thread.vcpu);
+   OFFSET(THREAD_MM_ASID, task_struct, thread.mm_asid);
+   OFFSET(THREAD_GUEST_ASID, task_struct, thread.guest_asid);
+#endif
BLANK();
 }
 
-- 
1.7.11.7

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

[PATCH 23/31] mips/kvm: Hook into CP unusable exception handler.

[David Daney]

From: David Daney 

The MIPS VZ KVM code needs this to be able to manage the FPU.

Signed-off-by: David Daney 
---
 arch/mips/kernel/traps.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index fca0a2f..2bdeb32 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern void check_wait(void);
 extern asmlinkage void rollback_handle_int(void);
@@ -1045,6 +1046,13 @@ asmlinkage void do_cpu(struct pt_regs *regs)
int status;
unsigned long __maybe_unused flags;
 
+#ifdef CONFIG_KVM_MIPSVZ
+   if (test_tsk_thread_flag(current, TIF_GUESTMODE)) {
+   if (mipsvz_cp_unusable(regs))
+   return;
+   }
+#endif
+
die_if_kernel("do_cpu invoked from kernel context!", regs);
 
cpid = (regs->cp0_cause >> CAUSEB_CE) & 3;
-- 
1.7.11.7

--
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 31/31] mips/kvm: Allow for upto 8 KVM vcpus per vm.

[David Daney]

From: David Daney 

The mipsvz implementation allows for SMP, so let's be able to create
all those vcpus.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/kvm_host.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 9f209e1..0a5e218 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -20,7 +20,7 @@
 #include 
 
 
-#define KVM_MAX_VCPUS  1
+#define KVM_MAX_VCPUS  8
 #define KVM_USER_MEM_SLOTS 8
 /* memory slots that does not exposed to userspace */
 #define KVM_PRIVATE_MEM_SLOTS  0
-- 
1.7.11.7

--
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 26/31] mips/kvm: Split up Kconfig and Makefile definitions in preperation for MIPSVZ.

[David Daney]

From: David Daney 

Create the symbol KVM_MIPSTE, and use it to select the trap and
emulate specific things.

Signed-off-by: David Daney 
---
 arch/mips/kvm/Kconfig  | 14 +-
 arch/mips/kvm/Makefile | 14 --
 2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig
index 2c15590..95c0d22 100644
--- a/arch/mips/kvm/Kconfig
+++ b/arch/mips/kvm/Kconfig
@@ -16,18 +16,22 @@ menuconfig VIRTUALIZATION
 if VIRTUALIZATION
 
 config KVM
-   tristate "Kernel-based Virtual Machine (KVM) support"
-   depends on HAVE_KVM
+   tristate
select PREEMPT_NOTIFIERS
+
+config KVM_MIPSTE
+   tristate "Kernel-based Virtual Machine (KVM) 32-bit trap-and-emulate"
+   depends on HAVE_KVM
+   select KVM
select ANON_INODES
select KVM_MMIO
---help---
- Support for hosting Guest kernels.
+ Support for hosting Guest kernels with modified address space layout.
  Currently supported on MIPS32 processors.
 
 config KVM_MIPS_DYN_TRANS
bool "KVM/MIPS: Dynamic binary translation to reduce traps"
-   depends on KVM
+   depends on KVM_MIPSTE
---help---
  When running in Trap & Emulate mode patch privileged
  instructions to reduce the number of traps.
@@ -36,7 +40,7 @@ config KVM_MIPS_DYN_TRANS
 
 config KVM_MIPS_DEBUG_COP0_COUNTERS
bool "Maintain counters for COP0 accesses"
-   depends on KVM
+   depends on KVM_MIPSTE
---help---
  Maintain statistics for Guest COP0 accesses.
  A histogram of COP0 accesses is printed when the VM is
diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
index 78d87bb..3377197 100644
--- a/arch/mips/kvm/Makefile
+++ b/arch/mips/kvm/Makefile
@@ -1,13 +1,15 @@
 # Makefile for KVM support for MIPS
 #
 
-common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o coalesced_mmio.o)
+common-objs = $(addprefix ../../../virt/kvm/, kvm_main.o)
 
 EXTRA_CFLAGS += -Ivirt/kvm -Iarch/mips/kvm
 
-kvm-objs := $(common-objs) kvm_mips.o kvm_mips_emul.o kvm_locore.o \
-   kvm_mips_int.o kvm_mips_stats.o kvm_mips_commpage.o \
-   kvm_mips_dyntrans.o kvm_trap_emul.o
+kvm_mipste-objs:= kvm_mips_emul.o kvm_locore.o kvm_mips_int.o \
+  kvm_mips_stats.o kvm_mips_commpage.o \
+  kvm_mips_dyntrans.o kvm_trap_emul.o kvm_cb.o \
+  kvm_tlb.o \
+  $(addprefix ../../../virt/kvm/, coalesced_mmio.o)
 
-obj-$(CONFIG_KVM)  += kvm.o
-obj-y  += kvm_cb.o kvm_tlb.o
+obj-$(CONFIG_KVM)  += $(common-objs) kvm_mips.o
+obj-$(CONFIG_KVM_MIPSTE)   += kvm_mipste.o
-- 
1.7.11.7

--
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 27/31] mips/kvm: Gate the use of kvm_local_flush_tlb_all() by KVM_MIPSTE

[David Daney]

From: David Daney 

Only the trap-and-emulate KVM code needs a Special tlb flusher.  All
other configurations should use the regular version.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/mmu_context.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/mmu_context.h 
b/arch/mips/include/asm/mmu_context.h
index 5609a32..04d0b74 100644
--- a/arch/mips/include/asm/mmu_context.h
+++ b/arch/mips/include/asm/mmu_context.h
@@ -117,7 +117,7 @@ get_new_asid(unsigned long cpu)
if (! ((asid += ASID_INC) & ASID_MASK) ) {
if (cpu_has_vtag_icache)
flush_icache_all();
-#ifdef CONFIG_VIRTUALIZATION
+#if IS_ENABLED(CONFIG_KVM_MIPSTE)
kvm_local_flush_tlb_all();  /* start new asid cycle */
 #else
local_flush_tlb_all();  /* start new asid cycle */
-- 
1.7.11.7

--
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 30/31] mips/kvm: Enable MIPSVZ in Kconfig/Makefile

[David Daney]

From: David Daney 

Also let CPU_CAVIUM_OCTEON select KVM.

Signed-off-by: David Daney 
---
 arch/mips/Kconfig  | 1 +
 arch/mips/kvm/Kconfig  | 9 +
 arch/mips/kvm/Makefile | 1 +
 3 files changed, 11 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 7a58ab9..16e3d22 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1426,6 +1426,7 @@ config CPU_CAVIUM_OCTEON
select LIBFDT
select USE_OF
select USB_EHCI_BIG_ENDIAN_MMIO
+   select HAVE_KVM
help
  The Cavium Octeon processor is a highly integrated chip containing
  many ethernet hardware widgets for networking tasks. The processor
diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig
index 95c0d22..32a5016 100644
--- a/arch/mips/kvm/Kconfig
+++ b/arch/mips/kvm/Kconfig
@@ -48,6 +48,15 @@ config KVM_MIPS_DEBUG_COP0_COUNTERS
 
  If unsure, say N.
 
+config KVM_MIPSVZ
+   bool "Kernel-based Virtual Machine (KVM) using hardware MIPS-VZ support"
+   depends on HAVE_KVM
+   select KVM
+   ---help---
+ Support for hosting Guest kernels on hardware with the
+ MIPS-VZ hardware module.
+
+
 source drivers/vhost/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/arch/mips/kvm/Makefile b/arch/mips/kvm/Makefile
index 3377197..595358f 100644
--- a/arch/mips/kvm/Makefile
+++ b/arch/mips/kvm/Makefile
@@ -13,3 +13,4 @@ kvm_mipste-objs   := kvm_mips_emul.o kvm_locore.o 
kvm_mips_int.o \
 
 obj-$(CONFIG_KVM)  += $(common-objs) kvm_mips.o
 obj-$(CONFIG_KVM_MIPSTE)   += kvm_mipste.o
+obj-$(CONFIG_KVM_MIPSVZ)   += kvm_mipsvz.o kvm_mipsvz_guest.o
-- 
1.7.11.7

--
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 12/31] MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al.

[David Daney]

From: David Daney 

---
 arch/mips/include/uapi/asm/inst.h | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/mips/include/uapi/asm/inst.h 
b/arch/mips/include/uapi/asm/inst.h
index 0f4aec2..133abc1 100644
--- a/arch/mips/include/uapi/asm/inst.h
+++ b/arch/mips/include/uapi/asm/inst.h
@@ -117,7 +117,8 @@ enum bcop_op {
 enum cop0_coi_func {
tlbr_op   = 0x01, tlbwi_op  = 0x02,
tlbwr_op  = 0x06, tlbp_op   = 0x08,
-   rfe_op= 0x10, eret_op   = 0x18
+   rfe_op= 0x10, eret_op   = 0x18,
+   wait_op   = 0x20
 };
 
 /*
@@ -567,6 +568,24 @@ struct b_format {  /* BREAK and SYSCALL */
;)))
 };
 
+struct c0_format { /* WAIT, TLB?? */
+   BITFIELD_FIELD(unsigned int opcode : 6,
+   BITFIELD_FIELD(unsigned int co : 1,
+   BITFIELD_FIELD(unsigned int code : 19,
+   BITFIELD_FIELD(unsigned int func : 6,
+   ;
+};
+
+struct c0m_format {/* MTC0, MFC0, ... */
+   BITFIELD_FIELD(unsigned int opcode : 6,
+   BITFIELD_FIELD(unsigned int func : 5,
+   BITFIELD_FIELD(unsigned int rt : 5,
+   BITFIELD_FIELD(unsigned int rd : 5,
+   BITFIELD_FIELD(unsigned int code : 8,
+   BITFIELD_FIELD(unsigned int sel : 3,
+   ;))
+};
+
 struct ps_format { /* MIPS-3D / paired single format */
BITFIELD_FIELD(unsigned int opcode : 6,
BITFIELD_FIELD(unsigned int rs : 5,
@@ -857,6 +876,8 @@ union mips_instruction {
struct f_format f_format;
struct ma_format ma_format;
struct b_format b_format;
+   struct c0_format c0_format;
+   struct c0m_format c0m_format;
struct ps_format ps_format;
struct v_format v_format;
struct fb_format fb_format;
-- 
1.7.11.7

--
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 11/31] MIPS: Rearrange branch.c so it can be used by kvm code.

[David Daney]

From: David Daney 

Introduce __compute_return_epc_for_insn0() entry point.

Signed-off-by: David Daney 
---
 arch/mips/include/asm/branch.h |  7 +
 arch/mips/kernel/branch.c  | 63 +++---
 2 files changed, 54 insertions(+), 16 deletions(-)

diff --git a/arch/mips/include/asm/branch.h b/arch/mips/include/asm/branch.h
index e28a3e0..b3de685 100644
--- a/arch/mips/include/asm/branch.h
+++ b/arch/mips/include/asm/branch.h
@@ -37,6 +37,13 @@ static inline unsigned long exception_epc(struct pt_regs 
*regs)
 
 #define BRANCH_LIKELY_TAKEN 0x0001
 
+extern int __compute_return_epc(struct pt_regs *regs);
+extern int __compute_return_epc_for_insn(struct pt_regs *regs,
+union mips_instruction insn);
+extern int __compute_return_epc_for_insn0(struct pt_regs *regs,
+ union mips_instruction insn,
+ unsigned int (*get_fcr31)(void));
+
 static inline int compute_return_epc(struct pt_regs *regs)
 {
if (get_isa16_mode(regs->cp0_epc)) {
diff --git a/arch/mips/kernel/branch.c b/arch/mips/kernel/branch.c
index 46c2ad0..e47145b 100644
--- a/arch/mips/kernel/branch.c
+++ b/arch/mips/kernel/branch.c
@@ -195,17 +195,18 @@ int __MIPS16e_compute_return_epc(struct pt_regs *regs)
 }
 
 /**
- * __compute_return_epc_for_insn - Computes the return address and do emulate
+ * __compute_return_epc_for_insn0 - Computes the return address and do emulate
  * branch simulation, if required.
  *
  * @regs:  Pointer to pt_regs
  * @insn:  branch instruction to decode
- * @returns:   -EFAULT on error and forces SIGBUS, and on success
+ * @returns:   -EFAULT on error, and on success
  * returns 0 or BRANCH_LIKELY_TAKEN as appropriate after
  * evaluating the branch.
  */
-int __compute_return_epc_for_insn(struct pt_regs *regs,
-  union mips_instruction insn)
+int __compute_return_epc_for_insn0(struct pt_regs *regs,
+  union mips_instruction insn,
+  unsigned int (*get_fcr31)(void))
 {
unsigned int bit, fcr31, dspcontrol;
long epc = regs->cp0_epc;
@@ -281,7 +282,7 @@ int __compute_return_epc_for_insn(struct pt_regs *regs,
 
case bposge32_op:
if (!cpu_has_dsp)
-   goto sigill;
+   return -EFAULT;
 
dspcontrol = rddsp(0x01);
 
@@ -364,13 +365,7 @@ int __compute_return_epc_for_insn(struct pt_regs *regs,
 * And now the FPA/cp1 branch instructions.
 */
case cop1_op:
-   preempt_disable();
-   if (is_fpu_owner())
-   asm volatile("cfc1\t%0,$31" : "=r" (fcr31));
-   else
-   fcr31 = current->thread.fpu.fcr31;
-   preempt_enable();
-
+   fcr31 = get_fcr31();
bit = (insn.i_format.rt >> 2);
bit += (bit != 0);
bit += 23;
@@ -434,11 +429,47 @@ int __compute_return_epc_for_insn(struct pt_regs *regs,
}
 
return ret;
+}
+EXPORT_SYMBOL_GPL(__compute_return_epc_for_insn0);
 
-sigill:
-   printk("%s: DSP branch but not DSP ASE - sending SIGBUS.\n", 
current->comm);
-   force_sig(SIGBUS, current);
-   return -EFAULT;
+static unsigned int __get_fcr31(void)
+{
+   unsigned int fcr31;
+
+   preempt_disable();
+   if (is_fpu_owner())
+   asm volatile(
+   ".set push\n"
+   "\t.set mips1\n"
+   "\tcfc1\t%0,$31\n"
+   "\t.set pop" : "=r" (fcr31));
+   else
+   fcr31 = current->thread.fpu.fcr31;
+   preempt_enable();
+   return fcr31;
+}
+
+/**
+ * __compute_return_epc_for_insn - Computes the return address and do emulate
+ * branch simulation, if required.
+ *
+ * @regs:  Pointer to pt_regs
+ * @insn:  branch instruction to decode
+ * @returns:   -EFAULT on error and forces SIGBUS, and on success
+ * returns 0 or BRANCH_LIKELY_TAKEN as appropriate after
+ * evaluating the branch.
+ */
+int __compute_return_epc_for_insn(struct pt_regs *regs,
+  union mips_instruction insn)
+{
+   int r =  __compute_return_epc_for_insn0(regs, insn, __get_fcr31);
+
+   if (r < 0) {
+   printk("%s: DSP branch but not DSP ASE - sending SIGBUS.\n", 
current->comm);
+   force_sig(SIGBUS, current);
+   }
+
+   return r;
 }
 EXPORT_SYMBOL_GPL(__compute_return_epc_for_insn);
 
-- 
1.7.11.7

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

[PATCH 01/31] MIPS: Move allocate_kscratch to cpu-probe.c and make it public.

[David Daney]

From: David Daney 

Signed-off-by: David Daney 
---
 arch/mips/include/asm/mipsregs.h |  2 ++
 arch/mips/kernel/cpu-probe.c | 29 +
 arch/mips/mm/tlbex.c | 20 +---
 3 files changed, 32 insertions(+), 19 deletions(-)

diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index 87e6207..6e0da5aa 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -1806,6 +1806,8 @@ __BUILD_SET_C0(brcm_cmt_ctrl)
 __BUILD_SET_C0(brcm_config)
 __BUILD_SET_C0(brcm_mode)
 
+int allocate_kscratch(void);
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_MIPSREGS_H */
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index c6568bf..ee1014e 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1064,3 +1064,32 @@ __cpuinit void cpu_report(void)
if (c->options & MIPS_CPU_FPU)
printk(KERN_INFO "FPU revision is: %08x\n", c->fpu_id);
 }
+
+static DEFINE_SPINLOCK(kscratch_used_lock);
+
+static unsigned int kscratch_used_mask;
+
+int allocate_kscratch(void)
+{
+   int r;
+   unsigned int a;
+
+   spin_lock(&kscratch_used_lock);
+
+   a = cpu_data[0].kscratch_mask & ~kscratch_used_mask;
+
+   r = ffs(a);
+
+   if (r == 0) {
+   r = -1;
+   goto out;
+   }
+
+   r--; /* make it zero based */
+
+   kscratch_used_mask |= (1 << r);
+out:
+   spin_unlock(&kscratch_used_lock);
+
+   return r;
+}
diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
index ce9818e..001b87c 100644
--- a/arch/mips/mm/tlbex.c
+++ b/arch/mips/mm/tlbex.c
@@ -30,6 +30,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -307,25 +308,6 @@ static int check_for_high_segbits __cpuinitdata;
 
 static int check_for_high_segbits __cpuinitdata;
 
-static unsigned int kscratch_used_mask __cpuinitdata;
-
-static int __cpuinit allocate_kscratch(void)
-{
-   int r;
-   unsigned int a = cpu_data[0].kscratch_mask & ~kscratch_used_mask;
-
-   r = ffs(a);
-
-   if (r == 0)
-   return -1;
-
-   r--; /* make it zero based */
-
-   kscratch_used_mask |= (1 << r);
-
-   return r;
-}
-
 static int scratch_reg __cpuinitdata;
 static int pgd_reg __cpuinitdata;
 enum vmalloc64_mode {not_refill, refill_scratch, refill_noscratch};
-- 
1.7.11.7

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

Re: [GIT PULL] Power management and ACPI fixes for v3.10-rc5

[Tony Luck]

On Fri, Jun 7, 2013 at 3:23 PM, Tony Luck  wrote:
> So please don't pull.

Bother. I see I was a few hours late finding this, and commit 9f29ab11ddb
is already in Linus' tree.

That's what happens when I get busy and skip a couple of days testing
linux-next :-(

So my problem comes from
arch/ia64/hp/common/sba_iommu.c

where the code in sba_init() says:

acpi_bus_register_driver(&acpi_sba_ioc_driver);
if (!ioc_list) {

but because of this change we never managed to call ioc_init()
so ioc_list doesn't get set up, and we die.
Before this commit, the call chain looked like this:

 [] ioc_init+0x40/0xd00
 [] acpi_sba_ioc_add+0x190/0x1c0
 [] acpi_device_probe+0xa0/0x280
 [] really_probe+0xe0/0x520
 [] driver_probe_device+0x30/0x60
 [] __driver_attach+0x110/0x160
 [] bus_for_each_dev+0x110/0x180
 [] driver_attach+0x40/0x60
 [] bus_add_driver+0x230/0x580
 [] driver_register+0xf0/0x400
 [] acpi_bus_register_driver+0x50/0x80
 [] sba_init+0x30/0x2d0

Is my problem that this driver has (or attaches) a "scan handler"
where it shouldn't ... and I just need to stop it doing that?

-Tony
--
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 v3 07/27] iommu, irq: Allocate irq_desc for dmar_msi with local node

[Yinghai Lu]

iommu irq's irq_desc should be on local node ram.

Fix the return value checking problem.

create_irq() will return -1 when fail to allocate.
create_irq_nr() will return 0 when fail to allocate.

here only check !irq, so need to change it to use create_irq_nr instead.

Signed-off-by: Yinghai Lu 
Cc: Joerg Roedel 
Cc: Donald Dutile 
Acked-by: Donald Dutile 
---
 drivers/iommu/dmar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index a7967ce..c09e60d 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1273,7 +1273,7 @@ int dmar_set_interrupt(struct intel_iommu *iommu)
if (iommu->irq)
return 0;
 
-   irq = create_irq();
+   irq = create_irq_nr(0, iommu->node);
if (!irq) {
pr_err("IOMMU: no free vectors\n");
return -EINVAL;
-- 
1.8.1.4

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

[PATCH v3 10/27] genirq: Split __irq_reserve_irqs from irq_alloc_descs

[Yinghai Lu]

irq_alloc_descs and irq_reserve_irqs are almost the same.
Separate code out to __irq_reserved_irqs, and other two reuse
__irq_reserve_irqs.

We will use __irq_reserve_irqs for coming ioapic hotplug support.

Signed-off-by: Yinghai Lu 
Cc: Alexander Gordeev 
---
 include/linux/irq.h  |  1 +
 kernel/irq/irqdesc.c | 54 ++--
 2 files changed, 32 insertions(+), 23 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index bc4e066..4e0fcbb 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -600,6 +600,7 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned 
int cnt, int node,
 
 void irq_free_descs(unsigned int irq, unsigned int cnt);
 int irq_reserve_irqs(unsigned int from, unsigned int cnt);
+int __irq_reserve_irqs(int irq, unsigned int from, unsigned int cnt);
 
 static inline void irq_free_desc(unsigned int irq)
 {
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 192a302..3b9fb92 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -340,18 +340,15 @@ void irq_free_descs(unsigned int from, unsigned int cnt)
 EXPORT_SYMBOL_GPL(irq_free_descs);
 
 /**
- * irq_alloc_descs - allocate and initialize a range of irq descriptors
- * @irq:   Allocate for specific irq number if irq >= 0
+ * __irq_reserve_descs - reserve and initialize a range of irq descriptors
+ * @irq:   Reserve for specific irq number if irq >= 0
  * @from:  Start the search from this irq number
- * @cnt:   Number of consecutive irqs to allocate.
- * @node:  Preferred node on which the irq descriptor should be allocated
- * @owner: Owning module (can be NULL)
+ * @cnt:   Number of consecutive irqs to reserve.
  *
  * Returns the first irq number or error code
  */
 int __ref
-__irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
- struct module *owner)
+__irq_reserve_irqs(int irq, unsigned int from, unsigned int cnt)
 {
int start, ret;
 
@@ -369,7 +366,7 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned int 
cnt, int node,
start = bitmap_find_next_zero_area(allocated_irqs, IRQ_BITMAP_BITS,
   from, cnt, 0);
ret = -EEXIST;
-   if (irq >=0 && start != irq)
+   if (irq >= 0 && start != irq)
goto err;
 
if (start + cnt > nr_irqs) {
@@ -380,12 +377,36 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned 
int cnt, int node,
 
bitmap_set(allocated_irqs, start, cnt);
mutex_unlock(&sparse_irq_lock);
-   return alloc_descs(start, cnt, node, owner);
+   return start;
 
 err:
mutex_unlock(&sparse_irq_lock);
return ret;
 }
+
+/**
+ * irq_alloc_descs - allocate and initialize a range of irq descriptors
+ * @irq:   Allocate for specific irq number if irq >= 0
+ * @from:  Start the search from this irq number
+ * @cnt:   Number of consecutive irqs to allocate.
+ * @node:  Preferred node on which the irq descriptor should be allocated
+ * @owner: Owning module (can be NULL)
+ *
+ * Returns the first irq number or error code
+ */
+int __ref
+__irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
+ struct module *owner)
+{
+   int start;
+
+   start = __irq_reserve_irqs(irq, from, cnt);
+
+   if (start < 0)
+   return start;
+
+   return alloc_descs(start, cnt, node, owner);
+}
 EXPORT_SYMBOL_GPL(__irq_alloc_descs);
 
 /**
@@ -397,20 +418,7 @@ EXPORT_SYMBOL_GPL(__irq_alloc_descs);
  */
 int irq_reserve_irqs(unsigned int from, unsigned int cnt)
 {
-   unsigned int start;
-   int ret = 0;
-
-   if (!cnt || (from + cnt) > nr_irqs)
-   return -EINVAL;
-
-   mutex_lock(&sparse_irq_lock);
-   start = bitmap_find_next_zero_area(allocated_irqs, nr_irqs, from, cnt, 
0);
-   if (start == from)
-   bitmap_set(allocated_irqs, start, cnt);
-   else
-   ret = -EEXIST;
-   mutex_unlock(&sparse_irq_lock);
-   return ret;
+   return __irq_reserve_irqs(from, from, cnt);
 }
 
 /**
-- 
1.8.1.4

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