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

[Josh Triplett]

On Mon, Nov 10, 2014 at 06:17:16PM +1100, Stephen Rothwell wrote:
> Hi Josh,
> 
> After merging the tiny tree, today's linux-next build (powerpc64 allnoconfig)
> failed like this:
> 
> arch/powerpc/kernel/built-in.o: In function `sys_call_table':
> (.rodata+0xd58): undefined reference to `.compat_sys_adjtimex'
> arch/powerpc/kernel/built-in.o: In function `sys_call_table':
> (.rodata+0x1b48): undefined reference to `.compat_sys_clock_adjtime'
> 
> Caused by commit be1e48a8e48f ("kernel: time: Compile out NTP support").

Good catch, thanks.  Not clear why that build failure didn't show up on
x86.

Looks like the two compat syscalls need cond_syscall lines as well.
I'll add those to the patch.

- Josh Triplett
--
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: Early test: hangs in mm/compact.c w. Linus's 12d7aacab56e9ef185c

[Vlastimil Babka]

On 11/10/2014 07:07 AM, Joonsoo Kim wrote:

On Sat, Nov 08, 2014 at 11:18:37PM +0100, Vlastimil Babka wrote:

On 11/08/2014 02:11 PM, P. Christeas wrote:

Hi,

I think I finally found the cause by staring into the code... CCing
people from all 4 separate threads I know about this issue.
The problem with finding the cause was that the first report I got from
Markus was about isolate_freepages_block() overhead, and later Norbert
reported that reverting a patch for isolate_freepages* helped. But the
problem seems to be that although the loop in isolate_migratepages exits
because the scanners almost meet (they are within same pageblock), they
don't truly meet, therefore compact_finished() decides to continue, but
isolate_migratepages() exits immediately... boom! But indeed e14c720efdd7
made this situation possible, as free scaner pfn can now point to a
middle of pageblock.


Indeed.



So I hope the attached patch will fix the soft-lockup issues in
compact_zone. Please apply on 3.18-rc3 or later without any other reverts,
and test. It probably won't help Markus and his isolate_freepages_block()
overhead though...


Yes, I found this bug too, but, it can't explain
isolate_freepages_block() overhead. Anyway, I can't find another bug
related to isolate_freepages_block(). :/


Thanks for checking.


Thanks,
Vlastimil

--8<--
>From fbf8eb0bcd2897090312e23da6a31bad9cc6b337 Mon Sep 17 00:00:00 2001
From: Vlastimil Babka 
Date: Sat, 8 Nov 2014 22:20:43 +0100
Subject: [PATCH] mm, compaction: prevent endless loop in migrate scanner

---
  mm/compaction.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index ec74cf0..1b7a1be 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1029,8 +1029,12 @@ static isolate_migrate_t isolate_migratepages(struct 
zone *zone,
}

acct_isolated(zone, cc);
-   /* Record where migration scanner will be restarted */
-   cc->migrate_pfn = low_pfn;
+   /*
+* Record where migration scanner will be restarted. If we end up in
+* the same pageblock as the free scanner, make the scanners fully
+* meet so that compact_finished() terminates compaction.
+*/
+   cc->migrate_pfn = (end_pfn <= cc->free_pfn) ? low_pfn : cc->free_pfn;

return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
  }


IMHO, proper fix is not to change this logic, but, to change decision
logic in compact_finished() and in compact_zone(). Maybe helper
function would be good for readability.


OK but I would think that to fix 3.18 ASAP and not introduce more 
regressions, go with the patch above first, as it is the minimal fix and 
people already test it. Then we can implement your suggestion later as a 
cleanup for 3.19?


Vlastimil


Thanks.



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

crypto: zeroization of sensitive data in af_alg

[Stephan Mueller]

Hi Herbert,

while working on the AF_ALG interface, I saw no active zeroizations of memory 
that may hold sensitive data that is maintained outside the kernel crypto API 
cipher handles. I think the following memory segments fall under that 
category:

* message digest

* IV

* plaintext / ciphertext handed in by consumer

* ciphertext / plaintext that is send back to the consumer

May I ask whether such zeroizations are present? At least I did not find it. 
If we conclude that there is a need for adding such zeroizations, I checked 
the code for the appropriate locations:

I think I found the location for the first one: hash_sock_destruct that should 
be enhanced with a memset(0) of ctx->result. I have a patch ready which is 
tested and works.

For the IV, I think I found the spot as well: skcipher_sock_destruct. This 
function should be enhanced with a memset(0) of ctx->iv. Again, I have a patch 
ready which is tested and works.

However, I am failing to find the right spot to add a zeroization for the 
latter one, i.e. the code that handles the pages send in by the user or the 
pages that are returned by the crypto API. Initially I thought 
skcipher_pull_sgl is a good spot for the symmetric ciphers as it evicts the 
used pages out of the scope of the kernel crypto API. I added a 
clear_page(sg_page(sg+1)) as well as memset(sg_page(sg+1), 0, plen) right 
before the put_page call. All that I got in return was a BUG() from the memory 
management layer.

Then I tried the same in af_alg_free_sg() as this function is used by 
algif_hash.c -- with the same result.

That makes me wonder: where should such a zeroization call be added?

Thanks

-- 
Ciao
Stephan
--
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 01/11] crypto: Documentation - crypto API high level spec

[Stephan Mueller]

Am Mittwoch, 5. November 2014, 18:15:12 schrieb Tadeusz Struk:

Hi Tadeusz,

> Hi,
> 
> On 11/02/2014 12:35 PM, Stephan Mueller wrote:
> > +   * type:
> > +   - blkcipher for symmetric block ciphers
> 
> blkcipher for synchronous block ciphers
> 
> > +   - ablkcipher for asymmetric block ciphers
> 
> ablkcipher for asynchronous block ciphers
> 
> > +   - cipher for single block ciphers that may be used with an
> > + additional template
> > +   - shash for symmetric message digest
> 
> shash for synchronous message digest
> 
> > +   - ahash for asymmetric message digest
> 
> ahash for asynchronous message digest
> 
> T.

Thanks a lot for this hint: I do not know how often I said "symmetric" or 
"asymmetric" when in fact I meant synchronous and asynchronous

Maybe I spent too much time in the crypto arena ;-)

-- 
Ciao
Stephan
--
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] n_tty: Add memory barrier to fix race condition in receive path

[Christian Riesch]

On Thu, Nov 6, 2014 at 9:56 PM, Greg Kroah-Hartman
 wrote:
> On Thu, Nov 06, 2014 at 08:49:01PM +, Måns Rullgård wrote:
>> Greg Kroah-Hartman  writes:
>>
>> > On Thu, Nov 06, 2014 at 12:39:59PM +0100, Christian Riesch wrote:
>> >> The current implementation of put_tty_queue() causes a race condition
>> >> when re-arranged by the compiler.
>> >>
>> >> On my build with gcc 4.8.3, cross-compiling for ARM, the line
>> >>
>> >>*read_buf_addr(ldata, ldata->read_head++) = c;
>> >>
>> >> was re-arranged by the compiler to something like
>> >>
>> >>x = ldata->read_head
>> >>ldata->read_head++
>> >>*read_buf_addr(ldata, x) = c;
>> >>
>> >> which causes a race condition. Invalid data is read if data is read
>> >> before it is actually written to the read buffer.
>> >
>> > Really?  A compiler can rearange things like that and expect things to
>> > actually work?  How is that valid?
>>
>> This is actually required by the C spec.  There is a sequence point
>> before a function call, after the arguments have been evaluated.  Thus
>> all side-effects, such as the post-increment, must be complete before
>> the function is called, just like in the example.
>>
>> There is no "re-arranging" here.  The code is simply wrong.
>
> Ah, ok, time to dig out the C spec...
>
> Anyway, because of this, no need for the wmb() calls, just rearrange the
> logic and all should be good, right?  Christian, can you test that
> instead?

I ran a test with the patch that I posted in my first email for the
last 4 days. No communication errors occurred so the patch actually
fixes my problem. I will run another test as suggested by Greg, just
with rearranging the logic.
Best regards, Christian
--
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: [f2fs-dev] [PATCH] f2fs: implement -o dirsync

[Changman Lee]

On Sun, Nov 09, 2014 at 10:24:22PM -0800, Jaegeuk Kim wrote:
> If a mount option has dirsync, we should call checkpoint for all the directory
> operations.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/namei.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index 6312dd2..db3ee09 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -138,6 +138,9 @@ static int f2fs_create(struct inode *dir, struct dentry 
> *dentry, umode_t mode,
>   stat_inc_inline_inode(inode);
>   d_instantiate(dentry, inode);
>   unlock_new_inode(inode);
> +
> + if (IS_DIRSYNC(dir))
> + f2fs_sync_fs(sbi->sb, 1);
>   return 0;
>  out:
>   handle_failed_inode(inode);
> @@ -164,6 +167,9 @@ static int f2fs_link(struct dentry *old_dentry, struct 
> inode *dir,
>   f2fs_unlock_op(sbi);
>  
>   d_instantiate(dentry, inode);
> +
> + if (IS_DIRSYNC(dir))
> + f2fs_sync_fs(sbi->sb, 1);
>   return 0;
>  out:
>   clear_inode_flag(F2FS_I(inode), FI_INC_LINK);
> @@ -233,6 +239,9 @@ static int f2fs_unlink(struct inode *dir, struct dentry 
> *dentry)
>   f2fs_delete_entry(de, page, dir, inode);
>   f2fs_unlock_op(sbi);
>  
> + if (IS_DIRSYNC(dir))
> + f2fs_sync_fs(sbi->sb, 1);
> +
>   /* In order to evict this inode, we set it dirty */
>   mark_inode_dirty(inode);

Let's move it below mark_inode_dirty.
After sync, it's unnecessary inserting inode into dirty_list.


>  fail:
> @@ -268,6 +277,9 @@ static int f2fs_symlink(struct inode *dir, struct dentry 
> *dentry,
>  
>   d_instantiate(dentry, inode);
>   unlock_new_inode(inode);
> +
> + if (IS_DIRSYNC(dir))
> + f2fs_sync_fs(sbi->sb, 1);
>   return err;
>  out:
>   handle_failed_inode(inode);
> @@ -304,6 +316,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry 
> *dentry, umode_t mode)
>   d_instantiate(dentry, inode);
>   unlock_new_inode(inode);
>  
> + if (IS_DIRSYNC(dir))
> + f2fs_sync_fs(sbi->sb, 1);
>   return 0;
>  
>  out_fail:
> @@ -346,8 +360,12 @@ static int f2fs_mknod(struct inode *dir, struct dentry 
> *dentry,
>   f2fs_unlock_op(sbi);
>  
>   alloc_nid_done(sbi, inode->i_ino);
> +
>   d_instantiate(dentry, inode);
>   unlock_new_inode(inode);
> +
> + if (IS_DIRSYNC(dir))
> + f2fs_sync_fs(sbi->sb, 1);
>   return 0;
>  out:
>   handle_failed_inode(inode);
> @@ -461,6 +479,9 @@ static int f2fs_rename(struct inode *old_dir, struct 
> dentry *old_dentry,
>   }
>  
>   f2fs_unlock_op(sbi);
> +
> + if (IS_DIRSYNC(old_dir) || IS_DIRSYNC(new_dir))
> + f2fs_sync_fs(sbi->sb, 1);
>   return 0;
>  
>  put_out_dir:
> @@ -600,6 +621,9 @@ static int f2fs_cross_rename(struct inode *old_dir, 
> struct dentry *old_dentry,
>   update_inode_page(new_dir);
>  
>   f2fs_unlock_op(sbi);
> +
> + if (IS_DIRSYNC(old_dir) || IS_DIRSYNC(new_dir))
> + f2fs_sync_fs(sbi->sb, 1);
>   return 0;
>  out_undo:
>   /* Still we may fail to recover name info of f2fs_inode here */
> -- 
> 2.1.1
> 
> 
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mfd: qcom-spmi-pmic: Add support for more chips versions

[Ivan T. Ivanov]

Hi Gilad,

On Fri, 2014-11-07 at 17:08 -0700, Gilad Avidov wrote:
> On 11/6/2014 12:54 AM, Ivan T. Ivanov wrote:
> > On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote:
> > > On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov  
> > > wrote:
> > > > On Wed, 2014-11-05 at 10:11 -0800, Bjorn Andersson wrote:
> > > > > On Tue, Nov 4, 2014 at 5:33 AM, Ivan T. Ivanov 
> > > > > wrote:
> > > > > [..]
> > > > > > @@ -28,11 +144,27 @@ static int pmic_spmi_probe(struct spmi_device
> > > > > > *sdev)
> > > > > >   {
> > > > > >  struct device_node *root = sdev->dev.of_node;
> > > > > >  struct regmap *regmap;
> > > > > > +   struct property *prop;
> > > > > > +   int major, minor, ret;
> > > > > > +   char *name, compatible[32];
> > > > > > 
> > > > > >  regmap = devm_regmap_init_spmi_ext(sdev,
> > > > > > &spmi_regmap_config);
> Hi Ivan, I have a general question about this driver/layer.
> Since the driver is using regmap, why does it need to be
> qcom-*spmi*-pmic ? could we drop the spmi part?
> regmap's point is abstraction of  the bus technology, and indeed some
> PMICs use i2c.

This is driver for SPMI device, so no. The child device/drivers are
different question, but I don't want to start that discussion again.

Regards,
Ivan
--
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: typo of the comment

[Ingo Molnar]

* john_gong  wrote:

> hi Paolo,
> i find a typo of the comment.
> 
> 
> From 09d5df31f0930e8e3eb10ad60a3debc53d6ce992 Mon Sep 17 00:00:00 2001
> From: john_gong 
> Date: Fri, 7 Nov 2014 07:32:17 +0800
> Subject: [PATCH] modify a typo of the comment
> 
> Signed-off-by: john_gong 
> ---
>  arch/x86/kvm/x86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index ef432f8..42bb2c8 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -214,7 +214,7 @@ void kvm_define_shared_msr(unsigned slot, u32 msr)
>  if (slot >= shared_msrs_global.nr)
>  shared_msrs_global.nr = slot + 1;
>  shared_msrs_global.msrs[slot] = msr;
> -/* we need ensured the shared_msr_global have been updated */
> +/* we need ensured the shared_msrs_global have been updated */
>  smp_wmb();

That's not the only typo in that sentence though.

Thanks,

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

Re: [PATCH 1/3] perf tools: Allow vmlinux to fallback to kallsyms on NO_LIBELF=1

[Namhyung Kim]

Hi David,

On Fri, 07 Nov 2014 08:21:16 -0700, David Ahern wrote:
> On 11/6/14, 10:20 PM, Namhyung Kim wrote:
>> It worked w/o libelf, but recent change to use vmlinux for kernel
>> symbols break it.
>
> Do you know the recent change (commit id) that broke it?

Nope.  I tried to find it but failed - older versions seems also have
the problem and some of them could not run perf record.  Anyway it looks
like depending some external condition and broken for a while. :(

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

Re: [f2fs-dev] [PATCH 4/5] f2fs: write node pages if checkpoint is not doing

[Changman Lee]

On Sat, Nov 08, 2014 at 11:36:08PM -0800, Jaegeuk Kim wrote:
> It needs to write node pages if checkpoint is not doing in order to avoid
> memory pressure.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/node.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 4ea2c47..6f514fb 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1314,10 +1314,12 @@ static int f2fs_write_node_page(struct page *page,
>   return 0;
>   }
>  
> - if (wbc->for_reclaim)
> - goto redirty_out;
> -
> - down_read(&sbi->node_write);
> + if (wbc->for_reclaim) {
> + if (!down_read_trylock(&sbi->node_write))
> + goto redirty_out;

Previously, we skipped write_page for reclaim path, but from now on, we
will write out node page to reclaim memory at any time except checkpoint.
We should remember it may occur to break merging bio.
Got it.

Reviewed-by: Changman Lee 

> + } else {
> + down_read(&sbi->node_write);
> + }
>   set_page_writeback(page);
>   write_node_page(sbi, page, &fio, nid, ni.blk_addr, &new_addr);
>   set_node_addr(sbi, &ni, new_addr, is_fsync_dnode(page));
> -- 
> 2.1.1
> 
> 
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 00/24] AMDKFD Kernel Driver

[Oded Gabbay]

On 11/10/2014 04:34 AM, Dave Airlie wrote:

On 9 November 2014 04:37, Oded Gabbay  wrote:

Hi,
Here is the v5 patch set of amdkfd.

This version is released several days ahead of the release of AMD's HSA Runtime
library as Open Source. Coupled with the modification that Thomas Stellard
did for the r600 LLVM back-end, AMD will be effectively releasing a _complete_
userspace Open Source stack/solution for running HSA applications using
kernels written in OpenCL C99 on top of amdkfd.



Daniel pointed out too me a major problem with the approach of having
two drivers
touching on hw at all, they are facing similiar issues with their virt stuff,

How does amdkfd interfact with runtime pm on the radeon driver? I'd expect
some calls to the runtime get/put functions in some places.

Dave.


Hi Dave,
Per Jerome's request from the first time he saw the driver, we removed all the 
"register bashing" code from amdkfd and moved them to the interface file between 
amdkfd and radeon, which is part of the radeon driver.
See "[PATCH v5 05/24] drm/radeon: Add radeon <--> amdkfd interface" for the 
implementation of that interface file.


amdkfd communicates with the H/W either through that file, or through packets 
submitted via the HIQ (a single kernel queue that is created/destroyed and 
exclusively used by amdkfd). By using the HIQ to submit the runlist to the GPU, 
we actually don't call to most of the interface file's functions. Those 
functions are mostly used in bring-up of new H/W with the scheduling mode of: 
"No CP scheduling"


Regarding power management, we have two hooks from the radeon driver, that call 
our driver (if it exists. if it doesn't exists, those call simply return without 
doing anything). I think this is better approach than amdkfd interface directly 
with the runtime pm, in order to prevent races between us and radeon. Do you agree ?


That code is also in Patch 5/24, at cik.c:

@@ -8471,6 +8476,10 @@ static int cik_startup(struct radeon_device *rdev)
if (r)
return r;

+   r = radeon_kfd_resume(rdev);
+   if (r)
+   return r;
+
return 0;
 }

@@ -8519,6 +8528,7 @@ int cik_resume(struct radeon_device *rdev)
  */
 int cik_suspend(struct radeon_device *rdev)
 {
+   radeon_kfd_suspend(rdev);
radeon_pm_suspend(rdev);
dce6_audio_fini(rdev);
radeon_vm_manager_fini(rdev);

- Oded

--
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/4] inet: Add skb_copy_datagram_iter

[David Miller]

From: Al Viro 
Date: Mon, 10 Nov 2014 06:58:17 +

> On Mon, Nov 10, 2014 at 12:20:20AM -0500, David Miller wrote:
>> From: Al Viro 
>> Date: Sun, 9 Nov 2014 21:19:08 +
>> 
>> > 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?
>> 
>> sparc64 will just fault no matter what kind of task it is.
>> 
>> It is impossible for a user task to generate a reference to
>> a kernel virtual address, as kernel and user accesses each
>> go via a separate address space identifier.
> 
> Sure, but why do we have access_ok() there at all?  I.e. why not just have
> it constant 1?

Since access_ok() is in fact constant 1 on sparc64, where we use it,
does it really matter?
--
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 4/5] power: rt5033_charger: Add RT5033 charger device driver

[Beomho Seo]

This patch add device driver of Richtek RT5033 PMIC. The driver support
switching charger. rt5033 charger provide three charging mode.
Three charging mode are pre charge mode, fast cahrge mode and constant voltage
mode. They are have vary charge rate, charge parameters. The charge parameters
can be controlled by i2c interface.

Cc: Sebastian Reichel 
Cc: Dmitry Eremin-Solenikov 
Cc: David Woodhouse 
Signed-off-by: Beomho Seo 
Acked-by: Chanwoo Choi 
---
Changes in v2:
- Fix wrong error message.
- Fix return value at error case. Because  charger->data null, probe function
return zero.
- Use define for set control register.
---
 drivers/power/Kconfig  |8 +
 drivers/power/Makefile |1 +
 drivers/power/rt5033_charger.c |  485 
 3 files changed, 494 insertions(+)
 create mode 100644 drivers/power/rt5033_charger.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index da6981f..629b101 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -405,6 +405,14 @@ config BATTERY_RT5033
  The fuelgauge calculates and determines the battery state of charge
  according to battery open circuit voltage.
 
+config CHARGER_RT5033
+   tristate "RT5033 battery charger support"
+   depends on MFD_RT5033
+   help
+ This adds support for battery charger in Richtek RT5033 PMIC.
+ The device supports pre-charge mode, fast charge mode and
+ constant voltage mode.
+
 source "drivers/power/reset/Kconfig"
 
 endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b83a0c7..bb8cce3 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
 obj-$(CONFIG_CHARGER_BQ24190)  += bq24190_charger.o
 obj-$(CONFIG_CHARGER_BQ24735)  += bq24735-charger.o
 obj-$(CONFIG_POWER_AVS)+= avs/
+obj-$(CONFIG_POWER_RT5033) += rt5033_charger.o
 obj-$(CONFIG_CHARGER_SMB347)   += smb347-charger.o
 obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
diff --git a/drivers/power/rt5033_charger.c b/drivers/power/rt5033_charger.c
new file mode 100644
index 000..f2a7233
--- /dev/null
+++ b/drivers/power/rt5033_charger.c
@@ -0,0 +1,485 @@
+/*
+ * Battery charger driver for RT5033
+ *
+ * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
+ * Beomho Seo 
+ *
+ * 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 bythe Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int rt5033_get_charger_state(struct rt5033_charger *charger)
+{
+   struct regmap *regmap = charger->rt5033->regmap;
+   int state = POWER_SUPPLY_STATUS_UNKNOWN;
+   u32 reg_data;
+
+   if (!regmap)
+   return state;
+
+   regmap_read(regmap, RT5033_REG_CHG_STAT, ®_data);
+
+   switch (reg_data & RT5033_CHG_STAT_MASK) {
+   case RT5033_CHG_STAT_DISCHARGING:
+   state = POWER_SUPPLY_STATUS_DISCHARGING;
+   break;
+   case RT5033_CHG_STAT_CHARGING:
+   state = POWER_SUPPLY_STATUS_CHARGING;
+   break;
+   case RT5033_CHG_STAT_FULL:
+   state = POWER_SUPPLY_STATUS_FULL;
+   break;
+   case RT5033_CHG_STAT_NOT_CHARGING:
+   state = POWER_SUPPLY_STATUS_NOT_CHARGING;
+   break;
+   }
+
+   return state;
+}
+
+static int rt5033_get_charger_type(struct rt5033_charger *charger)
+{
+   struct regmap *regmap = charger->rt5033->regmap;
+   int state = POWER_SUPPLY_CHARGE_TYPE_UNKNOWN;
+   u32 reg_data;
+
+   regmap_read(regmap, RT5033_REG_CHG_STAT, ®_data);
+
+   switch (reg_data & RT5033_CHG_STAT_TYPE_MASK) {
+   case RT5033_CHG_STAT_TYPE_FAST:
+   state = POWER_SUPPLY_CHARGE_TYPE_FAST;
+   break;
+   case RT5033_CHG_STAT_TYPE_PRE:
+   state = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+   break;
+   }
+
+   return state;
+}
+
+static int rt5033_get_charger_current(struct rt5033_charger *charger,
+   enum power_supply_property psp)
+{
+   struct regmap *regmap = charger->rt5033->regmap;
+   unsigned int state, reg_data, data;
+
+   if (psp == POWER_SUPPLY_PROP_CURRENT_MAX)
+   return RT5033_CHG_MAX_CURRENT;
+
+   regmap_read(regmap, RT5033_REG_CHG_CTRL5, ®_data);
+
+   state = (reg_data >> RT5033_CHGCTRL5_ICHG_SHIFT) & 0xf;
+
+   if (state > RT5033_CHG_MAX_CURRENT)
+   state = RT5033_CHG_MAX_CURRENT;
+
+   data = state * 100 + 700;
+
+   return data;
+}
+
+static int rt5033_get_charge_voltage(struct rt5033_charger *charger,
+   enum power_supply_property psp)
+{
+   struct regmap *regmap = charger->rt5033->regmap;
+   unsigned int state, reg_data, data;
+
+

[PATCH v2 0/5] mfd: rt5033: Add Richtek RT5033 drivers

[Beomho Seo]

 This patchset adds driver for Richtek rt5033 chip The chip contains
switching charge mode Li-Ion/Li-Polymer battery charger, fuelgauge, regulators.
This patchset provides common support for accessing the device.
This patchset have been tested base on exynos board.

Changes in v2:
- Remove volatile_reg callback. Because this driver not in use regmap cache.
- Remove unnecessary subnode of_compatible.
- Add definde for set high impedance mode of charger.
- Remove unnecessary device specific code.
- Fix wrong register name.
- Fix wrong error message.
- Fix return vallue at error case.
- Revise binding documentation.

Beomho Seo (5):
  mfd: rt5033: Add Richtek RT5033 driver core.
  regulator: rt5033: Add RT5033 Regulator device driver
  power: rt5033_battery: Add RT5033 Fuel gauge device driver
  power: rt5033_charger: Add RT5033 charger device driver
  Documentation: Add documentation for rt5033 multifunction device

 Documentation/devicetree/bindings/mfd/rt5033.txt   |  108 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/mfd/Kconfig|   11 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/rt5033.c   |  156 +++
 drivers/power/Kconfig  |   16 +
 drivers/power/Makefile |2 +
 drivers/power/rt5033_battery.c |  177 +++
 drivers/power/rt5033_charger.c |  485 
 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/rt5033-regulator.c   |  123 +
 include/linux/mfd/rt5033-private.h |  260 +++
 include/linux/mfd/rt5033.h |   64 +++
 14 files changed, 1413 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rt5033.txt
 create mode 100644 drivers/mfd/rt5033.c
 create mode 100644 drivers/power/rt5033_battery.c
 create mode 100644 drivers/power/rt5033_charger.c
 create mode 100644 drivers/regulator/rt5033-regulator.c
 create mode 100644 include/linux/mfd/rt5033-private.h
 create mode 100644 include/linux/mfd/rt5033.h

-- 
1.7.9.5

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

[PATCH v2 1/5] mfd: rt5033: Add Richtek RT5033 driver core.

[Beomho Seo]

This patch adds a new driver for Richtek RT5033 driver.
RT5033 is a Multifunction device which includes battery charger, fuel gauge,
flash LED current source, LDO and synchronous Buck converter. It is interfaced
to host controller using I2C interface.

Cc: Samuel Ortiz 
Cc: Lee Jones 
Signed-off-by: Beomho Seo 
Acked-by: Chanwoo Choi 
---
Changes in v2
- Remove volatile_reg callback. Because this driver not in use regmap cache.
- Revmoe unnecessary subnode of_compatible.
- Add define for set_high impedance mode of charger.
---

 drivers/mfd/Kconfig|   11 ++
 drivers/mfd/Makefile   |1 +
 drivers/mfd/rt5033.c   |  142 
 include/linux/mfd/rt5033-private.h |  260 
 include/linux/mfd/rt5033.h |   64 +
 5 files changed, 478 insertions(+)
 create mode 100644 drivers/mfd/rt5033.c
 create mode 100644 include/linux/mfd/rt5033-private.h
 create mode 100644 include/linux/mfd/rt5033.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index cbdb109..6800068 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -607,6 +607,17 @@ config MFD_RTSX_PCI
  types of memory cards, such as Memory Stick, Memory Stick Pro,
  Secure Digital and MultiMediaCard.
 
+config MFD_RT5033
+   bool "Richtek RT5033 Power Management IC"
+   depends on I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+ This support for Richtek RT5033 Power Management IC. This includes
+ the I2C driver and the Core APIs. This driver provides common support
+ for accessing the device. The device supports multiple sub-devices
+ like charger, fuel gauge, flash LED, current source, LDO and Buck.
+
 config MFD_RTSX_USB
tristate "Realtek USB card reader"
depends on USB
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8e679d6..94e0f1c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_MFD_STW481X)   += stw481x.o
 obj-$(CONFIG_MFD_IPAQ_MICRO)   += ipaq-micro.o
 obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)  += hi6421-pmic-core.o
+obj-$(CONFIG_MFD_RT5033)   += rt5033.o
 
 intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
new file mode 100644
index 000..8f5aee0
--- /dev/null
+++ b/drivers/mfd/rt5033.c
@@ -0,0 +1,142 @@
+/*
+ * MFD core driver for the Richtek RT5033.
+ *
+ * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
+ * Beomho Seo 
+ *
+ * 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 bythe Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct regmap_irq rt5033_irqs[] = {
+   { .mask = RT5033_PMIC_IRQ_BUCKOCP, },
+   { .mask = RT5033_PMIC_IRQ_BUCKLV, },
+   { .mask = RT5033_PMIC_IRQ_SAFELDOLV, },
+   { .mask = RT5033_PMIC_IRQ_LDOLV, },
+   { .mask = RT5033_PMIC_IRQ_OT, },
+   { .mask = RT5033_PMIC_IRQ_VDDA_UV, },
+};
+
+static const struct regmap_irq_chip rt5033_irq_chip = {
+   .name   = "rt5033",
+   .status_base= RT5033_REG_PMIC_IRQ_STAT,
+   .mask_base  = RT5033_REG_PMIC_IRQ_CTRL,
+   .mask_invert= true,
+   .num_regs   = 1,
+   .irqs   = rt5033_irqs,
+   .num_irqs   = ARRAY_SIZE(rt5033_irqs),
+};
+
+static const struct mfd_cell rt5033_devs[] = {
+   {
+   .name = "rt5033-regulator",
+   }, {
+   .name = "rt5033-charger",
+   .of_compatible = "richtek,rt5033-charger",
+   }, {
+   .name = "rt5033-battery",
+   .of_compatible = "richtek,rt5033-battery",
+   },
+};
+
+static const struct of_device_id rt5033_dt_match[] = {
+   { .compatible = "richtek,rt5033", },
+   { }
+};
+
+static const struct regmap_config rt5033_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .max_register   = RT5033_REG_END,
+};
+
+static int rt5033_i2c_probe(struct i2c_client *i2c,
+   const struct i2c_device_id *id)
+{
+   struct rt5033_dev *rt5033;
+   unsigned int data;
+   int ret = 0;
+
+   rt5033 = devm_kzalloc(&i2c->dev, sizeof(*rt5033), GFP_KERNEL);
+   if (!rt5033)
+   return -ENOMEM;
+
+   i2c_set_clientdata(i2c, rt5033);
+   rt5033->dev = &i2c->dev;
+   rt5033->i2c = i2c;
+   rt5033->irq = i2c->irq;
+   rt5033->wakeup = 1;
+
+   rt5033->regmap = devm_regmap_init_i2c(i2c, &rt5033_regmap_config);
+   if (IS_ERR(rt5033->regmap)) {
+   dev_err(&i2c->dev, "Failed to allocate register map.\n");
+   return PTR_ERR(rt5033->regmap);
+   }
+
+

Re: [PATCH] ALSA: korg1212: cleanup of printk

[Sudip Mukherjee]

hi Takashi,
I have a doubt regarding this korg1212.
snd_korg1212_free_pcm is just making korg1212->pcm as NULL. But are we not 
supposed to release the allocated memory ?
in snd_pcm_new we are allocating memory.

thanks
sudip

--
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 2/5] regulator: rt5033: Add RT5033 Regulator device driver

[Beomho Seo]

This patch add device driver of Richtek RT5033 PMIC.
The driver support multiple regulator like LDO and synchronous Buck.
The integrated synchronous buck converter is designed to provide 0.6 A
application with high efficiency. Two LDOs are integrated. One safe LDO is
for 60mA and the other one LDO is for 150 mA.

Cc: Liam Girdwood 
Cc: Mark Brown 
Signed-off-by: Beomho Seo 
Acked-by: Chanwoo Choi 
---
Changes in v2:
- Remove unnecessary device specific code.
---
 drivers/regulator/Kconfig|8 +++
 drivers/regulator/Makefile   |1 +
 drivers/regulator/rt5033-regulator.c |  123 ++
 3 files changed, 132 insertions(+)
 create mode 100644 drivers/regulator/rt5033-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 55d7b7b..8558e1b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -521,6 +521,14 @@ config REGULATOR_RN5T618
help
  Say y here to support the regulators found on Ricoh RN5T618 PMIC.
 
+config REGULATOR_RT5033
+   tristate "Richtek RT5033 Regulators"
+   depends on MFD_RT5033
+   help
+ This adds support for voltage and current regulators in Richtek
+ RT5033 PMIC. The device supports multiple regulators like
+ current source, LDO and Buck.
+
 config REGULATOR_S2MPA01
tristate "Samsung S2MPA01 voltage regulator"
depends on MFD_SEC_CORE
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 1029ed3..1f28ebf 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
 obj-$(CONFIG_REGULATOR_RC5T583)  += rc5t583-regulator.o
 obj-$(CONFIG_REGULATOR_RK808)   += rk808-regulator.o
 obj-$(CONFIG_REGULATOR_RN5T618) += rn5t618-regulator.o
+obj-$(CONFIG_REGULATOR_RT5033) += rt5033-regulator.o
 obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
 obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
diff --git a/drivers/regulator/rt5033-regulator.c 
b/drivers/regulator/rt5033-regulator.c
new file mode 100644
index 000..782ba2d
--- /dev/null
+++ b/drivers/regulator/rt5033-regulator.c
@@ -0,0 +1,123 @@
+/*
+ * Regulator driver for the Richtek RT5033
+ *
+ * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
+ * Beomho Seo 
+ *
+ * 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 bythe Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct regulator_ops rt5033_safe_ldo_ops = {
+   .is_enabled = regulator_is_enabled_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .list_voltage   = regulator_list_voltage_linear,
+};
+
+static struct regulator_ops rt5033_buck_ops = {
+   .is_enabled = regulator_is_enabled_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .list_voltage   = regulator_list_voltage_linear,
+   .map_voltage= regulator_map_voltage_linear,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+};
+
+static const struct regulator_desc rt5033_supported_regulators[] = {
+   [RT5033_BUCK] = {
+   .name   = "BUCK",
+   .id = RT5033_BUCK,
+   .ops= &rt5033_buck_ops,
+   .type   = REGULATOR_VOLTAGE,
+   .owner  = THIS_MODULE,
+   .n_voltages = RT5033_REGULATOR_BUCK_VOLTAGE_STEP_NUM,
+   .min_uV = RT5033_REGULATOR_BUCK_VOLTAGE_MIN,
+   .uV_step= RT5033_REGULATOR_BUCK_VOLTAGE_STEP,
+   .enable_reg = RT5033_REG_CTRL,
+   .enable_mask= RT5033_CTRL_EN_BUCK_MASK,
+   .vsel_reg   = RT5033_REG_BUCK_CTRL,
+   .vsel_mask  = RT5033_BUCK_CTRL_MASK,
+   },
+   [RT5033_LDO] = {
+   .name   = "LDO",
+   .id = RT5033_LDO,
+   .ops= &rt5033_buck_ops,
+   .type   = REGULATOR_VOLTAGE,
+   .owner  = THIS_MODULE,
+   .n_voltages = RT5033_REGULATOR_LDO_VOLTAGE_STEP_NUM,
+   .min_uV = RT5033_REGULATOR_LDO_VOLTAGE_MIN,
+   .uV_step= RT5033_REGULATOR_LDO_VOLTAGE_STEP,
+   .enable_reg = RT5033_REG_CTRL,
+   .enable_mask= RT5033_CTRL_EN_LDO_MASK,
+   .vsel_reg   = RT5033_REG_LDO_CTRL,
+   .vsel_mask  = RT5033_LDO_CTRL_MASK,
+   },
+   [RT5033_SAFE_LDO] = {
+   .name

[PATCH v2 3/5] power: rt5033_battery: Add RT5033 Fuel gauge device driver

[Beomho Seo]

This patch adds device driver of Richtek PMIC.
The driver support battery fuel gange. Fuel gauge calculates and determines the
battery state of charge(SOC) according to battery open circuit voltage(OCV).
Also, this driver provides battery average voltage, voltage and bettery present
property.

Cc: Sebastian Reichel 
Cc: Dmitry Eremin-Solenikov 
Cc: David Woodhouse 
Signed-off-by: Beomho Seo 
Acked-by: Chanwoo Choi 
---
Changes in v2:
- Remove volatile_reg callback. Because this driver not in use regmap cache.
- Fix wrong register name.
---
 drivers/power/Kconfig  |8 ++
 drivers/power/Makefile |1 +
 drivers/power/rt5033_battery.c |  177 
 3 files changed, 186 insertions(+)
 create mode 100644 drivers/power/rt5033_battery.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 0108c2a..da6981f 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -397,6 +397,14 @@ config BATTERY_GOLDFISH
  Say Y to enable support for the battery and AC power in the
  Goldfish emulator.
 
+config BATTERY_RT5033
+   tristate "RT5033 fuel gauge support"
+   depends on MFD_RT5033
+   help
+ This adds support for battery fuel gauge in Richtek RT5033 PMIC.
+ The fuelgauge calculates and determines the battery state of charge
+ according to battery open circuit voltage.
+
 source "drivers/power/reset/Kconfig"
 
 endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dfa8942..b83a0c7 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_BATTERY_DA9052)  += da9052-battery.o
 obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
 obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
 obj-$(CONFIG_BATTERY_Z2)   += z2_battery.o
+obj-$(CONFIG_BATTERY_RT5033)   += rt5033_battery.o
 obj-$(CONFIG_BATTERY_S3C_ADC)  += s3c_adc_battery.o
 obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
 obj-$(CONFIG_CHARGER_88PM860X) += 88pm860x_charger.o
diff --git a/drivers/power/rt5033_battery.c b/drivers/power/rt5033_battery.c
new file mode 100644
index 000..70af2c3
--- /dev/null
+++ b/drivers/power/rt5033_battery.c
@@ -0,0 +1,177 @@
+/*
+ * Fuel gauge driver for Richtek RT5033
+ *
+ * Copyright (C) 2014 Samsung Electronics, Co., Ltd.
+ * Beomho Seo 
+ *
+ * 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 bythe Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int rt5033_battery_get_capacity(struct i2c_client *client)
+{
+   struct rt5033_battery *battery = i2c_get_clientdata(client);
+   u32 msb;
+
+   regmap_read(battery->regmap, RT5033_FUEL_REG_SOC_H, &msb);
+
+   return msb;
+}
+
+static int rt5033_battery_get_present(struct i2c_client *client)
+{
+   struct rt5033_battery *battery = i2c_get_clientdata(client);
+   u32 val;
+
+   regmap_read(battery->regmap, RT5033_FUEL_REG_CONFIG_L, &val);
+
+   return (val & RT5033_FUEL_BAT_PRESENT) ? true : false;
+}
+
+static int rt5033_battery_get_watt_prop(struct i2c_client *client,
+   enum power_supply_property psp)
+{
+   struct rt5033_battery *battery = i2c_get_clientdata(client);
+   unsigned int regh, regl;
+   int ret;
+   u32 msb, lsb;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+   regh = RT5033_FUEL_REG_VBAT_H;
+   regl = RT5033_FUEL_REG_VBAT_L;
+   break;
+   case POWER_SUPPLY_PROP_VOLTAGE_AVG:
+   regh = RT5033_FUEL_REG_AVG_VOLT_H;
+   regl = RT5033_FUEL_REG_AVG_VOLT_L;
+   break;
+   case POWER_SUPPLY_PROP_VOLTAGE_OCV:
+   regh = RT5033_FUEL_REG_OCV_H;
+   regl = RT5033_FUEL_REG_OCV_L;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   regmap_read(battery->regmap, regh, &msb);
+   regmap_read(battery->regmap, regl, &lsb);
+
+   ret = ((msb << 4) + (lsb >> 4)) * 1250 / 1000;
+
+   return ret;
+}
+
+static int rt5033_battery_get_property(struct power_supply *psy,
+   enum power_supply_property psp,
+   union power_supply_propval *val)
+{
+   struct rt5033_battery *battery = container_of(psy,
+   struct rt5033_battery, psy);
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+   case POWER_SUPPLY_PROP_VOLTAGE_AVG:
+   case POWER_SUPPLY_PROP_VOLTAGE_OCV:
+   val->intval = rt5033_battery_get_watt_prop(battery->client,
+   psp);
+   break;
+   case POWER_SUPPLY_PROP_PRESENT:
+   val->intval = rt5033_battery_get_present(battery->client);
+   break;
+   case POWER_SUPPLY_PROP_CAPACITY:

[PATCH v2 5/5] Documentation: Add documentation for rt5033 multifunction device

[Beomho Seo]

This patch device tree binding documentation for rt5033 multifunction device.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian campbell 
Cc: Kumar Gala 
Signed-off-by: Beomho Seo 
Acked-by: Chanwoo Choi 
---
Changes in v2:
- Revise binding documentation.
---
 Documentation/devicetree/bindings/mfd/rt5033.txt   |  108 
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 2 files changed, 109 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/rt5033.txt

diff --git a/Documentation/devicetree/bindings/mfd/rt5033.txt 
b/Documentation/devicetree/bindings/mfd/rt5033.txt
new file mode 100644
index 000..52a6d33
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rt5033.txt
@@ -0,0 +1,108 @@
+Richtek RT5033 Power management Integrated Circuit
+
+RT5033 is a Multifunction device which includes battery charger, fuel gauge,
+flash LED current source, LDO and synchronous Buck converter for portable
+applications. It is interfaced to host controller using i2c interface.
+
+Required properties:
+- compatible : Must be "richtek,rt5033"
+- reg : Specifies the i2c slave address of general part.
+- interrupts : This i2c devices has an IRQ line connected to the main SoC.
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+Regulators: The regulators of RT5033 have to be instantiated under sub-node
+named "regulators" usinge the following format.
+
+   regulators {
+   regulator-name {
+   regulator-name = LDO/BUCK
+   regulator subnodes called X, Y and Z
+   };
+   };
+   refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+
+Battery charger: There battery charger of RT5033 have to be instantiated under
+sub-node named "charger" using the following format.
+
+Required properties:
+- compatible : Must be "richtek,rt5033-charger".
+- richtek,pre-uamp : Current of pre-charge mode. The pre-charge current levels
+  are 350 mA to 650 mA programmed by I2C per 100 mA.
+- richtek,pre-threshold-uvolt : Voltage of threshold pre-charge mode. Battery
+  voltage is below pre-charge threshold voltage, the charger is in pre-charge
+  mode with pre-charge current. Its levels are 2.3 V  to 3.8 V programmed
+  by I2C per 0.1 V.
+- richtek,fast-uamp : Current of fast-charge mode. The fast-charge current
+  levels are 700 mA to 2000 mA programmed by I2C per 100 mA.
+- richtek,const-uvolt :  Battery regulation voltage of constant voltage mode.
+  This voltage level 3.65 V to 4.4 V bye I2C per 0.025 V.
+- richtek,eoc-uamp : This property is end of charge current. Its level 150 mA
+  to 200 mA.
+
+   charger {
+   compatible = "richtek,rt5033-charger";
+   richtek,pre-uamp = <35>;
+   richtek,pre-threshold-uvolt = <340>;
+   richtek,fast-uamp = <200>;
+   richtek,const-uvolt = <435>;
+   richtek,eoc-uamp = <25>;
+   };
+
+
+Fuelgauge: There fuelgauge of RT5033 to be instantiated node named "fuelgauge"
+using the following format.
+
+Required properties:
+- compatible = Must be "richtek,rt5033-battery".
+
+   i2c_fuel: i2c@1 {
+   compatible = "i2c-gpio";
+   standard i2c-gpio constraints...
+   fuelgauge {
+   compatible = "richtek,rt5033-battery".
+   };
+   };
+
+
+Example:
+
+   rt5033@34 {
+   compatible = "richtek,rt5033";
+   reg = <0x34>;
+   interrupt-parent = <&gpx1>;
+   interrupts = <5 0>;
+
+   regulators {
+   buck_reg: BUCK {
+   regulator-name = "BUCK";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-always-on;
+   };
+   };
+
+   charger {
+   compatible = "richtek,rt5033-charger";
+   richtek,pre-uamp = <35>;
+   richtek,pre-threshold-uvolt = <340>;
+   richtek,fast-uamp = <200>;
+   richtek,const-uvolt = <435>;
+   richtek,eoc-uamp = <25>;
+   };
+
+   };
+
+   i2c_fuel: i2c@10 {
+   compatible = "i2c-gpio";
+   gpios = <&gpm3 1 0
+   &gpm3 0 0>;
+
+   fuel: rt5033-battery@35 {
+   compatible = "richtek,rt5033-battery";
+   interrupt-parent = <&gpx2>;
+   interrupts = <3 0>;
+ 

[PATCH] Input: xpad - update docs to reflect current state

[Daniel Dressler]

The last time this documentation was accurate was
just over 8 years ago. In this time we've added
support for two new generations of Xbox console
controllers and dozens of third-party controllers.

This patch unifies terminology and makes it explicit
which model of controller a sentence refers to.

It also expands certain sections to address the latest
versions of Xbox controllers.

Thus this documentation should now be useful to
end users and not contain out-right untruths.

This is the patch's second revision. Prior versions
of this patch altered the driver's TODO list. That
change has been pulled out of this documentation
update patch.

Signed-off-by: Daniel Dressler 
---
 Documentation/input/xpad.txt | 123 +--
 1 file changed, 83 insertions(+), 40 deletions(-)

diff --git a/Documentation/input/xpad.txt b/Documentation/input/xpad.txt
index 7cc9a43..d1b23f2 100644
--- a/Documentation/input/xpad.txt
+++ b/Documentation/input/xpad.txt
@@ -1,18 +1,22 @@
-xpad - Linux USB driver for X-Box gamepads
+xpad - Linux USB driver for Xbox compatible controllers
 
-This is the very first release of a driver for X-Box gamepads.
-Basically, this was hacked away in just a few hours, so don't expect
-miracles.
+This driver exposes all first-party and third-party Xbox compatible
+controllers. It has a long history and has enjoyed considerable usage
+as Window's xinput library caused most PC games to focus on Xbox
+controller compatibility.
 
-In particular, there is currently NO support for the rumble pack.
-You won't find many ff-aware linux applications anyway.
+Due to backwards compatibility all buttons are reported as digital.
+This only effects Original Xbox controllers. All later controller models
+have only digital face buttons.
+
+Rumble is supported on some models of Xbox 360 controllers but not of
+Original Xbox controllers nor on Xbox One controllers. As of writing
+the Xbox One's rumble protocol has not been reverse engineered but in
+the future could be supported.
 
 
 0. Notes
 
-
-Driver updated for kernel 2.6.17.11. (Based on a patch for 2.6.11.4.)
-
 The number of buttons/axes reported varies based on 3 things:
 - if you are using a known controller
 - if you are using a known dance pad
@@ -20,12 +24,16 @@ The number of buttons/axes reported varies based on 3 
things:
   module configuration for "Map D-PAD to buttons rather than axes for unknown
   pads" (module option dpad_to_buttons)
 
-If you set dpad_to_buttons to 0 and you are using an unknown device (one
-not listed below), the driver will map the directional pad to axes (X/Y),
-if you said N it will map the d-pad to buttons, which is needed for dance
-style games to function correctly.  The default is Y.
+If you set dpad_to_buttons to N and you are using an unknown device
+the driver will map the directional pad to axes (X/Y).
+If you said Y it will map the d-pad to buttons, which is needed for dance
+style games to function correctly. The default is Y.
+
+dpad_to_buttons has no effect for known pads. A erroneous commit message
+claimed dpad_to_buttons could be used to force behavior on known devices.
+This is not true. Both dpad_to_buttons and triggers_to_buttons only affect
+unknown controllers.
 
-dpad_to_buttons has no effect for known pads.
 
 0.1 Normal Controllers
 --
@@ -80,17 +88,29 @@ to the list of supported devices, ensuring that it will 
work out of the
 box in the future.
 
 
-1. USB adapter
+1. USB adapters
 --
+All generations of Xbox controllers speak USB over the wire.
+- Original Xbox controllers use a proprietary connector and require adapters.
+- Wireless Xbox 360 controllers require a 'Xbox 360 Wireless Gaming Receiver
+  for Windows'
+- Wired Xbox 360 controllers use standard USB connectors.
+- Xbox One controllers can be wireless but speak Wi-Fi Direct and are not
+  yet supported.
+- Xbox One controllers can be wired and use standard Micro-USB connectors.
+
 
-Before you can actually use the driver, you need to get yourself an
-adapter cable to connect the X-Box controller to your Linux-Box. You
-can buy these online fairly cheap, or build your own.
+
+1.1 Original Xbox USB adapters
+--
+Using this driver with an Original Xbox controller requires an
+adapter cable to break out the proprietary connector's pins to USB.
+You can buy these online fairly cheap, or build your own.
 
 Such a cable is pretty easy to build. The Controller itself is a USB
 compound device (a hub with three ports for two expansion slots and
 the controller device) with the only difference in a nonstandard connector
-(5 pins vs. 4 on standard USB connector).
+(5 pins vs. 4 on standard USB 1.0 connectors).
 
 You just need to solder a USB connector onto the cable and keep the
 yellow wire unconnected. The other pins have the same order on both
@@ -102,26 +122,41 @@ original one. You can buy an extension cable and cut that 
instead. That way,
 you can still use th

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

[Stephen Rothwell]

Hi Josh,

After merging the tiny tree, today's linux-next build (powerpc64 allnoconfig)
failed like this:

arch/powerpc/kernel/built-in.o: In function `sys_call_table':
(.rodata+0xd58): undefined reference to `.compat_sys_adjtimex'
arch/powerpc/kernel/built-in.o: In function `sys_call_table':
(.rodata+0x1b48): undefined reference to `.compat_sys_clock_adjtime'

Caused by commit be1e48a8e48f ("kernel: time: Compile out NTP support").

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpytjrJk2M1h.pgp
Description: OpenPGP digital signature

[PATCH] Makefile: allow building selected tests with non-NPTL toolchain

[Alexey Brodkin]

Some architectures are still stuck with non-NPTL toolchains.
These are for example ARC, Blackfin, Xtensa etc.

Still rt-tests are very good benchmarks and it would be good to enable use of
at least selected (those that will be built) tests on those architectures.

This change makes it possible to only build subset of tests that don't require
NPTL calls.

By default behavior is not modified - all tests are built, but if one wants
to build with non-NPTL toolchain just add "HAVE_NPTL=no" in command line
or modify "HAVE_NPTL" variable right in Makefile and execute "make".

Signed-off-by: Alexey Brodkin 
Cc: Vineet Gupta 
Cc: Clark Williams 
---
 Makefile | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 318a5c6..675edf7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,13 @@
 VERSION_STRING = 0.89
 
-sources = cyclictest.c signaltest.c pi_stress.c rt-migrate-test.c  \
- ptsematest.c sigwaittest.c svsematest.c pmqtest.c sendme.c\
- pip_stress.c hackbench.c
+HAVE_NPTL ?= yes
+
+ifeq ($(HAVE_NPTL),yes)
+sources = cyclictest.c pi_stress.c pip_stress.c pmqtest.c rt-migrate-test.c
+endif
+
+sources += signaltest.c ptsematest.c sigwaittest.c svsematest.c sendme.c \
+ hackbench.c
 
 TARGETS = $(sources:.c=)
 
-- 
1.9.3

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

[PATCH] ALSA: korg1212: cleanup of printk

[Sudip Mukherjee]

replaced all references of the debug messages via printk
with dev_* macro (mostly dev_dbg).
one reference was changed to pr_err as there the card might have been
uninitialized.

while compiling after these modifications, we are getting three
warnings in function snd_korg1212_create:
2301: warning: format "%d" expects argument of type "int",
but argument 6 has type "long unsigned int" [-Wformat]
2376: warning: format "%x" expects argument of type "unsigned int",
but argument 5 has type "dma_addr_t" [-Wformat]
2376: warning: format "%d" expects argument of type "int",
but argument 6 has type "size_t" [-Wformat]

these warnings were prviously not visible as K1212_DEBUG_LEVEL
was defined as 0.

Signed-off-by: Sudip Mukherjee 
---
 sound/pci/korg1212/korg1212.c | 406 +++---
 1 file changed, 219 insertions(+), 187 deletions(-)

diff --git a/sound/pci/korg1212/korg1212.c b/sound/pci/korg1212/korg1212.c
index 59d21c9..ab8e805 100644
--- a/sound/pci/korg1212/korg1212.c
+++ b/sound/pci/korg1212/korg1212.c
@@ -39,21 +39,6 @@
 #include 
 
 // 
-// Debug Stuff
-// 
-#define K1212_DEBUG_LEVEL  0
-#if K1212_DEBUG_LEVEL > 0
-#define K1212_DEBUG_PRINTK(fmt,args...)printk(KERN_DEBUG fmt,##args)
-#else
-#define K1212_DEBUG_PRINTK(fmt,...)
-#endif
-#if K1212_DEBUG_LEVEL > 1
-#define K1212_DEBUG_PRINTK_VERBOSE(fmt,args...)printk(KERN_DEBUG 
fmt,##args)
-#else
-#define K1212_DEBUG_PRINTK_VERBOSE(fmt,...)
-#endif
-
-// 
 // Record/Play Buffer Allocation Method. If K1212_LARGEALLOC is defined all 
 // buffers are alocated as a large piece inside KorgSharedBuffer.
 // 
@@ -530,12 +515,12 @@ static int snd_korg1212_Send1212Command(struct 
snd_korg1212 *korg1212,
int rc = K1212_CMDRET_Success;
 
 if (!korg1212->outDoorbellPtr) {
-   K1212_DEBUG_PRINTK_VERBOSE("K1212_DEBUG: CardUninitialized\n");
+   pr_err("snd_korg1212_Send1212Command: Card Uninitialized\n");
 return K1212_CMDRET_CardUninitialized;
}
 
-   K1212_DEBUG_PRINTK("K1212_DEBUG: Card <- 0x%08x 0x%08x [%s]\n",
-  doorbellVal, mailBox0Val, 
stateName[korg1212->cardState]);
+   dev_dbg(korg1212->card->dev, "Card <- 0x%08x 0x%08x [%s]\n",
+   doorbellVal, mailBox0Val, stateName[korg1212->cardState]);
 for (retryCount = 0; retryCount < MAX_COMMAND_RETRIES; retryCount++) {
writel(mailBox3Val, korg1212->mailbox3Ptr);
 writel(mailBox2Val, korg1212->mailbox2Ptr);
@@ -562,7 +547,7 @@ static int snd_korg1212_Send1212Command(struct snd_korg1212 
*korg1212,
 mailBox3Lo = readl(korg1212->mailbox3Ptr);
 if (mailBox3Lo & COMMAND_ACK_MASK) {
if ((mailBox3Lo & DOORBELL_VAL_MASK) == (doorbellVal & 
DOORBELL_VAL_MASK)) {
-   K1212_DEBUG_PRINTK_VERBOSE("K1212_DEBUG: Card 
<- Success\n");
+   dev_dbg(korg1212->card->dev, "Card <- 
Success\n");
 rc = K1212_CMDRET_Success;
break;
 }
@@ -571,7 +556,7 @@ static int snd_korg1212_Send1212Command(struct snd_korg1212 
*korg1212,
 korg1212->cmdRetryCount += retryCount;
 
if (retryCount >= MAX_COMMAND_RETRIES) {
-   K1212_DEBUG_PRINTK_VERBOSE("K1212_DEBUG: Card <- 
NoAckFromCard\n");
+   dev_err(korg1212->card->dev, "Card <- NoAckFromCard\n");
rc = K1212_CMDRET_NoAckFromCard;
}
 
@@ -612,20 +597,21 @@ static void snd_korg1212_timer_func(unsigned long data)
korg1212->stop_pending_cnt = 0;
korg1212->dsp_stop_is_processed = 1;
wake_up(&korg1212->wait);
-   K1212_DEBUG_PRINTK_VERBOSE("K1212_DEBUG: Stop ack'ed [%s]\n",
-  stateName[korg1212->cardState]);
+   dev_dbg(korg1212->card->dev, "Stop ack'ed [%s]\n",
+   stateName[korg1212->cardState]);
} else {
if (--korg1212->stop_pending_cnt > 0) {
/* reprogram timer */
korg1212->timer.expires = jiffies + 1;
add_timer(&korg1212->timer);
} else {
-   snd_printd("korg1212_timer_func timeout\n");
+   dev_err(korg1212->card->dev,
+   "korg1212_timer_func timeout\n");
korg1212->sharedBufferPtr->cardCommand = 0;
korg1212->dsp_stop_is_processed = 1;
wake_u

[PATCH] slab: Fix compilation error in case of !CONFIG_NUMA

[Peter Ujfalusi]

Move the definition of slab_free() outside of #ifdef CONFIG_NUMA since it
is used by code which is not NUMA specific. Fixes the following error
introduced by the following commit:
5da1c3c725ab slab: recharge slab pages to the allocating memory cgroup

  CC  mm/slab.o
/home/Z/linux/mm/slab.c: In function ‘slab_alloc’:
/home/Z/linux/mm/slab.c:3260:4: error: implicit declaration of function 
‘slab_free’ [-Werror=implicit-function-declaration]
slab_free(cachep, objp);
^
/home/Z/linux/mm/slab.c: At top level:
/home/Z/linux/mm/slab.c:3534:29: warning: conflicting types for ‘slab_free’ 
[enabled by default]
 static __always_inline void slab_free(struct kmem_cache *cachep, void *objp)
 ^
/home/Z/linux/mm/slab.c:3534:29: error: static declaration of ‘slab_free’ 
follows non-static declaration
/home/Z/linux/mm/slab.c:3260:4: note: previous implicit declaration of 
‘slab_free’ was here
slab_free(cachep, objp);
^
cc1: some warnings being treated as errors
/home/Z/linux/scripts/Makefile.build:257: recipe for target 'mm/slab.o' 
failed
make[2]: *** [mm/slab.o] Error 1
/home/Z/linux/Makefile:953: recipe for target 'mm' failed
make[1]: *** [mm] Error 2
make[1]: *** Waiting for unfinished jobs
  CHK kernel/config_data.h

Signed-off-by: Peter Ujfalusi 
---
 mm/slab.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 61b01c2ae1d9..301ede1c6784 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3133,8 +3133,6 @@ done:
return obj;
 }
 
-static __always_inline void slab_free(struct kmem_cache *cachep, void *objp);
-
 static __always_inline void *
 slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid,
   unsigned long caller)
@@ -3228,6 +3226,8 @@ __do_cache_alloc(struct kmem_cache *cachep, gfp_t flags)
 
 #endif /* CONFIG_NUMA */
 
+static __always_inline void slab_free(struct kmem_cache *cachep, void *objp);
+
 static __always_inline void *
 slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller)
 {
-- 
2.1.3

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

Re: [NOHZ] Remove scheduler_tick_max_deferment

[Viresh Kumar]

On 6 November 2014 22:54, Christoph Lameter  wrote:

> We did not need to housekeeper in the dynticks idle case. What is so
> different about dynticks busy?

We do have a running task here and so the stats are important..

> I may not have the complete picture of the timer tick processing in my
> mind these days (it has been a lots of years since I did any work there
> after all) but as far as my arguably simplistic reading of the code goes I
> do not see why a housekeeper would be needed there. The load is constant
> and known in the dynticks busy case as it is in the dynticks idle case.

I tried to initiate a thread on similar stuff, might be helpful:

https://lkml.org/lkml/2014/5/22/131
--
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/

A recommendation from Support

[support2341]

Hello,

Hey Friend,

As you know, I’m always on the lookout for 
real ways to make decent money.   
 
Not just a measly $20 or $30 a day; I mean real money. 

$20,000 or $30,000 A DAY?!?! Now THAT is…

DAMN GOOD REAL MONEY!

His 6 figure bank accounts now are a pretty good 
indicator that Trevor Haynes has figured it out.

Check this out -  http://tinyurl.com/ko7bljk

The Millionaire Money Machine has nothing to do with 
eBooks, websites, T-shirts, MLM, gambling, writing, 
flipping sites or any of that.

THIS isn’t about making ten buck here or there. 

It’s about making TENS OF THOUSANDS DAILY.

You’ll meet one Millionaire Money Machine user who 
banked over $30K overnight… 

While he was asleep!

Take a look -  http://tinyurl.com/ko7bljk  

For a VERY LIMITED number, Haynes is giving away his 
Millionaire Money Machine. No strings, No BS.

But DO NOT WAIT on this!

Check it out here:

-  http://tinyurl.com/ko7bljk









NOTE: If your email account doesn't automatically turn the URL above into a 
link, 
  you can copy and paste it into your browser.   

If the link is broken please use this: 
http://nikkanares.mmmachine.cpa.clicksure.com   



Click below to view the webpage that your friend has recommended:


Support has used the Tell-a-Friend form to send you this link.

We look forward to your visit!


--
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: [alsa-devel] [PATCH 1/3] ASoC: twl4030: don't report EBUSY if no change requested.

[Lars-Peter Clausen]

On 11/10/2014 01:45 AM, NeilBrown wrote:

diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index b6b0cb399599..613b61cee081 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -957,6 +957,16 @@ static int snd_soc_put_twl4030_opmode_enum_double(struct 
snd_kcontrol *kcontrol,
  {
struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
struct twl4030_priv *twl4030 = snd_soc_codec_get_drvdata(codec);
+   struct snd_ctl_elem_value currentval;



snd_ctl_elem_value is a bit to big to be put onto the kernel stack. Just 
using twl4030_read() should be fine.

--
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/4] inet: Add skb_copy_datagram_iter

[Al Viro]

On Mon, Nov 10, 2014 at 12:20:20AM -0500, David Miller wrote:
> From: Al Viro 
> Date: Sun, 9 Nov 2014 21:19:08 +
> 
> > 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?
> 
> sparc64 will just fault no matter what kind of task it is.
> 
> It is impossible for a user task to generate a reference to
> a kernel virtual address, as kernel and user accesses each
> go via a separate address space identifier.

Sure, but why do we have access_ok() there at all?  I.e. why not just have
it constant 1?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] perf tools: Allow vmlinux to fallback to kallsyms on NO_LIBELF=1

[Namhyung Kim]

On Fri, 7 Nov 2014 12:29:31 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 07, 2014 at 02:20:04PM +0900, Namhyung Kim escreveu:
>> When libelf is not used, perf cannot not show symbol names since it
>> doesn't access the ELF symbol table.  But kernel is different as it
>> can fallback to kallsyms.
>> 
>> It worked w/o libelf, but recent change to use vmlinux for kernel
>> symbols break it.
>> 
>> With this change, it now can show kernel symbols again:
>
> Ok, but since you added that minimal ELF symtab loading, isn't better to
> try that first, i.e. if we find a vmlinux file with a build-id and with
> symbols in it...
>
> If that isn't the case, i.e. no vmlinux was found, then we fallback to
> kallsyms, to check if that is available.
>
> I.e. with your new minimalistic ELF symtab loader if we have a suitable
> vmlinux but no kallsyms, we end up resolving no symbols even having that
> nice vmlinux :-)

Yeah, maybe.  But it'd add a substantial complexity also and I tried to
make it simple and small only to show usual userspace symbols.

I think that about a half of the complexity of the dso__load_sym() in
symbol-elf.c came from the kernel (and module) support.  And expecting
kallsyms on the system is not a high barrier IMHO.  So I decided to just
fall back to kallsyms for kernel dsos.  Mayby we can add the kernel
support incrementally later.

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

Re: [Gta04-owner] [PATCH 2/3] ASoC: twl4030: allow voice port to be connected externally.

[Dr. H. Nikolaus Schaller]

Am 10.11.2014 um 00:25 schrieb NeilBrown :

> On Sat, 8 Nov 2014 09:26:22 + Mark Brown  wrote:
> 
>> On Sat, Nov 08, 2014 at 11:38:03AM +1100, NeilBrown wrote:
>> 
>>> If voice port on twl4030 is not connected to a McBSP (or similar)
>>> then we cannot configure the format the way we normally do for a DAI.
>> 
>> Yes we can, you need to represent the DAI link to whatever else the
>> device is connected to in the driver like we do anything else - and in
>> any case this isn't a device specific issue so we shouldn't be doing
>> something driver specific to solve it.  Look at something like speyside.
> 
> Hi Mark,
> thanks for the reply ... I might need a little bit more help though.
> 
> I had a look at sound/soc/samsung/speyside.c, but I'm not entirely sure what
> I'm looking for.
> Presumably this is an audio processor not unlike the audio module in the
> twl4030.
> 
> I see that there are 3 dai-links:
>  CPU-DSP
>  DSP-CODEC
>  Baseband
> 
> Presumably "Baseband" is similar, in purpose at least, to the "voice"
> interface on the twl4030.
> 
> Each dai-link has a "cpu_dai_name" and a "codec_dai_name", even though it
> appears that only "CPU-DSP" is connected to the CPU.  Maybe that naming is
> the source of some of my confusion.
> 
> "Baseband" declares
>.cpu_dai_name = "wm8996-aif2",
> so wm8996 is something with 2 audio interfaces, (aif), and this is the second
> one?  Maybe the  wm8996 is the audio module, so what is the "speyside"?
> 
> http://opensource.wolfsonmicro.com/content/speyside-audio
> 
> says it is a "reference platform".  Does that mean it is a board with a bunch
> of chips soldered onto it?  If it were a board it should be described by a
> dts file, not by a pile of C code (I thought), so I must be wrong about that.
> 
> 
> In my case, I have a board with a GSM module and the twl4030 module.  Each
> has an audio interface and these are connected.  I assume that I need to
> express this connection in the dts file.
> The GSM module doesn't currently appear in the dts file as it is usb-attached.
> However I've been thinking that we will need to add it so we can express
> power-on controls (twiddling some GPIOs).  So let's suppose we have the GSM
> module in the dts file (child of a USB interface)

It is a quite complex connection pattern and I am not sure if the modem is 
really
a logical child of the USB interface. Powering up/down the USB interface has 
nothing
to do with the modem power. Rather, it continues to operate if USB is suspended
and the modem notifies USB that it has become active.

The connections on this GTA04 board are:

Modem USB <—> CPU USB
Modem PCM <—> TWL4030 Voice <—> OMAP3 McBSP4 (yes, it is a 3-way connection)
Modem Power control <—> 1 or 2 GPIOs (depending on board variant)

The reason for the 3-way connection is that user space can chose if the GSM
voice is routed directly to the TWL codec (low latency, independent of CPU) or
goes through the CPU (e.g. for DTAM or voice scrambling by software) and
then through the other PCM link between the CPU and the TWL.

This is why I would make the McBSP4 a separate sound card.

And, this is why it needs some control and tri-state of the TWL4030 and OMAP3
McBSP4 since only one can provide a digital PCM stream to the modem.

One more thing to consider for a general solution is that there are modem 
modules
that communicate data through UART or SPI - but otherwise have a similar 
connection
for digital audio. So forcing the power control driver to be a subnode of USB 
doesn’t
appear general enough to me.

Finally, this connection pattern is not specific to this modem (OPTION GTM601) 
on this
GTA04 board. We plan to use a Gemalto PHS8  in the Pyra-Handheld and the Neo900
devices - but the general connection pattern as defined above remains the same.

So my proposal is to have a specific wwan-power driver for this type of modems.
And power control can and should be kept separately from USB (except the case
where only 1 GPIO exists and USB must be tapped to detect the modem power
state). You can find work in progress for this approach here:



> and the twl4030 as well
> (beneath an i2c interface).
> 
> The twl4030 needs to know the master/polarity of the clk/frm lines.  The GSM
> module declares that these are.  So presumably we need some sort of linkage.
> A... I found Documentation/devicetree/bindings/sound/simple-card.txt
> 
> So I need to make the "voice" port on the twl4030 look like a "cpu" end of a
> dai-link, and create a "codec" end in the GSM module, and use "sound-dai" to
> point from the twl4030 to the GSM module.

What I wonder a little is that we have all these dai-links working since your 
3.7
kernel for GTA04. Is it necessary to re-invent a solution or should we just make
the solution device tree compatible?

> Then I use fram

Re: [rfc patch] mm: vmscan: invoke slab shrinkers for each lruvec

[Dave Chinner]

On Thu, Nov 06, 2014 at 06:50:28PM -0500, Johannes Weiner wrote:
> The slab shrinkers currently rely on the reclaim code providing an
> ad-hoc concept of NUMA nodes that doesn't really exist: for all
> scanned zones and lruvecs, the nodes and available LRU pages are
> summed up, only to have the shrinkers then again walk that nodemask
> when scanning slab caches.  This duplication will only get worse and
> more expensive once the shrinkers become aware of cgroups.

As i said previously, it's not an "ad-hoc concept". It's exactly the
same NUMA abstraction that the VM presents to anyone who wants to
control memory allocation locality. i.e. node IDs and node masks.

> Instead, invoke the shrinkers for each lruvec scanned - which is
> either the zone level, or in case of cgroups, the subset of a zone's
> pages that is charged to the scanned memcg.  The number of eligible
> LRU pages is naturally available at that level - it is even more
> accurate than simply looking at the global state and the number of
> available swap pages, as get_scan_count() considers many other factors
> when deciding which LRU pages to consider.
> 
> This invokes the shrinkers more often and with smaller page and scan
> counts, but the ratios remain the same, and the shrinkers themselves
> do not add significantly to the existing per-lruvec cost.

That goes in the opposite direction is which we've found filesystem
shrinkers operate most effectively. i.e. larger batches with less
frequent reclaim callouts tend to result in more consistent
performance because shrinkers take locks and do IO that other
application operations get stuck behind (shrink_batch exists
for this reason ;).

>
> This integrates the slab shrinking nicely into the reclaim logic.  Not
> just conceptually, but it also allows kswapd, the direct reclaim code,
> and zone reclaim to get rid of their ad-hoc custom slab shrinking.
> 
> Lastly, this facilitates making the shrinkers cgroup-aware without a
> fantastic amount code and runtime work duplication, and consolidation 
> will make hierarchy walk optimizations easier later on.

It still makes callers have to care about internal VM metrics
to calculate how much work they should do. Callers should be able to
pass in a measure of how much work the shrinker should do (e.g. as
a percentage of cache size). Even the VM can use this - it can take
it's scanned/pages variables and use them to calculate the
percentage of caches to free, and the shrinker loop can then be
completely free of any relationship to the LRU page reclaim
implementation.

e.g. drop_caches() should just be able to call "shrink_slab_all()"
and not have to care about nodes, batch sizes, detect when caches
are empty, etc. Similarly shake_page() only wants
"shrink_slab_node_nr()" to free a small amount of objects from the
node it cares about each time.

i.e. we should be writing helpers to remove shrinker implementation
quirks from callers, not driving more of the quirks into external
callers...

> Signed-off-by: Johannes Weiner 
> ---
>  drivers/staging/android/ashmem.c |   1 -
>  fs/drop_caches.c |  15 ++--
>  include/linux/shrinker.h |   2 -
>  mm/memory-failure.c  |   3 +-
>  mm/vmscan.c  | 164 
> +--
>  5 files changed, 63 insertions(+), 122 deletions(-)
> 
> I put this together as a result of the discussion with Vladimir about
> memcg-aware slab shrinkers this morning.
> 
> This might need some tuning, but it definitely looks like the right
> thing to do conceptually.  I'm currently playing with various slab-
> and memcg-heavy workloads (many numa nodes + many cgroups = many
> shrinker invocations) but so far the numbers look okay.
> 
> It would be great if other people could weigh in, and possibly also
> expose it to their favorite filesystem and reclaim stress tests.

Causes substantial increase in performance variability on inode
intensive benchmarks. On my standard fsmark benchmark, I see file
creates sit at around 250,000/sec, but there's several second long
dips to about 50,000/sec co-inciding with the inode cache being
trimmed by several million inodes. Looking more deeply, this is due
to memory pressure driving inode writeback - we're reclaiming inodes
that haven't yet been written to disk, and so by reclaiming the
inode cache slab more frequently it's driving larger peaks of IO
and blocking ongoing filesystem operations more frequently.

My initial thoughts are that this correlates with the above comments
I made about frequency of shrinker calls and batch sizes, so I
suspect that the aggregation of shrinker-based reclaim work is
necessary to minimise the interference that recalim causes at the
filesystem level...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.

[PATCH] tty: pr_warning->pr_warn and logging neatening

[Joe Perches]

Convert the pr_warning to the more common pr_warn.

Other miscellanea:

o Convert unusual PR_FMT define and uses to pr_fmt
o Remove unnecessary OOM message
o Fix grammar in an error message
o Convert a pr_warning with a KERN_ERR to pr_err

Signed-off-by: Joe Perches 
---
 drivers/tty/ehv_bytechan.c   |  4 ++--
 drivers/tty/hvc/hvcs.c   |  2 +-
 drivers/tty/isicom.c | 14 +++---
 drivers/tty/serial/bfin_sport_uart.c |  5 +++--
 drivers/tty/serial/mfd.c |  2 +-
 drivers/tty/serial/mrst_max3110.c| 27 ---
 drivers/tty/vt/keyboard.c|  6 +++---
 drivers/tty/vt/vt.c  |  4 ++--
 8 files changed, 31 insertions(+), 33 deletions(-)

diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index 4f485e8..9d29d7e 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -309,8 +309,8 @@ static int __init ehv_bc_console_init(void)
 * handle for udbg.
 */
if (stdout_bc != CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE)
-   pr_warning("ehv-bc: udbg handle %u is not the stdout handle\n",
-  CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE);
+   pr_warn("ehv-bc: udbg handle %u is not the stdout handle\n",
+   CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE);
 #endif
 
/* add_preferred_console() must be called before register_console(),
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index 81e939e..00bec633 100644
--- a/drivers/tty/hvc/hvcs.c
+++ b/drivers/tty/hvc/hvcs.c
@@ -1575,7 +1575,7 @@ static int __init hvcs_module_init(void)
 */
rc = driver_create_file(&(hvcs_vio_driver.driver), &driver_attr_rescan);
if (rc)
-   pr_warning(KERN_ERR "HVCS: Failed to create rescan file (err 
%d)\n", rc);
+   pr_err("HVCS: Failed to create rescan file (err %d)\n", rc);
 
return 0;
 }
diff --git a/drivers/tty/isicom.c b/drivers/tty/isicom.c
index 858291c..59ed783 100644
--- a/drivers/tty/isicom.c
+++ b/drivers/tty/isicom.c
@@ -249,7 +249,7 @@ static int lock_card(struct isi_board *card)
spin_unlock_irqrestore(&card->card_lock, card->flags);
msleep(10);
}
-   pr_warning("Failed to lock Card (0x%lx)\n", card->base);
+   pr_warn("Failed to lock Card (0x%lx)\n", card->base);
 
return 0;   /* Failed to acquire the card! */
 }
@@ -378,13 +378,13 @@ static inline int __isicom_paranoia_check(struct isi_port 
const *port,
char *name, const char *routine)
 {
if (!port) {
-   pr_warning("Warning: bad isicom magic for dev %s in %s.\n",
-  name, routine);
+   pr_warn("Warning: bad isicom magic for dev %s in %s\n",
+   name, routine);
return 1;
}
if (port->magic != ISICOM_MAGIC) {
-   pr_warning("Warning: NULL isicom port for dev %s in %s.\n",
-  name, routine);
+   pr_warn("Warning: NULL isicom port for dev %s in %s\n",
+   name, routine);
return 1;
}
 
@@ -546,8 +546,8 @@ static irqreturn_t isicom_interrupt(int irq, void *dev_id)
byte_count = header & 0xff;
 
if (channel + 1 > card->port_count) {
-   pr_warning("%s(0x%lx): %d(channel) > port_count.\n",
-  __func__, base, channel+1);
+   pr_warn("%s(0x%lx): %d(channel) > port_count\n",
+   __func__, base, channel + 1);
outw(0x, base+0x04); /* enable interrupts */
spin_unlock(&card->card_lock);
return IRQ_HANDLED;
diff --git a/drivers/tty/serial/bfin_sport_uart.c 
b/drivers/tty/serial/bfin_sport_uart.c
index d62d8da..67d4083 100644
--- a/drivers/tty/serial/bfin_sport_uart.c
+++ b/drivers/tty/serial/bfin_sport_uart.c
@@ -517,14 +517,15 @@ static void sport_set_termios(struct uart_port *port,
up->csize = 5;
break;
default:
-   pr_warning("requested word length not supported\n");
+   pr_warn("requested word length not supported\n");
+   break;
}
 
if (termios->c_cflag & CSTOPB) {
up->stopb = 1;
}
if (termios->c_cflag & PARENB) {
-   pr_warning("PAREN bits is not supported yet\n");
+   pr_warn("PAREN bit is not supported yet\n");
/* up->parib = 1; */
}
 
diff --git a/drivers/tty/serial/mfd.c b/drivers/tty/serial/mfd.c
index 445799d..e1f4fda 100644
--- a/drivers/tty/serial/mfd.c
+++ b/drivers/tty/serial/mfd.c
@@ -1371,7 +1371,7 @@ static void hsu_global_init(void)
hsu->iolen = 0x1000;
 
if (!(request_mem_region(hsu->paddr, hsu->iolen, "HSU global")))
-   pr_warning("HSU: error in request mem region\n");
+   pr_warn("HSU: error in 

Re: [PATCH 1/3] SMBUS: Add DeviceIDs for SunrisePoint LP

[Jean Delvare]

Hi Devin,

On Fri, 07 Nov 2014 17:55:43 -0500, Devin Ryles wrote:
> From 8386c61977dce52fcdfe7fb279692606f47650bc Mon Sep 17 00:00:00 2001
> From: Devin Ryles 
> Date: Wed, 5 Nov 2014 16:30:03 -0500
> Subject: [PATCH 1/3] SMBUS: Add DeviceIDs for SunrisePoint LP
> 
> This patch adds the DeviceIDs for SunrisePoint LP
> 
> Signed-off-by: Devin Ryles 
> ---
>  Documentation/i2c/busses/i2c-i801 | 1 +
>  drivers/i2c/busses/Kconfig| 1 +
>  drivers/i2c/busses/i2c-i801.c | 3 +++
>  3 files changed, 5 insertions(+)
> 
> diff --git a/Documentation/i2c/busses/i2c-i801email-clients.txt
> b/Documentation/i2c/busses/i2c-i801
> index 793c83d..82f48f7 100644
> --- a/Documentation/i2c/busses/i2c-i801
> +++ b/Documentation/i2c/busses/i2c-i801
> @@ -29,6 +29,7 @@ Supported adapters:
>* Intel Wildcat Point-LP (PCH)
>* Intel BayTrail (SOC)
>* Intel Sunrise Point-H (PCH)
> +  * Intel Sunrise Point-LP (PCH)
> Datasheets: Publicly available at the Intel website
>  
>  On Intel Patsburg and later chipsets, both the normal host SMBus
> controller
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 917c358..06e99eb 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -123,6 +123,7 @@ config I2C_I801
>   Wildcat Point-LP (PCH)
>   BayTrail (SOC)
>   Sunrise Point-H (PCH)
> + Sunrise Point-LP (PCH)
>  
> This driver can also be built as a module.  If so, the module
> will be called i2c-i801.
> diff --git a/drivers/i2c/busses/i2c-i801.c
> b/drivers/i2c/busses/i2c-i801.c
> index 7cfc183..e158e18 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -63,6 +63,7 @@
>   * Wildcat Point-LP (PCH)0x9ca2  32  hardyes yes yes
>   * BayTrail (SOC)0x0f12  32  hardyes yes yes
>   * Sunrise Point-H (PCH) 0xa123  32  hardyes yes yes
> + * Sunrise Point-LP (PCH)0x9d23  32  hardyes yes yes
>   *
>   * Features supported by this driver:
>   * Software PEC  no
> @@ -186,6 +187,7 @@
>  #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_SMBUS   0x9c22
>  #define PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_SMBUS0x9ca2
>  #define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_SMBUS 0xa123
> +#define PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_SMBUS0x9d23
>  
>  struct i801_mux_config {
>   char *gpio_chip;
> @@ -833,6 +835,7 @@ static const struct pci_device_id i801_ids[] = {
>   { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_BAYTRAIL_SMBUS) },
>   { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_BRASWELL_SMBUS) },
>   { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_SMBUS) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_SMBUS) },
>   { 0, }
>  };
>  

This looks good, however your e-mail client wrapped long lines so the
patch can't be applied. Please reconfigure your client to not do that
and send the patches again. In Evolution, you can select the entire
contents of the patch and set the formatting to "Pre-formatted", that
should work. See Documentation/email-clients.txt for more details. If
you're not sure, try sending the message to yourself once first to make
sure the formatting is good.

Thanks,
-- 
Jean Delvare
SUSE L3 Support
--
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 03/13] KVM: Add KVM_CAP_PI to detect VT-d Posted-Interrtups

[Feng Wu]

This patch adds KVM_CAP_PI to detect VT-d Posted-Interrtups
feature for QEMU.

Signed-off-by: Feng Wu 
---
 arch/x86/kvm/x86.c   |4 
 include/uapi/linux/kvm.h |1 +
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0033df3..b447a98 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -63,6 +63,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_IO_MSRS 256
 #define KVM_MAX_MCE_BANKS 32
@@ -2775,6 +2776,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
ext)
case KVM_CAP_TSC_DEADLINE_TIMER:
r = boot_cpu_has(X86_FEATURE_TSC_DEADLINE_TIMER);
break;
+   case KVM_CAP_PI:
+   r = irq_post_enabled;
+   break;
default:
r = 0;
break;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 6076882..7593c52 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -761,6 +761,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_PPC_FIXUP_HCALL 103
 #define KVM_CAP_PPC_ENABLE_HCALL 104
 #define KVM_CAP_CHECK_EXTENSION_VM 105
+#define KVM_CAP_PI 106
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
1.7.1

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

[PATCH 04/13] iommu/vt-d: Adjust 'struct irte' to better suit for VT-d Posted-Interrupts

[Feng Wu]

This patch adjusts the definition of 'struct irte', so that we can
add the VT-d Posted-Interrtups format in this structure later.

Signed-off-by: Feng Wu 
---
 drivers/iommu/intel_irq_remapping.c |   35 +++
 include/linux/dmar.h|4 ++--
 2 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index f99f0f1..776da10 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -310,9 +310,9 @@ static void set_irte_sid(struct irte *irte, unsigned int 
svt,
 {
if (disable_sourceid_checking)
svt = SVT_NO_VERIFY;
-   irte->svt = svt;
-   irte->sq = sq;
-   irte->sid = sid;
+   irte->irq_remap_high.svt = svt;
+   irte->irq_remap_high.sq = sq;
+   irte->irq_remap_high.sid = sid;
 }
 
 static int set_ioapic_sid(struct irte *irte, int apic)
@@ -917,8 +917,8 @@ static void prepare_irte(struct irte *irte, int vector,
 {
memset(irte, 0, sizeof(*irte));
 
-   irte->present = 1;
-   irte->dst_mode = apic->irq_dest_mode;
+   irte->irq_remap_low.present = 1;
+   irte->irq_remap_low.dst_mode = apic->irq_dest_mode;
/*
 * Trigger mode in the IRTE will always be edge, and for IO-APIC, the
 * actual level or edge trigger will be setup in the IO-APIC
@@ -926,11 +926,11 @@ static void prepare_irte(struct irte *irte, int vector,
 * For more details, see the comments (in io_apic.c) explainig IO-APIC
 * irq migration in the presence of interrupt-remapping.
*/
-   irte->trigger_mode = 0;
-   irte->dlvry_mode = apic->irq_delivery_mode;
-   irte->vector = vector;
-   irte->dest_id = IRTE_DEST(dest);
-   irte->redir_hint = 1;
+   irte->irq_remap_low.trigger_mode = 0;
+   irte->irq_remap_low.dlvry_mode = apic->irq_delivery_mode;
+   irte->irq_remap_low.vector = vector;
+   irte->irq_remap_low.dest_id = IRTE_DEST(dest);
+   irte->irq_remap_low.redir_hint = 1;
 }
 
 static int intel_setup_ioapic_entry(int irq,
@@ -973,10 +973,13 @@ static int intel_setup_ioapic_entry(int irq,
"Redir_hint:%d Trig_Mode:%d Dlvry_Mode:%X "
"Avail:%X Vector:%02X Dest:%08X "
"SID:%04X SQ:%X SVT:%X)\n",
-   attr->ioapic, irte.present, irte.fpd, irte.dst_mode,
-   irte.redir_hint, irte.trigger_mode, irte.dlvry_mode,
-   irte.avail, irte.vector, irte.dest_id,
-   irte.sid, irte.sq, irte.svt);
+   attr->ioapic, irte.irq_remap_low.present,
+   irte.irq_remap_low.fpd, irte.irq_remap_low.dst_mode,
+   irte.irq_remap_low.redir_hint, irte.irq_remap_low.trigger_mode,
+   irte.irq_remap_low.dlvry_mode, irte.irq_remap_low.avail,
+   irte.irq_remap_low.vector, irte.irq_remap_low.dest_id,
+   irte.irq_remap_high.sid, irte.irq_remap_high.sq,
+   irte.irq_remap_high.svt);
 
entry = (struct IR_IO_APIC_route_entry *)route_entry;
memset(entry, 0, sizeof(*entry));
@@ -1046,8 +1049,8 @@ intel_ioapic_set_affinity(struct irq_data *data, const 
struct cpumask *mask,
return err;
}
 
-   irte.vector = cfg->vector;
-   irte.dest_id = IRTE_DEST(dest);
+   irte.irq_remap_low.vector = cfg->vector;
+   irte.irq_remap_low.dest_id = IRTE_DEST(dest);
 
/*
 * Atomically updates the IRTE with the new destination, vector
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index 593fff9..8be5d42 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -159,7 +159,7 @@ struct irte {
vector  : 8,
__reserved_2: 8,
dest_id : 32;
-   };
+   } irq_remap_low;
__u64 low;
};
 
@@ -169,7 +169,7 @@ struct irte {
sq  : 2,
svt : 2,
__reserved_3: 44;
-   };
+   } irq_remap_high;
__u64 high;
};
 };
-- 
1.7.1

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

[PATCH 00/13] Add VT-d Posted-Interrupts support for KVM

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html

Feng Wu (13):
  iommu/vt-d: VT-d Posted-Interrupts feature detection
  KVM: Initialize VT-d Posted-Interrtups Descriptor
  KVM: Add KVM_CAP_PI to detect VT-d Posted-Interrtups
  iommu/vt-d: Adjust 'struct irte' to better suit for VT-d
Posted-Interrupts
  KVM: Update IRTE according to guest interrupt configuration changes
  KVM: Add some helper functions for Posted-Interrupts
  x86, irq: Define a global vector for VT-d Posted-Interrupts
  KVM: Update Posted-Interrupts descriptor during VCPU scheduling
  KVM: Change NDST field after VCPU scheduling
  KVM: Add the handler for Wake-up Vector
  KVM: Suppress posted-interrupt when 'SN' is set
  iommu/vt-d: No need to migrating irq for VT-d Posted-Interrtups
  iommu/vt-d: Add a command line parameter for VT-d posted-interrupts

 arch/x86/include/asm/entry_arch.h|2 +
 arch/x86/include/asm/hardirq.h   |1 +
 arch/x86/include/asm/hw_irq.h|2 +
 arch/x86/include/asm/irq_remapping.h |7 +
 arch/x86/include/asm/irq_vectors.h   |1 +
 arch/x86/include/asm/kvm_host.h  |9 ++
 arch/x86/kernel/apic/apic.c  |1 +
 arch/x86/kernel/entry_64.S   |2 +
 arch/x86/kernel/irq.c|   27 
 arch/x86/kernel/irqinit.c|2 +
 arch/x86/kvm/vmx.c   |  257 +-
 arch/x86/kvm/x86.c   |   53 ++-
 drivers/iommu/amd_iommu.c|6 +
 drivers/iommu/intel_irq_remapping.c  |   83 +--
 drivers/iommu/irq_remapping.c|   20 +++
 drivers/iommu/irq_remapping.h|8 +
 include/linux/dmar.h |   30 -
 include/linux/intel-iommu.h  |1 +
 include/linux/kvm_host.h |   25 
 include/uapi/linux/kvm.h |2 +
 virt/kvm/assigned-dev.c  |  141 +++
 virt/kvm/irq_comm.c  |4 +-
 virt/kvm/irqchip.c   |   11 --
 virt/kvm/kvm_main.c  |   14 ++
 24 files changed, 667 insertions(+), 42 deletions(-)

--
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 10/13] KVM: Add the handler for Wake-up Vector

[Feng Wu]

When VCPU is blocked and an external interrupts from assigned
devices is delivered to it, VT-d Posted-Interrupts mechanism
will deliver a interrrupt to the associated physical CPU with
Wake-up Vector. In its handler, we find the destination VCPU
and wake up it.

Signed-off-by: Feng Wu 
---
 arch/x86/include/asm/kvm_host.h |2 +
 arch/x86/kvm/vmx.c  |   52 +++
 arch/x86/kvm/x86.c  |   22 +++-
 include/linux/kvm_host.h|3 ++
 virt/kvm/kvm_main.c |3 ++
 5 files changed, 75 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 71cfe3e..ca231a3 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -99,6 +99,8 @@ static inline gfn_t gfn_to_index(gfn_t gfn, gfn_t base_gfn, 
int level)
 
 #define ASYNC_PF_PER_VCPU 64
 
+extern void (*wakeup_handler_callback)(void);
+
 enum kvm_reg {
VCPU_REGS_RAX = 0,
VCPU_REGS_RCX = 1,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index fa77714..51d2c8a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -822,6 +822,13 @@ static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
 static DEFINE_PER_CPU(struct list_head, loaded_vmcss_on_cpu);
 static DEFINE_PER_CPU(struct desc_ptr, host_gdt);
 
+/*
+ * We maintian a per-CPU linked-list of VCPU, so in wakeup_handler() we
+ * can find which VCPU should be waken up.
+ */
+static DEFINE_PER_CPU(struct list_head, blocked_vcpu_on_cpu);
+static DEFINE_PER_CPU(spinlock_t, blocked_vcpu_on_cpu_lock);
+
 static unsigned long *vmx_io_bitmap_a;
 static unsigned long *vmx_io_bitmap_b;
 static unsigned long *vmx_msr_bitmap_legacy;
@@ -2813,6 +2820,8 @@ static int hardware_enable(void)
return -EBUSY;
 
INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu));
+   INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu));
+   spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
 
/*
 * Now we can enable the vmclear operation in kdump
@@ -9183,6 +9192,7 @@ static int vmx_vcpu_pre_block(struct kvm_vcpu *vcpu)
struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
struct pi_desc old;
struct pi_desc new;
+   unsigned long flags;
 
if (!irq_post_enabled)
return 0;
@@ -9222,9 +9232,22 @@ static int vmx_vcpu_pre_block(struct kvm_vcpu *vcpu)
 
/* set 'NV' to 'wakeup vector' */
new.nv = POSTED_INTR_WAKEUP_VECTOR;
+
+   /*
+* We should save physical cpu id here, vcpu->cpu may
+* be changed due to preemption, in that case, this
+* do-while loop will run again.
+*/
+   vcpu->wakeup_cpu = vcpu->cpu;
} while (cmpxchg(&pi_desc->control, old.control, new.control)
!= old.control);
 
+   spin_lock_irqsave(&per_cpu(blocked_vcpu_on_cpu_lock,
+   vcpu->wakeup_cpu), flags);
+   list_add_tail(&vcpu->blocked_vcpu_list,
+   &per_cpu(blocked_vcpu_on_cpu, vcpu->wakeup_cpu));
+   spin_unlock_irqrestore(&per_cpu(blocked_vcpu_on_cpu_lock,
+   vcpu->wakeup_cpu), flags);
return 0;
 }
 
@@ -9234,6 +9257,7 @@ static void vmx_vcpu_post_block(struct kvm_vcpu *vcpu)
struct pi_desc old;
struct pi_desc new;
unsigned int dest = 0;
+   unsigned long flags;
 
if (!irq_post_enabled)
return;
@@ -9255,6 +9279,13 @@ static void vmx_vcpu_post_block(struct kvm_vcpu *vcpu)
} while (cmpxchg(&pi_desc->control, old.control, new.control)
!= old.control);
 
+   spin_lock_irqsave(&per_cpu(blocked_vcpu_on_cpu_lock,
+   vcpu->wakeup_cpu), flags);
+   list_del(&vcpu->blocked_vcpu_list);
+   spin_unlock_irqrestore(&per_cpu(blocked_vcpu_on_cpu_lock,
+   vcpu->wakeup_cpu), flags);
+   vcpu->wakeup_cpu = -1;
+
pi_clear_sn(pi_desc);
 }
 
@@ -9372,6 +9403,25 @@ static struct kvm_x86_ops vmx_x86_ops = {
.vcpu_post_block = vmx_vcpu_post_block,
 };
 
+/*
+ * Handler for POSTED_INTERRUPT_WAKEUP_VECTOR.
+ */
+void wakeup_handler(void)
+{
+   struct kvm_vcpu *vcpu;
+   int cpu = smp_processor_id();
+
+   spin_lock(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
+   list_for_each_entry(vcpu, &per_cpu(blocked_vcpu_on_cpu, cpu),
+   blocked_vcpu_list) {
+   struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+
+   if (pi_test_on(pi_desc) == 1)
+   kvm_vcpu_kick(vcpu);
+   }
+   spin_unlock(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
+}
+
 static int __init vmx_init(void)
 {
int r, i, msr;
@@ -9486,6 +9536,8 @@ static int __init vmx_init(void)
 
update_ple_window_actual_max();
 
+   wakeup_handler_callback = wakeup_handler;
+
   

[PATCH 02/13] KVM: Initialize VT-d Posted-Interrtups Descriptor

[Feng Wu]

This patch initialize the VT-d Posted-interrupt Descritpor.

Signed-off-by: Feng Wu 
---
 arch/x86/include/asm/irq_remapping.h |1 +
 arch/x86/kernel/apic/apic.c  |1 +
 arch/x86/kvm/vmx.c   |   56 -
 3 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index b7747c4..a3cc437 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -57,6 +57,7 @@ extern bool setup_remapped_irq(int irq,
   struct irq_chip *chip);
 
 void irq_remap_modify_chip_defaults(struct irq_chip *chip);
+extern int irq_post_enabled;
 
 #else  /* CONFIG_IRQ_REMAP */
 
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index ba6cc04..987408d 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -162,6 +162,7 @@ __setup("apicpmtimer", setup_apicpmtimer);
 #endif
 
 int x2apic_mode;
+EXPORT_SYMBOL_GPL(x2apic_mode);
 #ifdef CONFIG_X86_X2APIC
 /* x2apic enabled before OS handover */
 int x2apic_preenabled;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3e556c6..a4670d3 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "trace.h"
 
@@ -408,13 +409,32 @@ struct nested_vmx {
 };
 
 #define POSTED_INTR_ON  0
+#define POSTED_INTR_SN  1
+
 /* Posted-Interrupt Descriptor */
 struct pi_desc {
u32 pir[8]; /* Posted interrupt requested */
-   u32 control;/* bit 0 of control is outstanding notification bit */
-   u32 rsvd[7];
+   union {
+   struct {
+   u64 on  : 1,
+   sn  : 1,
+   rsvd_1  : 13,
+   ndm : 1,
+   nv  : 8,
+   rsvd_2  : 8,
+   ndst: 32;
+   };
+   u64 control;
+   };
+   u32 rsvd[6];
 } __aligned(64);
 
+static void pi_clear_sn(struct pi_desc *pi_desc)
+{
+   return clear_bit(POSTED_INTR_SN,
+   (unsigned long *)&pi_desc->control);
+}
+
 static bool pi_test_and_set_on(struct pi_desc *pi_desc)
 {
return test_and_set_bit(POSTED_INTR_ON,
@@ -4396,6 +4416,33 @@ static void ept_set_mmio_spte_mask(void)
kvm_mmu_set_mmio_spte_mask((0x3ull << 62) | 0x6ull);
 }
 
+static bool pi_desc_init(struct vcpu_vmx *vmx)
+{
+   unsigned int dest;
+
+   if (irq_post_enabled == 0)
+   return true;
+
+   /*
+* Initialize Posted-Interrupt Descriptor
+*/
+
+   pi_clear_sn(&vmx->pi_desc);
+   vmx->pi_desc.nv = POSTED_INTR_VECTOR;
+
+   /* Physical mode for Notificaiton Event */
+   vmx->pi_desc.ndm = 0;
+   dest = cpu_physical_id(vmx->vcpu.cpu);
+
+   if (x2apic_mode)
+   vmx->pi_desc.ndst = dest;
+   else
+   vmx->pi_desc.ndst = (dest << 8) & 0xFF00;
+
+   return true;
+}
+
+
 /*
  * Sets up the vmcs for emulated real mode.
  */
@@ -4439,6 +4486,11 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
 
vmcs_write64(POSTED_INTR_NV, POSTED_INTR_VECTOR);
vmcs_write64(POSTED_INTR_DESC_ADDR, __pa((&vmx->pi_desc)));
+
+   if (!pi_desc_init(vmx)) {
+   printk(KERN_ERR "Initialize PI descriptor error!\n");
+   return 1;
+   }
}
 
if (ple_gap) {
-- 
1.7.1

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

[PATCH 01/13] iommu/vt-d: VT-d Posted-Interrupts feature detection

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

This patch adds feature detection logic for VT-d posted-interrupt.

Signed-off-by: Feng Wu 
---
 drivers/iommu/intel_irq_remapping.c |   13 +
 drivers/iommu/irq_remapping.c   |4 
 drivers/iommu/irq_remapping.h   |5 +
 include/linux/intel-iommu.h |1 +
 4 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 7c80661..f99f0f1 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -580,6 +580,19 @@ static int __init intel_irq_remapping_supported(void)
if (!ecap_ir_support(iommu->ecap))
return 0;
 
+   /* VT-d posted-interrupt feature detection*/
+   if (disable_irq_post == 0)
+   for_each_drhd_unit(drhd) {
+   struct intel_iommu *iommu = drhd->iommu;
+
+   if (!cap_pi_support(iommu->cap)) {
+   irq_post_enabled = 0;
+   disable_irq_post = 1;
+   break;
+   }
+   irq_post_enabled = 1;
+   }
+
return 1;
 }
 
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 74a1767..2f8ee00 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -23,6 +23,10 @@ int irq_remap_broken;
 int disable_sourceid_checking;
 int no_x2apic_optout;
 
+int disable_irq_post = 1;
+int irq_post_enabled = 0;
+EXPORT_SYMBOL_GPL(irq_post_enabled);
+
 static struct irq_remap_ops *remap_ops;
 
 static int msi_alloc_remapped_irq(struct pci_dev *pdev, int irq, int nvec);
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index fde250f..7bb5913 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -37,6 +37,9 @@ extern int disable_sourceid_checking;
 extern int no_x2apic_optout;
 extern int irq_remapping_enabled;
 
+extern int disable_irq_post;
+extern int irq_post_enabled;
+
 struct irq_remap_ops {
/* Check whether Interrupt Remapping is supported */
int (*supported)(void);
@@ -91,6 +94,8 @@ extern struct irq_remap_ops amd_iommu_irq_ops;
 #define irq_remapping_enabled 0
 #define disable_irq_remap 1
 #define irq_remap_broken  0
+#define disable_irq_post  1
+#define irq_post_enabled  0
 
 #endif /* CONFIG_IRQ_REMAP */
 
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index a65208a..5b1a124 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -87,6 +87,7 @@ static inline void dmar_writeq(void __iomem *addr, u64 val)
 /*
  * Decoding Capability Register
  */
+#define cap_pi_support(c)  (((c) >> 59) & 1)
 #define cap_read_drain(c)  (((c) >> 55) & 1)
 #define cap_write_drain(c) (((c) >> 54) & 1)
 #define cap_max_amask_val(c)   (((c) >> 48) & 0x3f)
-- 
1.7.1

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

[PATCH 12/13] iommu/vt-d: No need to migrating irq for VT-d Posted-Interrtups

[Feng Wu]

We don't need to migrate the irqs for VT-d Posted-Interrtups here.
When 'pst' is set in IRTE, the associated irq will be posted to
guests instead of interrupt remapping. The destination of the
interrupt is set in Posted-Interrupts Descriptor, and the migration
happens during VCPU scheduling.

Signed-off-by: Feng Wu 
---
 drivers/iommu/intel_irq_remapping.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 87c02fe..249e2b1 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1038,6 +1038,13 @@ intel_ioapic_set_affinity(struct irq_data *data, const 
struct cpumask *mask,
if (get_irte(irq, &irte))
return -EBUSY;
 
+   /*
+* If the interrupt is for posting, it is used by guests,
+* we cannot change IRTE here.
+*/
+   if (irte.irq_post_low.pst == 1)
+   return 0;
+
err = assign_irq_vector(irq, cfg, mask);
if (err)
return err;
-- 
1.7.1

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

[PATCH 05/13] KVM: Update IRTE according to guest interrupt configuration changes

[Feng Wu]

When guest changes its interrupt configuration (such as, vector, etc.)
for direct-assigned devices, we need to update the associated IRTE
with the new guest vector, so external interrupts from the assigned
devices can be injected to guests without VM-Exit.

The current method of handling guest lowest priority interrtups
is to use a counter 'apic_arb_prio' for each VCPU, we choose the
VCPU with smallest 'apic_arb_prio' and then increase it by 1.
However, for VT-d PI, we cannot re-use this, since we no longer
have control to 'apic_arb_prio' with posted interrupt direct
delivery by Hardware.

Here, we introduce a similiar way with 'apic_arb_prio' to handle
guest lowest priority interrtups when VT-d PI is used. Here is the
ideas:
- Each VCPU has a counter 'round_robin_counter'.
- When guests sets an interrupts to lowest priority, we choose
the VCPU with smallest 'round_robin_counter' as the destination,
then increase it.

Signed-off-by: Feng Wu 
---
 arch/x86/include/asm/irq_remapping.h |6 ++
 arch/x86/include/asm/kvm_host.h  |2 +
 arch/x86/kvm/vmx.c   |   12 +++
 arch/x86/kvm/x86.c   |   11 +++
 drivers/iommu/amd_iommu.c|6 ++
 drivers/iommu/intel_irq_remapping.c  |   28 +++
 drivers/iommu/irq_remapping.c|9 ++
 drivers/iommu/irq_remapping.h|3 +
 include/linux/dmar.h |   26 ++
 include/linux/kvm_host.h |   22 +
 include/uapi/linux/kvm.h |1 +
 virt/kvm/assigned-dev.c  |  141 ++
 virt/kvm/irq_comm.c  |4 +-
 virt/kvm/irqchip.c   |   11 ---
 14 files changed, 269 insertions(+), 13 deletions(-)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index a3cc437..32d6cc4 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -51,6 +51,7 @@ extern void compose_remapped_msi_msg(struct pci_dev *pdev,
 unsigned int irq, unsigned int dest,
 struct msi_msg *msg, u8 hpet_id);
 extern int setup_hpet_msi_remapped(unsigned int irq, unsigned int id);
+extern int update_pi_irte(unsigned int irq, u64 pi_desc_addr, u32 vector);
 extern void panic_if_irq_remap(const char *msg);
 extern bool setup_remapped_irq(int irq,
   struct irq_cfg *cfg,
@@ -88,6 +89,11 @@ static inline int setup_hpet_msi_remapped(unsigned int irq, 
unsigned int id)
return -ENODEV;
 }
 
+static inline int update_pi_irte(unsigned int irq, u64 pi_desc_addr, u32 
vector)
+{
+   return -ENODEV;
+}
+
 static inline void panic_if_irq_remap(const char *msg)
 {
 }
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 6ed0c30..0630161 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -358,6 +358,7 @@ struct kvm_vcpu_arch {
struct kvm_lapic *apic;/* kernel irqchip context */
unsigned long apic_attention;
int32_t apic_arb_prio;
+   int32_t round_robin_counter;
int mp_state;
u64 ia32_misc_enable_msr;
bool tpr_access_reporting;
@@ -771,6 +772,7 @@ struct kvm_x86_ops {
int (*check_nested_events)(struct kvm_vcpu *vcpu, bool external_intr);
 
void (*sched_in)(struct kvm_vcpu *kvm, int cpu);
+   u64 (*get_pi_desc_addr)(struct kvm_vcpu *vcpu);
 };
 
 struct kvm_arch_async_pf {
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index a4670d3..ae91b72 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -544,6 +544,11 @@ static inline struct vcpu_vmx *to_vmx(struct kvm_vcpu 
*vcpu)
return container_of(vcpu, struct vcpu_vmx, vcpu);
 }
 
+struct pi_desc *vcpu_to_pi_desc(struct kvm_vcpu *vcpu)
+{
+   return &(to_vmx(vcpu)->pi_desc);
+}
+
 #define VMCS12_OFFSET(x) offsetof(struct vmcs12, x)
 #define FIELD(number, name)[number] = VMCS12_OFFSET(name)
 #define FIELD64(number, name)  [number] = VMCS12_OFFSET(name), \
@@ -4280,6 +4285,11 @@ static void vmx_sync_pir_to_irr_dummy(struct kvm_vcpu 
*vcpu)
return;
 }
 
+static u64 vmx_get_pi_desc_addr(struct kvm_vcpu *vcpu)
+{
+   return __pa((u64)vcpu_to_pi_desc(vcpu));
+}
+
 /*
  * Set up the vmcs's constant host-state fields, i.e., host-state fields that
  * will not change in the lifetime of the guest.
@@ -9232,6 +9242,8 @@ static struct kvm_x86_ops vmx_x86_ops = {
.check_nested_events = vmx_check_nested_events,
 
.sched_in = vmx_sched_in,
+
+   .get_pi_desc_addr = vmx_get_pi_desc_addr,
 };
 
 static int __init vmx_init(void)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b447a98..0c19d15 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7735,6 +7735,17 @@ bool kvm_arch_has_noncoherent_dma(struct kvm *kvm)
 }
 EXPORT_SYMBOL_GPL(kvm_arch_has_noncoherent_dma);
 
+int kvm_update_pi_irte_common(struct kvm *kvm, struct kvm_v

[PATCH 11/13] KVM: Suppress posted-interrupt when 'SN' is set

[Feng Wu]

Currently, we don't support urgent interrupt, all interrupts
are recognized as non-urgent interrupt, so we cannot send
posted-interrupt when 'SN' is set.

Signed-off-by: Feng Wu 
---
 arch/x86/kvm/vmx.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 51d2c8a..495cfbd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4306,15 +4306,22 @@ static int vmx_vm_has_apicv(struct kvm *kvm)
 static void vmx_deliver_posted_interrupt(struct kvm_vcpu *vcpu, int vector)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
-   int r;
+   int r, sn;
 
if (pi_test_and_set_pir(vector, &vmx->pi_desc))
return;
 
+   /*
+* Currently, we don't support urgent interrupt, all interrupts
+* are recognized as non-urgent interrupt, so we cannot send
+* posted-interrupt when 'SN' is set.
+*/
+   sn = pi_test_sn(&vmx->pi_desc);
+
r = pi_test_and_set_on(&vmx->pi_desc);
kvm_make_request(KVM_REQ_EVENT, vcpu);
 #ifdef CONFIG_SMP
-   if (!r && (vcpu->mode == IN_GUEST_MODE))
+   if (!r && !sn && (vcpu->mode == IN_GUEST_MODE))
apic->send_IPI_mask(get_cpu_mask(vcpu->cpu),
POSTED_INTR_VECTOR);
else
-- 
1.7.1

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

[PATCH 09/13] KVM: Change NDST field after VCPU scheduling

[Feng Wu]

This patch changes the NDST filed of Posted-Interrupts
Descriptor after VCPU is scheduled to another physical
CPU.

Signed-off-by: Feng Wu 
---
 arch/x86/kvm/vmx.c |   25 +
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4c1a966..fa77714 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1906,6 +1906,31 @@ static void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
vmcs_writel(HOST_IA32_SYSENTER_ESP, sysenter_esp); /* 22.2.3 */
vmx->loaded_vmcs->cpu = cpu;
}
+
+   if (irq_post_enabled && (vcpu->cpu != cpu)) {
+   struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+   struct pi_desc old, new;
+   unsigned int dest;
+
+   memset(&old, 0, sizeof(old));
+   memset(&new, 0, sizeof(new));
+
+   pi_set_sn(pi_desc);
+
+   do {
+   old.control = new.control = pi_desc->control;
+
+   dest = cpu_physical_id(cpu);
+
+   if (x2apic_mode)
+   new.ndst = dest;
+   else
+   new.ndst = (dest << 8) & 0xFF00;
+
+   } while (cmpxchg(&pi_desc->control, old.control,
+   new.control) != old.control);
+   pi_clear_sn(pi_desc);
+   }
 }
 
 static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
-- 
1.7.1

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

[PATCH 07/13] x86, irq: Define a global vector for VT-d Posted-Interrupts

[Feng Wu]

Currently, we use a global vector as the Posted-Interrupts
Notification Event for all the VCPUs in the system. We need
to introduce another global vector for VT-d Posted-Interrtups,
which will be used to wakeup the sleep VCPU when an external
interrupt from a direct-assigned device happens for that VCPU.

Signed-off-by: Feng Wu 
---
 arch/x86/include/asm/entry_arch.h  |2 ++
 arch/x86/include/asm/hardirq.h |1 +
 arch/x86/include/asm/hw_irq.h  |2 ++
 arch/x86/include/asm/irq_vectors.h |1 +
 arch/x86/kernel/entry_64.S |2 ++
 arch/x86/kernel/irq.c  |   27 +++
 arch/x86/kernel/irqinit.c  |2 ++
 7 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/entry_arch.h 
b/arch/x86/include/asm/entry_arch.h
index dc5fa66..27ca0af 100644
--- a/arch/x86/include/asm/entry_arch.h
+++ b/arch/x86/include/asm/entry_arch.h
@@ -23,6 +23,8 @@ BUILD_INTERRUPT(x86_platform_ipi, X86_PLATFORM_IPI_VECTOR)
 #ifdef CONFIG_HAVE_KVM
 BUILD_INTERRUPT3(kvm_posted_intr_ipi, POSTED_INTR_VECTOR,
 smp_kvm_posted_intr_ipi)
+BUILD_INTERRUPT3(kvm_posted_intr_wakeup_ipi, POSTED_INTR_WAKEUP_VECTOR,
+smp_kvm_posted_intr_wakeup_ipi)
 #endif
 
 /*
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index 0f5fb6b..9866065 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -14,6 +14,7 @@ typedef struct {
 #endif
 #ifdef CONFIG_HAVE_KVM
unsigned int kvm_posted_intr_ipis;
+   unsigned int kvm_posted_intr_wakeup_ipis;
 #endif
unsigned int x86_platform_ipis; /* arch dependent */
unsigned int apic_perf_irqs;
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 4615906..559563c 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -29,6 +29,7 @@
 extern asmlinkage void apic_timer_interrupt(void);
 extern asmlinkage void x86_platform_ipi(void);
 extern asmlinkage void kvm_posted_intr_ipi(void);
+extern asmlinkage void kvm_posted_intr_wakeup_ipi(void);
 extern asmlinkage void error_interrupt(void);
 extern asmlinkage void irq_work_interrupt(void);
 
@@ -92,6 +93,7 @@ extern void trace_call_function_single_interrupt(void);
 #define trace_irq_move_cleanup_interrupt  irq_move_cleanup_interrupt
 #define trace_reboot_interrupt  reboot_interrupt
 #define trace_kvm_posted_intr_ipi kvm_posted_intr_ipi
+#define trace_kvm_posted_intr_wakeup_ipi kvm_posted_intr_wakeup_ipi
 #endif /* CONFIG_TRACING */
 
 /* IOAPIC */
diff --git a/arch/x86/include/asm/irq_vectors.h 
b/arch/x86/include/asm/irq_vectors.h
index 5702d7e..1343349 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -105,6 +105,7 @@
 /* Vector for KVM to deliver posted interrupt IPI */
 #ifdef CONFIG_HAVE_KVM
 #define POSTED_INTR_VECTOR 0xf2
+#define POSTED_INTR_WAKEUP_VECTOR  0xf1
 #endif
 
 /*
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index df088bb..7663aaa 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1004,6 +1004,8 @@ apicinterrupt X86_PLATFORM_IPI_VECTOR \
 #ifdef CONFIG_HAVE_KVM
 apicinterrupt3 POSTED_INTR_VECTOR \
kvm_posted_intr_ipi smp_kvm_posted_intr_ipi
+apicinterrupt3 POSTED_INTR_WAKEUP_VECTOR \
+   kvm_posted_intr_wakeup_ipi smp_kvm_posted_intr_wakeup_ipi
 #endif
 
 #ifdef CONFIG_X86_MCE_THRESHOLD
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 922d285..47408c3 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -237,6 +237,9 @@ __visible void smp_x86_platform_ipi(struct pt_regs *regs)
 }
 
 #ifdef CONFIG_HAVE_KVM
+void (*wakeup_handler_callback)(void) = NULL;
+EXPORT_SYMBOL_GPL(wakeup_handler_callback);
+
 /*
  * Handler for POSTED_INTERRUPT_VECTOR.
  */
@@ -256,6 +259,30 @@ __visible void smp_kvm_posted_intr_ipi(struct pt_regs 
*regs)
 
set_irq_regs(old_regs);
 }
+
+/*
+ * Handler for POSTED_INTERRUPT_WAKEUP_VECTOR.
+ */
+__visible void smp_kvm_posted_intr_wakeup_ipi(struct pt_regs *regs)
+{
+   struct pt_regs *old_regs = set_irq_regs(regs);
+
+   ack_APIC_irq();
+
+   irq_enter();
+
+   exit_idle();
+
+   inc_irq_stat(kvm_posted_intr_wakeup_ipis);
+
+   if (wakeup_handler_callback)
+   wakeup_handler_callback();
+
+   irq_exit();
+
+   set_irq_regs(old_regs);
+}
+
 #endif
 
 __visible void smp_trace_x86_platform_ipi(struct pt_regs *regs)
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index 4de73ee..659cde3 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -168,6 +168,8 @@ static void __init apic_intr_init(void)
 #ifdef CONFIG_HAVE_KVM
/* IPI for KVM to deliver posted interrupt */
alloc_intr_gate(POSTED_INTR_VECTOR, kvm_posted_intr_ipi);
+   /* IPI for KVM to deliver interrupt to wake up tasks */
+   alloc_intr_gate(POSTED_INTR_WAKEUP_VECTOR, kvm_

Re: [RFC] ptrace: add generic SET_SYSCALL request

[AKASHI Takahiro]

On 11/07/2014 09:27 PM, Will Deacon wrote:

On Fri, Nov 07, 2014 at 12:03:00PM +, Arnd Bergmann wrote:

On Friday 07 November 2014 11:55:51 Will Deacon wrote:

On Fri, Nov 07, 2014 at 09:30:53AM +, Arnd Bergmann wrote:

On Friday 07 November 2014 16:47:23 AKASHI Takahiro wrote:

This patch adds a new generic ptrace request, PTRACE_SET_SYSCALL.
It can be used to change a system call number as follows:
 ret = ptrace(pid, PTRACE_SET_SYSCALL, null, new_syscall_no);
'new_syscall_no' can be -1 to skip this system call, you need to modify
a register's value, in arch-specific way, as return value though.

Please note that we can't define PTRACE_SET_SYSCALL macro in
uapi/linux/ptrace.h partly because its value on arm, 23, is used as another
request on sparc.

This patch also contains an example of change on arch side, arm.
Only syscall_set_nr() is required to be defined in asm/syscall.h.

Currently only arm has this request, while arm64 would also have it
once my patch series of seccomp for arm64 is merged. It will also be
usable for most of other arches.
See the discussions in lak-ml:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/300167.html

Signed-off-by: AKASHI Takahiro 



Can you describe why you are moving the implementation? Is this a feature
that we want to have on all architectures in the future? As you say,
only arm32 implements is at the moment.


We need this for arm64 and, since all architectures seem to have a mechanism
for setting a system call via ptrace, moving it to generic code should make
sense for new architectures too, no?


It makes a little more sense now, but I still don't understand why you
need to set the system call number via ptrace. What is this used for,
and why doesn't any other architecture have this?


I went through the same thought process back in August, and Akashi
eventually convinced me that this was the best thing to do:

   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/278692.html

It comes down to a debugger (which could be GDB, seccomp, tracer ...)
wanting to change the system call number. This is also used as a mechanism
to skip a system call by setting it to '-1' (yeah, it's gross, and the
interaction between all of these syscall hooks is horrible too).

If we update w8 directly instead, we run into a couple of issues:

   - Needing to restore the original w8 if the value is set to '-1' for
 skip, but continuing to return -ENOSYS for syscall(-1) when not on a
 tracer path


Yeah, this restriction still exists on my recent patch, v7.
(this is because arm64 uses the same register, x0, as the first argument
and a return value.)


   - seccomp assumes that syscall_get_nr will return the version set by
 the most recent tracer, so then we need hacks in ptrace to route
 register writes to w8 to syscallno in pt_regs, but again, only in the
 case that we're tracing.


The problem here is that, if we had a hack of replacinging syscallno with w8
in ptrace (ptrace_syscall_enter()), secure_computing() (actually, 
seccomp_phase2()
on v3.18-rc) would have no chance of seeing a modified syscall number because
the hack would be executed after secure_computing().
(Please note that a tracer simply modifies w8, not syscallno directly).

This eventually results in missing a special case of -1 (skipping this system 
call).

http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/280846.html

That is why we needed to have a dedicated new interface.

-Takahiro AKASHI


Akashi might be able to elaborate on other problems, since this was a
couple of months ago and I take every opportunity I can to avoid looking
at this part of the kernel.

Will


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

[PATCH 06/13] KVM: Add some helper functions for Posted-Interrupts

[Feng Wu]

This patch adds three helper functions to manipulate the Posted-
Interrtups Decriptor.

Signed-off-by: Feng Wu 
---
 arch/x86/kvm/vmx.c |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ae91b72..f4f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -435,6 +435,24 @@ static void pi_clear_sn(struct pi_desc *pi_desc)
(unsigned long *)&pi_desc->control);
 }
 
+static void pi_set_sn(struct pi_desc *pi_desc)
+{
+   return set_bit(POSTED_INTR_SN,
+   (unsigned long *)&pi_desc->control);
+}
+
+static int pi_test_on(struct pi_desc *pi_desc)
+{
+   return test_bit(POSTED_INTR_ON,
+   (unsigned long *)&pi_desc->control);
+}
+
+static int pi_test_sn(struct pi_desc *pi_desc)
+{
+   return test_bit(POSTED_INTR_SN,
+   (unsigned long *)&pi_desc->control);
+}
+
 static bool pi_test_and_set_on(struct pi_desc *pi_desc)
 {
return test_and_set_bit(POSTED_INTR_ON,
-- 
1.7.1

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

[PATCH 08/13] KVM: Update Posted-Interrupts descriptor during VCPU scheduling

[Feng Wu]

Update Posted-Interrupts descriptor according to the
following rules:
- Before VCPU block, set 'NV' to POSTED_INTR_WAKEUP_VECTOR
- After VCPU block, set 'NV' back to POSTED_INTR_VECTOR

Signed-off-by: Feng Wu 
---
 arch/x86/include/asm/kvm_host.h |5 ++
 arch/x86/kvm/vmx.c  |   83 +++
 arch/x86/kvm/x86.c  |   16 +++
 virt/kvm/kvm_main.c |   11 +
 4 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 0630161..71cfe3e 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -773,6 +773,8 @@ struct kvm_x86_ops {
 
void (*sched_in)(struct kvm_vcpu *kvm, int cpu);
u64 (*get_pi_desc_addr)(struct kvm_vcpu *vcpu);
+   int (*vcpu_pre_block)(struct kvm_vcpu *vcpu);
+   void (*vcpu_post_block)(struct kvm_vcpu *vcpu);
 };
 
 struct kvm_arch_async_pf {
@@ -1095,4 +1097,7 @@ int kvm_pmu_read_pmc(struct kvm_vcpu *vcpu, unsigned pmc, 
u64 *data);
 void kvm_handle_pmu_event(struct kvm_vcpu *vcpu);
 void kvm_deliver_pmi(struct kvm_vcpu *vcpu);
 
+int kvm_arch_vcpu_pre_block(struct kvm_vcpu *vcpu);
+void kvm_arch_vcpu_post_block(struct kvm_vcpu *vcpu);
+
 #endif /* _ASM_X86_KVM_HOST_H */
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index f4f..4c1a966 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -9153,6 +9153,86 @@ static void vmx_sched_in(struct kvm_vcpu *vcpu, int cpu)
shrink_ple_window(vcpu);
 }
 
+static int vmx_vcpu_pre_block(struct kvm_vcpu *vcpu)
+{
+   struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+   struct pi_desc old;
+   struct pi_desc new;
+
+   if (!irq_post_enabled)
+   return 0;
+
+   memset(&old, 0, sizeof(old));
+   memset(&new, 0, sizeof(new));
+
+   do {
+   old.control = new.control = pi_desc->control;
+
+   /*
+* A posted-interrupt happened in the one of the
+* following two cases:
+* 1. After the latest pir-to-virr sync operation
+* in kvm_arch_vcpu_runnable() function
+* 2. In this do-while() loop, a posted-interrupt
+* occurs.
+*
+* For either of above cases, we should not block
+* the VCPU.
+*/
+   if (pi_test_on(pi_desc) == 1) {
+   /*
+* Need to set this flag, then the inject will
+* be synced from PIR to vIRR before VM-ENTRY.
+* In fact, for guest IPI case, in function
+* vmx_deliver_posted_interrupt(), this flags
+* has already been set, but if the interrupt
+* is injected by VT-d PI hardware, we need
+* to set this.
+*/
+   kvm_make_request(KVM_REQ_EVENT, vcpu);
+   return 1;
+   }
+
+   pi_clear_sn(&new);
+
+   /* set 'NV' to 'wakeup vector' */
+   new.nv = POSTED_INTR_WAKEUP_VECTOR;
+   } while (cmpxchg(&pi_desc->control, old.control, new.control)
+   != old.control);
+
+   return 0;
+}
+
+static void vmx_vcpu_post_block(struct kvm_vcpu *vcpu)
+{
+   struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
+   struct pi_desc old;
+   struct pi_desc new;
+   unsigned int dest = 0;
+
+   if (!irq_post_enabled)
+   return;
+
+   pi_set_sn(pi_desc);
+
+   do {
+   old.control = new.control = pi_desc->control;
+
+   dest = cpu_physical_id(vcpu->cpu);
+
+   if (x2apic_mode)
+   new.ndst = dest;
+   else
+   new.ndst = (dest << 8) & 0xFF00;
+
+   /* set 'NV' to 'notification vector' */
+   new.nv = POSTED_INTR_VECTOR;
+   } while (cmpxchg(&pi_desc->control, old.control, new.control)
+   != old.control);
+
+   pi_clear_sn(pi_desc);
+}
+
 static struct kvm_x86_ops vmx_x86_ops = {
.cpu_has_kvm_support = cpu_has_kvm_support,
.disabled_by_bios = vmx_disabled_by_bios,
@@ -9262,6 +9342,9 @@ static struct kvm_x86_ops vmx_x86_ops = {
.sched_in = vmx_sched_in,
 
.get_pi_desc_addr = vmx_get_pi_desc_addr,
+
+   .vcpu_pre_block = vmx_vcpu_pre_block,
+   .vcpu_post_block = vmx_vcpu_post_block,
 };
 
 static int __init vmx_init(void)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0c19d15..d0c8bb2 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7746,6 +7746,22 @@ int kvm_update_pi_irte_common(struct kvm *kvm, struct 
kvm_vcpu *vcpu,
return 0;
 }
 
+int kvm_arch_vcpu_pre_block(struct kvm_vcpu *vcpu)
+{
+   if (kvm_x86_ops->vcpu_pre_block)
+   retur

Re: [PATCH 2/3] perf symbol: Implement a very simple ELF symbol parser

[Namhyung Kim]

Hi Arnaldo,

On Fri, 7 Nov 2014 12:26:18 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 07, 2014 at 02:20:05PM +0900, Namhyung Kim escreveu:
>> It'll be used to show (userspace) symbol names when libelf isn't (or
>> cannot be) linked.
>
> Does this deals with prelink, etc?

I believe so. :)

>  
>>   # Overhead  Command Shared Object  Symbol
>>   #   ..  .  .
>>   #
>>   37.01%  mem-memcpy  libc-2.17.so   [.] __memcpy_ssse3_back

  namhyung@sejong:linux$ readelf -WS /lib64/libc-2.17.so | grep prelink
[41] .gnu.prelink_undo PROGBITS 200368 000c30 01
  0   0  8

  namhyung@sejong:linux$ nm /lib64/libc-2.17.so | grep __memcpy_ssse3_back
  003153f46f40 t __memcpy_ssse3_back


Thanks,
Namhyung


>>   24.25%  perfld-2.17.so [.] _dl_relocate_object
>>   22.16%  perf[kernel.kallsyms]  [k] kmem_cache_alloc
>>   14.29%  mem-memset  libc-2.17.so   [.] __memset_sse2
>>2.21%  perf[kernel.kallsyms]  [k] flush_signal_handlers
>>0.07%  perf[kernel.kallsyms]  [k] intel_pmu_enable_all
--
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 13/13] iommu/vt-d: Add a command line parameter for VT-d posted-interrupts

[Feng Wu]

Enable VT-d Posted-Interrtups and add a command line
parameter for it.

Signed-off-by: Feng Wu 
---
 drivers/iommu/irq_remapping.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 0e36860..3cb9429 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -23,7 +23,7 @@ int irq_remap_broken;
 int disable_sourceid_checking;
 int no_x2apic_optout;
 
-int disable_irq_post = 1;
+int disable_irq_post = 0;
 int irq_post_enabled = 0;
 EXPORT_SYMBOL_GPL(irq_post_enabled);
 
@@ -206,6 +206,13 @@ static __init int setup_irqremap(char *str)
 }
 early_param("intremap", setup_irqremap);
 
+static __init int setup_nointpost(char *str)
+{
+   disable_irq_post = 1;
+   return 0;
+}
+early_param("nointpost", setup_nointpost);
+
 void __init setup_irq_remapping_ops(void)
 {
remap_ops = &intel_irq_remap_ops;
-- 
1.7.1

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

linux-next: manual merge of the pinctrl tree with the arm-soc tree

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the pinctrl tree got a conflict in
arch/arm/boot/dts/ste-nomadik-stn8815.dtsi between commit 2096eb80e446
("ARM: nomadik: move GPIO I2C to S8815 board file") and 43c4034963d6
("ARM: nomadik: set up MCDATDIR2") from the arm-soc tree and commits
68d41f23ce8d ("pinctrl: nomadik: force-convert to generic mux
bindings") and 1637d480f873 ("pinctrl: nomadik: force-convert to
generic config bindings") from the pinctrl tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

I also added this merge fix patch:

From: Stephen Rothwell 
Date: Mon, 10 Nov 2014 17:30:59 +1100
Subject: [PATCH] pinctrl: nomadik: fix up for binding changes

Signed-off-by: Stephen Rothwell 
---
 arch/arm/boot/dts/ste-nomadik-s8815.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ste-nomadik-s8815.dts 
b/arch/arm/boot/dts/ste-nomadik-s8815.dts
index 7a7e2443503f..85d3b95dfdba 100644
--- a/arch/arm/boot/dts/ste-nomadik-s8815.dts
+++ b/arch/arm/boot/dts/ste-nomadik-s8815.dts
@@ -43,7 +43,7 @@
gpioi2c {
gpioi2c_default_mode: gpioi2c_default {
gpioi2c_default_cfg {
-   ste,pins = "GPIO73_C21", "GPIO74_C20";
+   pins = "GPIO73_C21", "GPIO74_C20";
ste,input = <0>;
};
};
-- 
2.1.3

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

diff --cc arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
index f435ff20aefe,c8b4a93180f8..
--- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
+++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
@@@ -116,8 -116,8 +116,8 @@@
mmcsd {
mmcsd_default_mux: mmcsd_mux {
mmcsd_default_mux {
-   ste,function = "mmcsd";
-   ste,pins = "mmcsd_a_1", "mmcsd_b_1";
+   function = "mmcsd";
 -  groups = "mmcsd_a_1";
++  groups = "mmcsd_a_1", "mmcsd_b_1";
};
};
mmcsd_default_mode: mmcsd_default {
@@@ -127,9 -127,9 +127,9 @@@
ste,output = <0>;
};
mmcsd_default_cfg2 {
 -  /* MCCMDDIR, MCDAT0DIR, MCDAT31DIR */
 +  /* MCCMDDIR, MCDAT0DIR, MCDAT31DIR, 
MCDATDIR2 */
-   ste,pins = "GPIO10_C11", "GPIO15_A12",
+   pins = "GPIO10_C11", "GPIO15_A12",
 -  "GPIO16_C13";
 +  "GPIO16_C13", "GPIO23_D15";
ste,output = <1>;
};
mmcsd_default_cfg3 {


pgpRaFNhESNLq.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] perf tools: Allow vmlinux to fallback to kallsyms on NO_LIBELF=1

[Namhyung Kim]

Hi Peter,

On Fri, 7 Nov 2014 18:37:18 +0100, Peter Zijlstra wrote:
> On Fri, Nov 07, 2014 at 11:57:39PM +0900, Namhyung Kim wrote:
>
>> > Why does this live in the minimal implementation; should we not always
>> > discard ELF files with 0 symbols?
>> > 
>> > Suppose I have a vmlinux but removed all symbols from it; I want it to
>> > fall back to kallsyms too.
>> 
>> I'm not sure I understood what you said correctly.  With this change,
>> dso__load_kernel_sym() always ends up calling dso__load_kallsyms() since
>> dso__load_vmlinux() will always return 0;
>> 
>> So I think you'll fall back to kallsyms even though you have a vmlinux
>> with symbol.  This makes dso__load_sym() in the patch 2/3 simpler IMHO.
>
> But why have it specific to the minimal elf thing? Why not discard any
> DSO with 0 symbols and try the next option to acquire symbols?

Hmm.. I don't think it's specific to the minimal elf parser.  The return
value of dso__load_sym() is a number of symbols found so when it sees a
dso with 0 symbols it'll fall back to the next option IMHO (not
tested).  Did you see a problem with the current code?

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

linux-next: manual merge of the pinctrl tree with the driver-core tree

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the pinctrl tree got a conflict in
drivers/pinctrl/pinctrl-rockchip.c between commit 9198f509c888
("pinctrl: rockchip: add suspend/resume functions") from the
driver-core tree and commit 5c759d73b022 ("pinctrl: drop owner
assignment from platform_drivers") from the pinctrl tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/pinctrl/pinctrl-rockchip.c
index 71d5835d864b,40970c305dd0..
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@@ -1982,6 -2053,8 +2053,7 @@@ static struct platform_driver rockchip_
.probe  = rockchip_pinctrl_probe,
.driver = {
.name   = "rockchip-pinctrl",
 -  .owner  = THIS_MODULE,
+   .pm = &rockchip_pinctrl_dev_pm_ops,
.of_match_table = rockchip_pinctrl_dt_match,
},
  };


pgp6yPG5BloNg.pgp
Description: OpenPGP digital signature

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

[Anish Bhatt]

Fix for this was sent out on thursday itself, but does not seem to be applied 
yet :
http://marc.info/?l=linux-scsi&m=141529629911520&w=2

From: Stephen Rothwell [s...@canb.auug.org.au]
Sent: Sunday, November 09, 2014 10:15 PM
To: James Bottomley
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; 
Christoph Hellwig; Karen Xie
Subject: linux-next: build failure after merge of the scsi tree

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/cxgbi/cxgb4i/cxgb4i.c: In function 'do_abort_req_rss':
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:942:3: error: too many arguments to function 
'send_tx_flowc_wr'
   send_tx_flowc_wr(csk, 0);
   ^
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:492:20: note: declared here
 static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
^

Caused by commit 4be50d4f7649 ("cxgb4i: send abort_rpl correctly").

I have used the scsi tree from next-20141106 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] f2fs: implement -o dirsync

[Jaegeuk Kim]

If a mount option has dirsync, we should call checkpoint for all the directory
operations.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/namei.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 6312dd2..db3ee09 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -138,6 +138,9 @@ static int f2fs_create(struct inode *dir, struct dentry 
*dentry, umode_t mode,
stat_inc_inline_inode(inode);
d_instantiate(dentry, inode);
unlock_new_inode(inode);
+
+   if (IS_DIRSYNC(dir))
+   f2fs_sync_fs(sbi->sb, 1);
return 0;
 out:
handle_failed_inode(inode);
@@ -164,6 +167,9 @@ static int f2fs_link(struct dentry *old_dentry, struct 
inode *dir,
f2fs_unlock_op(sbi);
 
d_instantiate(dentry, inode);
+
+   if (IS_DIRSYNC(dir))
+   f2fs_sync_fs(sbi->sb, 1);
return 0;
 out:
clear_inode_flag(F2FS_I(inode), FI_INC_LINK);
@@ -233,6 +239,9 @@ static int f2fs_unlink(struct inode *dir, struct dentry 
*dentry)
f2fs_delete_entry(de, page, dir, inode);
f2fs_unlock_op(sbi);
 
+   if (IS_DIRSYNC(dir))
+   f2fs_sync_fs(sbi->sb, 1);
+
/* In order to evict this inode, we set it dirty */
mark_inode_dirty(inode);
 fail:
@@ -268,6 +277,9 @@ static int f2fs_symlink(struct inode *dir, struct dentry 
*dentry,
 
d_instantiate(dentry, inode);
unlock_new_inode(inode);
+
+   if (IS_DIRSYNC(dir))
+   f2fs_sync_fs(sbi->sb, 1);
return err;
 out:
handle_failed_inode(inode);
@@ -304,6 +316,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry 
*dentry, umode_t mode)
d_instantiate(dentry, inode);
unlock_new_inode(inode);
 
+   if (IS_DIRSYNC(dir))
+   f2fs_sync_fs(sbi->sb, 1);
return 0;
 
 out_fail:
@@ -346,8 +360,12 @@ static int f2fs_mknod(struct inode *dir, struct dentry 
*dentry,
f2fs_unlock_op(sbi);
 
alloc_nid_done(sbi, inode->i_ino);
+
d_instantiate(dentry, inode);
unlock_new_inode(inode);
+
+   if (IS_DIRSYNC(dir))
+   f2fs_sync_fs(sbi->sb, 1);
return 0;
 out:
handle_failed_inode(inode);
@@ -461,6 +479,9 @@ static int f2fs_rename(struct inode *old_dir, struct dentry 
*old_dentry,
}
 
f2fs_unlock_op(sbi);
+
+   if (IS_DIRSYNC(old_dir) || IS_DIRSYNC(new_dir))
+   f2fs_sync_fs(sbi->sb, 1);
return 0;
 
 put_out_dir:
@@ -600,6 +621,9 @@ static int f2fs_cross_rename(struct inode *old_dir, struct 
dentry *old_dentry,
update_inode_page(new_dir);
 
f2fs_unlock_op(sbi);
+
+   if (IS_DIRSYNC(old_dir) || IS_DIRSYNC(new_dir))
+   f2fs_sync_fs(sbi->sb, 1);
return 0;
 out_undo:
/* Still we may fail to recover name info of f2fs_inode here */
-- 
2.1.1

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

Re: [PATCH] cpufreq: respect the min/max settings from user space

[Vince Hsu]

Hi Viresh,

Just sent v2 with your ACK. :)

Hi Rafael,

Could you please apply the v2? Thanks!

Vince

On 11/10/2014 01:09 PM, Viresh Kumar wrote:

On 28 October 2014 08:55, Vince Hsu  wrote:

Hi Viresh,

Could you remind me where can I find this patch upstream? It seems this was
missed?

Rafael hasn't picked it up. You can normally look at the tree Rafael
manages:

git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git

Can you please resend it to Rafael ?
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

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

[Stephen Rothwell]

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

drivers/scsi/cxgbi/cxgb4i/cxgb4i.c: In function 'do_abort_req_rss':
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:942:3: error: too many arguments to function 
'send_tx_flowc_wr'
   send_tx_flowc_wr(csk, 0);
   ^
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:492:20: note: declared here
 static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
^

Caused by commit 4be50d4f7649 ("cxgb4i: send abort_rpl correctly").

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


pgpb4Igw5bUXD.pgp
Description: OpenPGP digital signature

[PATCH V2] cpufreq: respect the min/max settings from user space

[Vince Hsu]

When the user space tries to set scaling_(max|min)_freq through
sysfs, the cpufreq_set_policy() asks other driver's opinions
for the max/min frequencies. Some device drivers, like Tegra
CPU EDP which is not upstreamed yet though, may constrain the
CPU maximum frequency dynamically because of board design.
So if the user space access happens and some driver is capping
the cpu frequency at the same time, the user_policy->(max|min)
is overridden by the capped value, and that's not expected by
the user space. And if the user space is not invoked again,
the CPU will always be capped by the user_policy->(max|min)
even no drivers limit the CPU frequency any more.

This patch preserves the user specified min/max settings, so that
every time the cpufreq policy is updated, the new max/min can
be re-evaluated correctly based on the user's expection and
the present device drivers' status.

Signed-off-by: Vince Hsu 
Acked-by: Viresh Kumar 
---
v2: added Viresh's Acked-by

 drivers/cpufreq/cpufreq.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 644b54e1e7d1..0721ab352e2a 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -535,7 +535,7 @@ static int cpufreq_set_policy(struct cpufreq_policy *policy,
 static ssize_t store_##file_name   \
 (struct cpufreq_policy *policy, const char *buf, size_t count) \
 {  \
-   int ret;\
+   int ret, temp;  \
struct cpufreq_policy new_policy;   \
\
ret = cpufreq_get_policy(&new_policy, policy->cpu); \
@@ -546,8 +546,10 @@ static ssize_t store_##file_name   
\
if (ret != 1)   \
return -EINVAL; \
\
+   temp = new_policy.object;   \
ret = cpufreq_set_policy(policy, &new_policy);  \
-   policy->user_policy.object = policy->object;\
+   if (!ret)   \
+   policy->user_policy.object = temp;  \
\
return ret ? ret : count;   \
 }
-- 
1.9.1

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

Re: [PATCH 14/18] perf tools: Make vmlinux short name more like kallsyms short name

[Namhyung Kim]

Hi Jiri,

On Sun, 9 Nov 2014 08:51:26 +0100, Jiri Olsa wrote:
> On Thu, Nov 06, 2014 at 06:04:35PM -0300, Arnaldo Carvalho de Melo wrote:
>> From: Namhyung Kim 
>> 
>> The previous patch changed kernel dso name from '[kernel.kallsyms]' to
>> vmlinux.  However it might add confusion to old users accustomed to the
>> old name.  So change the short name to '[kernel.vmlinux]' to reduce such
>> confusion.
>> 
>
> SNIP
>
>> Signed-off-by: Arnaldo Carvalho de Melo 
>> ---
>>  tools/perf/util/machine.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
>> index 53f90e9c65fe..52e94902afb1 100644
>> --- a/tools/perf/util/machine.c
>> +++ b/tools/perf/util/machine.c
>> @@ -1106,6 +1106,9 @@ static int machine__process_kernel_mmap_event(struct 
>> machine *machine,
>>  if (__machine__create_kernel_maps(machine, kernel) < 0)
>>  goto out_problem;
>>  
>> +if (strstr(dso->long_name, "vmlinux"))
>> +dso__set_short_name(dso, "[kernel.vmlinux]", false);
>> +
>
> heya,
> I've got attached segfault in perf script because of this,
> if I revert it's ok..

Oops, sorry.  It seems somehow to fail to find a matching kernel dso
from the build-id table..  anyway we need to access 'kernel' instead of
'dso' since it might be invalid at this time.

Could you please check below patch?


>From e28ec815465721b81669c47eb00d8307f4b424cd Mon Sep 17 00:00:00 2001
From: Namhyung Kim 
Date: Mon, 10 Nov 2014 15:05:26 +0900
Subject: [PATCH] perf tools: Fix segfault due to invalid kernel dso access

When processing kernel mmap event, it should access the 'kernel'
variable as sometimes it cannot find a matching dso from build-id
table so 'dso' might be invalid.

Reported-by: Jiri Olsa 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/machine.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 52e94902afb1..85033d80fd6a 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1106,8 +1106,8 @@ static int machine__process_kernel_mmap_event(struct 
machine *machine,
if (__machine__create_kernel_maps(machine, kernel) < 0)
goto out_problem;
 
-   if (strstr(dso->long_name, "vmlinux"))
-   dso__set_short_name(dso, "[kernel.vmlinux]", false);
+   if (strstr(kernel->long_name, "vmlinux"))
+   dso__set_short_name(kernel, "[kernel.vmlinux]", false);
 
machine__set_kernel_mmap_len(machine, event);
 
-- 
2.1.2

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

Re: linux-next: manual merge of the char-misc tree with the staging tree

[Greg KH]

On Mon, Nov 10, 2014 at 04:53:16PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the char-misc tree got a conflict in
> drivers/Makefile between commit 83e0abae ("staging: android:
> binder: move to the "real" part of the kernel") from the staging tree and
> commit a06ae8609b3d ("coresight: add CoreSight core layer framework")
> from the char-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/Makefile
> index 60d19820a4d4,628b512b625b..
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@@ -161,4 -161,4 +161,5 @@@ obj-$(CONFIG_POWERCAP)   += powercap
>   obj-$(CONFIG_MCB)   += mcb/
>   obj-$(CONFIG_RAS)   += ras/
>   obj-$(CONFIG_THUNDERBOLT)   += thunderbolt/
>  +obj-$(CONFIG_ANDROID)   += android/
> + obj-$(CONFIG_CORESIGHT) += coresight/


Looks good, 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/

Re: Early test: hangs in mm/compact.c w. Linus's 12d7aacab56e9ef185c

[Joonsoo Kim]

On Sat, Nov 08, 2014 at 11:18:37PM +0100, Vlastimil Babka wrote:
> On 11/08/2014 02:11 PM, P. Christeas wrote:
> > On Thursday 06 November 2014, Vlastimil Babka wrote:
> >>> On Wednesday 05 November 2014, Vlastimil Babka wrote:
>  Can you please try the following patch?
>  -compaction_defer_reset(zone, order, false);
> >> Oh and did I ask in this thread for /proc/zoneinfo yet? :)
> > 
> > Using that same kernel[1], got again into a race, gathered a few more data.
> > 
> > This time, I had 1x "urpmq" process [2] hung at 100% CPU , when "kwin" got 
> > apparently blocked (100% CPU, too) trying to resize a GUI window. I suppose 
> > the resizing operation would mean heavy memory alloc/free.
> > 
> > The rest of the system was responsive, I could easily get a console, login, 
> > gather the files.. Then, I have *killed* -9 the "urpmq" process, which 
> > solved 
> > the race and my system is still alive! "kwin" is still running, returned to 
> > regular CPU load.
> > 
> > Attached is traces from SysRq+l (pressed a few times, wanted to "snapshot" 
> > the 
> > stack) and /proc/zoneinfo + /proc/vmstat
> > 
> > Bisection is not yet meaningful, IMHO, because I cannot be sure that "good" 
> > points are really free from this issue. I'd estimate that each test would 
> > take 
> > +3days, unless I really find a deterministic way to reproduce the issue .
> 
> Hi,
> 
> I think I finally found the cause by staring into the code... CCing
> people from all 4 separate threads I know about this issue.
> The problem with finding the cause was that the first report I got from
> Markus was about isolate_freepages_block() overhead, and later Norbert
> reported that reverting a patch for isolate_freepages* helped. But the
> problem seems to be that although the loop in isolate_migratepages exits
> because the scanners almost meet (they are within same pageblock), they
> don't truly meet, therefore compact_finished() decides to continue, but
> isolate_migratepages() exits immediately... boom! But indeed e14c720efdd7
> made this situation possible, as free scaner pfn can now point to a
> middle of pageblock.

Indeed.

> 
> So I hope the attached patch will fix the soft-lockup issues in
> compact_zone. Please apply on 3.18-rc3 or later without any other reverts,
> and test. It probably won't help Markus and his isolate_freepages_block()
> overhead though...

Yes, I found this bug too, but, it can't explain
isolate_freepages_block() overhead. Anyway, I can't find another bug
related to isolate_freepages_block(). :/

> Thanks,
> Vlastimil
> 
> --8<--
> >From fbf8eb0bcd2897090312e23da6a31bad9cc6b337 Mon Sep 17 00:00:00 2001
> From: Vlastimil Babka 
> Date: Sat, 8 Nov 2014 22:20:43 +0100
> Subject: [PATCH] mm, compaction: prevent endless loop in migrate scanner
> 
> ---
>  mm/compaction.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index ec74cf0..1b7a1be 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1029,8 +1029,12 @@ static isolate_migrate_t isolate_migratepages(struct 
> zone *zone,
>   }
>  
>   acct_isolated(zone, cc);
> - /* Record where migration scanner will be restarted */
> - cc->migrate_pfn = low_pfn;
> + /* 
> +  * Record where migration scanner will be restarted. If we end up in
> +  * the same pageblock as the free scanner, make the scanners fully
> +  * meet so that compact_finished() terminates compaction.
> +  */
> + cc->migrate_pfn = (end_pfn <= cc->free_pfn) ? low_pfn : cc->free_pfn;
>  
>   return cc->nr_migratepages ? ISOLATE_SUCCESS : ISOLATE_NONE;
>  }

IMHO, proper fix is not to change this logic, but, to change decision
logic in compact_finished() and in compact_zone(). Maybe helper
function would be good for readability.

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

Re: AMR: sun7i: CPU hotplug support?

[Jan Kiszka]

On 2014-11-10 00:17, Maxime Ripard wrote:
> Hi Jan,
> 
> On Sun, Nov 09, 2014 at 08:35:49PM +0100, Jan Kiszka wrote:
>> did anyone already happen to look into enabling CPU hotplug for the
>> Allwinner A20 in upstream? I'm currently running the sunxi-next branch
>> on Banana Pi, and echo 0 > .../cpu1/online just hangs the system. The
>> old 3.4 LeMaker kernel works fine in this regard. I can try to look into
>> details and port things over, just want to avoid duplicate efforts.
> 
> Having hotplug support would indeed be very welcome.
> 
> However, it should be done in u-boot, through PSCI, and not in the
> kernel itself.
> 
> As far as I'm aware, no one worked actively on it, beside some WIP
> commit from Marc a while ago:
> https://git.kernel.org/cgit/linux/kernel/git/maz/u-boot.git/commit/?h=wip/psci&id=45379c0f9cf812f0f62722f4015ec907fa5dc144

OK - I guess I will need a little guidance in then: Is there a good
reference board to study and to derive from? And maybe also: What is
missing or not working in that u-boot branch? If I get this interface
right, I just takes some device tree bits to enable this for the kernel
afterward, correct?

Thanks,
Jan

PS: That the GMAC on B-Pi has some TX reliability issues, both with
kernel and u-boot, is known, right? If not, I'll open a separate thread.



signature.asc
Description: OpenPGP digital signature

[PATCH 2/2] ARM: multi_v7_defconfig: Enable Broadcom Cygnus

[Scott Branden]

From: Ray Jui 

Enable Broadcom Cygnus platform support in multi_v7_defconfig

Signed-off-by: Ray Jui 
Signed-off-by: Scott Branden 
---
 arch/arm/configs/multi_v7_defconfig | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index e8f79fd..f3ef3f5 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -17,6 +17,7 @@ CONFIG_MACH_ARMADA_38X=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_MACH_DOVE=y
 CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BCM_CYGNUS=y
 CONFIG_ARCH_BCM_21664=y
 CONFIG_ARCH_BCM_281XX=y
 CONFIG_ARCH_BCM_5301X=y
@@ -125,8 +126,12 @@ CONFIG_DMA_CMA=y
 CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_OMAP_OCP2SCP=y
 CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
 CONFIG_MTD_M25P80=y
+CONFIG_MTD_NAND=y
 CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_AD525X_DPOT=y
 CONFIG_AD525X_DPOT_I2C=y
@@ -161,6 +166,7 @@ CONFIG_TI_CPSW=y
 CONFIG_XILINX_EMACLITE=y
 CONFIG_AT803X_PHY=y
 CONFIG_MARVELL_PHY=y
+CONFIG_BROADCOM_PHY=y
 CONFIG_ICPLUS_PHY=y
 CONFIG_USB_PEGASUS=y
 CONFIG_USB_USBNET=y
@@ -234,6 +240,7 @@ CONFIG_SPI_TEGRA114=y
 CONFIG_SPI_TEGRA20_SFLASH=y
 CONFIG_SPI_TEGRA20_SLINK=y
 CONFIG_SPI_XILINX=y
+CONFIG_SPI_SPIDEV=y
 CONFIG_PINCTRL_AS3722=y
 CONFIG_PINCTRL_PALMAS=y
 CONFIG_GPIO_SYSFS=y
@@ -260,6 +267,7 @@ CONFIG_ST_THERMAL_SYSCFG=y
 CONFIG_ST_THERMAL_MEMMAP=y
 CONFIG_WATCHDOG=y
 CONFIG_XILINX_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
 CONFIG_ORION_WATCHDOG=y
 CONFIG_SUNXI_WATCHDOG=y
 CONFIG_MFD_AS3722=y
@@ -306,6 +314,8 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_SOUND=y
 CONFIG_SND=y
+CONFIG_SND_DYNAMIC_MINORS=y
+CONFIG_SND_USB_AUDIO=y
 CONFIG_SND_SOC=y
 CONFIG_SND_SOC_TEGRA=y
 CONFIG_SND_SOC_TEGRA_RT5640=y
@@ -427,7 +437,12 @@ CONFIG_TI_PIPE3=y
 CONFIG_PHY_MIPHY365X=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_EXT4_FS=y
+CONFIG_AUTOFS4_FS=y
+CONFIG_MSDOS_FS=y
 CONFIG_VFAT_FS=y
+CONFIG_NTFS_FS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_UBIFS_FS=y
 CONFIG_TMPFS=y
 CONFIG_SQUASHFS=y
 CONFIG_SQUASHFS_LZO=y
@@ -436,6 +451,9 @@ CONFIG_NFS_FS=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
 CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_MAGIC_SYSRQ=y
-- 
2.1.3

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

[PATCH 1/2] ARM: multi_v7_defconfig: remove one level of menu from Kconfig

[Scott Branden]

remove menu "Broadcom Mobile SoC Selection"
This requires:
- selecting ARCH_BCM_MOBILE based on SoC selections
- fixup multi_v7_defconfig to work with new menu levels of mach-bcm.

Signed-off-by: Scott Branden 
---
 arch/arm/configs/multi_v7_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 491b7d5..e8f79fd 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -17,7 +17,8 @@ CONFIG_MACH_ARMADA_38X=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_MACH_DOVE=y
 CONFIG_ARCH_BCM=y
-CONFIG_ARCH_BCM_MOBILE=y
+CONFIG_ARCH_BCM_21664=y
+CONFIG_ARCH_BCM_281XX=y
 CONFIG_ARCH_BCM_5301X=y
 CONFIG_ARCH_BRCMSTB=y
 CONFIG_ARCH_BERLIN=y
-- 
2.1.3

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

[LKP] [sched] 9597d64116d: -16.1% hackbench.throughput

[lkp]

FYI, we noticed the below changes on

https://git.linaro.org/people/mturquette/linux.git eas-next
commit 9597d64116d0d441dea32e7f5f05fa135d16f44b ("sched: replace 
capacity_factor by usage")


b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  testbox/testcase/testparams
  --  ---
 %stddev %change %stddev
 \  |\  
104249 ±  0% -16.1%  87436 ±  0%  
ivb42/hackbench/performance-50%-threads-socket
104249   -16.1%  87436GEO-MEAN hackbench.throughput

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
  0.88 ± 25%+209.7%   2.74 ±  5%  
ivb42/hackbench/performance-50%-threads-socket
  0.88  +209.7%   2.74GEO-MEAN 
perf-profile.cpu-cycles.ttwu_do_activate.constprop.87.sched_ttwu_pending.scheduler_ipi.smp_reschedule_interrupt.reschedule_interrupt

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
  0.76 ± 26%+209.2%   2.36 ±  5%  
ivb42/hackbench/performance-50%-threads-socket
  0.76  +209.2%   2.36GEO-MEAN 
perf-profile.cpu-cycles.activate_task.ttwu_do_activate.sched_ttwu_pending.scheduler_ipi.smp_reschedule_interrupt

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
  0.76 ± 26%+210.6%   2.35 ±  5%  
ivb42/hackbench/performance-50%-threads-socket
  0.76  +210.6%   2.35GEO-MEAN 
perf-profile.cpu-cycles.enqueue_task.activate_task.ttwu_do_activate.sched_ttwu_pending.scheduler_ipi

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
  0.70 ± 25%+203.1%   2.13 ±  6%  
ivb42/hackbench/performance-50%-threads-socket
  0.70  +203.1%   2.13GEO-MEAN 
perf-profile.cpu-cycles.enqueue_task_fair.enqueue_task.activate_task.ttwu_do_activate.sched_ttwu_pending

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
243252 ± 46%+242.5% 833240 ± 42%  
ivb42/hackbench/performance-50%-threads-socket
243252  +242.5% 833240GEO-MEAN 
sched_debug.cfs_rq[2]:/.spread0

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
98 ± 36% -49.1% 50 ± 34%  
ivb42/hackbench/performance-50%-threads-socket
98   -49.1% 50GEO-MEAN 
sched_debug.cfs_rq[18]:/.blocked_load_avg

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
   1067752 ± 25% +65.3%1764542 ± 11%  
ivb42/hackbench/performance-50%-threads-socket
   1067752   +65.3%1764542GEO-MEAN 
sched_debug.cfs_rq[16]:/.spread0

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
923375 ± 22% +96.3%1812750 ± 21%  
ivb42/hackbench/performance-50%-threads-socket
923375   +96.3%1812750GEO-MEAN 
sched_debug.cfs_rq[14]:/.spread0

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
   1008818 ± 20% +70.9%1724167 ± 14%  
ivb42/hackbench/performance-50%-threads-socket
   1008818   +70.9%1724167GEO-MEAN 
sched_debug.cfs_rq[6]:/.spread0

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
   1109100 ± 25% +53.9%1707190 ± 16%  
ivb42/hackbench/performance-50%-threads-socket
   1109100   +53.9%1707190GEO-MEAN 
sched_debug.cfs_rq[15]:/.spread0

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
   1006499 ± 33% +67.8%1688436 ± 22%  
ivb42/hackbench/performance-50%-threads-socket
   1006499   +67.8%1688436GEO-MEAN 
sched_debug.cfs_rq[13]:/.spread0

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
915637 ± 16% +93.4%1771080 ± 18%  
ivb42/hackbench/performance-50%-threads-socket
915637   +93.4%1771080GEO-MEAN 
sched_debug.cfs_rq[7]:/.spread0

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
783024 ± 10% +67.2%1309563 ± 22%  
ivb42/hackbench/performance-50%-threads-socket
783024   +67.2%1309563GEO-MEAN 
sched_debug.cfs_rq[5]:/.spread0

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
 16155 ±  3% +66.8%  26952 ±  3%  
ivb42/hackbench/performance-50%-threads-socket
 16155   +66.8%  26952GEO-MEAN 
proc-vmstat.numa_pages_migrated

b57a1e0afff2cbac  9597d64116d0d441dea32e7f5f  
  --  
 16155 ±  3% +66.8%  26952 ±  3%  
ivb42/hackbench/performance-50%-threads-

linux-next: manual merge of the char-misc tree with the staging tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in
drivers/Makefile between commit 83e0abae ("staging: android:
binder: move to the "real" part of the kernel") from the staging tree and
commit a06ae8609b3d ("coresight: add CoreSight core layer framework")
from the char-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/Makefile
index 60d19820a4d4,628b512b625b..
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@@ -161,4 -161,4 +161,5 @@@ obj-$(CONFIG_POWERCAP) += powercap
  obj-$(CONFIG_MCB) += mcb/
  obj-$(CONFIG_RAS) += ras/
  obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
 +obj-$(CONFIG_ANDROID) += android/
+ obj-$(CONFIG_CORESIGHT)   += coresight/


pgpMdZBjCXdMg.pgp
Description: OpenPGP digital signature

Re: [arc-linux-dev] Re: ARC backport for stable 3.14

[Vineet Gupta]

On Monday 10 November 2014 08:55 AM, Greg Kroah-Hartman wrote:
> On Wed, Oct 15, 2014 at 09:26:55AM +, Vineet Gupta wrote:
>> Hi,
>>
>> Can you please apply the following mainline commits to 3.14 stable (in the 
>> order below)
>>
>> c3441edd2dea ARC: [SMP] General Fixes
> That commit doesn't have a signed-off-by:, what happened?

Not sure how I missed that in first place ?

>
>> d75386363ee6 ARC: fix mmuv2 warning
>> ef680cdc2437 ARC: Disable caches in early boot if so configured
>>
>> Build/run tested on 3.14
> All applied now, 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/

[RFC 1/2] sched/fair: Add cumulative average of load_avg_contrib to a task

[Shilpasri G Bhat]

This patch aims to identify a suitable metric which can define
the nature of the task as CPU intensive or non-intensive. This
metric's value will be used to optimize the logic to scale CPU
frequency during an idle wakeup scenario i.e., to make the cpufreq
governor to scale the frequency optimized for workloads.

Given the properties of 'load_avg_contrib' of a task's sched entity,
it forms a potential candidate for frequency scaling. By the virtue of
its design this metric picks up the load slowly during an idle wakeup.
So at that instant of wakeup we cannot account on the latest value of
this metric as it is unreliable. This can be seen in the test results
below.

I ran a modified version of ebizzy which sleeps in between its
execution such that its utilization can be user defined value. The
below trace was observed for a single thread ebizzy run for a 40%
utilization.

T1 ebizzy   309.613862: .__update_entity_load_avg_contrib: ebizzy 
load_avg_contrib=1022
T2 ebizzy   309.613864: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8
T3310.062932: .__update_entity_load_avg_contrib: ebizzy 
load_avg_contrib=0
T4310.062936: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy
T5 ebizzy   310.063104: .__update_entity_load_avg_contrib: ebizzy 
load_avg_contrib=67
T6 ebizzy   310.063106: .__update_entity_load_avg_contrib: kworker/8:1 
load_avg_contrib=0
T7 ebizzy   310.063108: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:1

At 309.613862 the 'load_avg_contrib' value of ebizzy is equal to 1022
which indicates its high utilization. It goes to sleep at 309.613864.
After a long idle peroid ebizzy wakes up at 310.062932. Once a cpu
wakes up from an idle state all the timers that were deferred on that
cpu will be fired. The cpufreq governor's timer is one such deferred
timer which gets fired consequently after ebizzy wakes up. On next
context_switch at 310.063104 we can see that load_avg_contrib's value
gets updated to 67. Further at 310.063108 the cpufreq governor gets
switched in to calculate the load, now if it were to consider ebizzy's
'load_avg_contrib' value then we will not benefit as the recent value
is far less compared to the value ebizzy had before going to sleep.

We can hide these fluctuations of 'load_avg_contrib' by calculating
the average of all the values of 'load_avg_contrib'. The cumulative
average of 'load_avg_contrib' will always preserve the long-term
behavior of the task. Thus using the cumulative average of
'load_avg_contrib' we can scale the cpu frequency as best suited for
the task.

'load_avg_contrib' of ebizzy is updated at T1, T3 and T5. So in
a period from T1-T7 ebizzy has the following values :
load_avg_contribcumulative_average
T1  10221022/1= 1022
T3  0   (1022+0)/2= 511
T5  67  (1022+0+67)/3 = 363

At T5 the cumulative_average is 363 which is better than the
load_avg_contrib value 67 when used to decide the nature of the task.
Thus we can use cumulative_average to scale the cpu frequency during
an idle wakeup.

Signed-off-by: Shilpasri G Bhat 
Suggested-by: Preeti U Murthy 
---
 include/linux/sched.h |  4 
 kernel/sched/core.c   | 35 +++
 kernel/sched/fair.c   |  6 +-
 kernel/sched/sched.h  |  2 +-
 4 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5e344bb..212a0a7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1081,6 +1081,8 @@ struct sched_avg {
u64 last_runnable_update;
s64 decay_count;
unsigned long load_avg_contrib;
+   unsigned long cumulative_avg;
+   unsigned long cumulative_avg_count;
 };
 
 #ifdef CONFIG_SCHEDSTATS
@@ -3032,3 +3034,5 @@ static inline unsigned long rlimit_max(unsigned int limit)
 }
 
 #endif
+
+extern unsigned int task_cumulative_load(int cpu);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4499950..b3d0d5a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2853,6 +2853,7 @@ need_resched:
if (likely(prev != next)) {
rq->nr_switches++;
rq->curr = next;
+   rq->prev = prev;
++*switch_count;
 
context_switch(rq, prev, next); /* unlocks the rq */
@@ -8219,3 +8220,37 @@ void dump_cpu_task(int cpu)
pr_info("Task dump for CPU %d:\n", cpu);
sched_show_task(cpu_curr(cpu));
 }
+
+/**
+ * task_cumulative_load - return the cumulative load of
+ * the previous task if cpu is the current cpu OR the
+ * cumulative load of current task on the cpu. If cpu
+ * is idle then return 0.
+ *
+ * Invoked by the cpufreq governor to calculate the
+ * load when the CPU is woken from an idle state.
+ *
+ */
+unsigned int task_cumulative_load(int cpu)
+{
+   struct rq *rq = cpu_rq(cpu);
+   struct task_struct *p;
+
+   if (cpu == smp_processor_id()) {
+   if (rq->pre

[RFC 2/2] cpufreq: governor: CPU frequency scaled from task's cumulative-load on an idle wakeup

[Shilpasri G Bhat]

"18b46a cpufreq: governor: Be friendly towards latency-sensitive
bursty workloads" patch by Srivatsa tried to solve a problem in
cpufreq governor's CPU load calculation logic. The fix is to detect
wakeup from cpuidle scenario and to start the workload at reasonably
high frequency and thus avoiding the redundant step to bring down
the frequency when a task wakes up on an idle CPU.

This logic used the 'previous load' as the CPU load for the alternate
wakeup-from-cpuidle and not newly calculating the load. The issue is
that sometimes the 'previous load' which is meant to help certain
latency sensitive tasks can get used by some kworker or similar task
to its advantage if it woke up first on the cpu. This will deprive
important tasks of high cpu frequency thus replicating the issue that
we set out to solve. Also if the bursty workloads were in a constant
migration of cpus then they will be deprived from running at high
frequency on every wakeup-on-idle-cpu scenarios. This is explained
below:

   Time(ms) Events on CPU

   100  Task A is running on CPU

   110  Governor's timer fires and calculates CPU load:
load=100 prev_load=100. It marks the high load
and increases the CPU frequency

   110.5Task A is running

   118  Task A went to sleep and CPU became idle

   140  Task B starts to run

   141  Governor's deferred timer fires and calculates CPU load.
It notices the long idle period and uses the prev_load
as the current CPU load. load=100 prev_load=0. It
increases the CPU frequency as it sees the high load.

   141.5Task B is running

   142  Task B went to sleep and CPU became idle

   174  Task A woke up and started running again

   175  Governor's deferred timer fires and calculates CPU load.
load=3 prev_load=3. Even though it is a long idle
period the CPU load is freshly calculated as the
prev_load is copied for alternate wake_ups. The
governor decides to decrease the frequency as it
notices low load.

At 175ms governor decreases the CPU frequency as it freshly calculates
the load. So Task A is deprived from running at high frequency for the
next 10ms of its execution until the governor's timer fires again to
compute the load. This happened because Task B woke up first on the
CPU consuming the prev_load.

Considering latency sensitive bursty workloads like Task A and short
bursty housekeeping kernel functions like Task B; Task A will surely
fall short of chances of running at high frequency on its wakeup if
Task B continues to pop up in this fashion.

If the governor was aware of the history of the incoming task it could
make decisions more appropriately to scale the CPU frequency.
So instead of cpu load use a task's cumulative-load to calculate the
load on every wakeup from idle state. The cumulative-load of task will
explain the nature of the task's cpu utilization. But we cannot directly
map cumulative-load to scale cpu frequency. Because the current
cpufreq governor logic is implemented keeping cpu load in mind. This
logic intends to increase the CPU frequency if the task's cumulative
load is above a threshold limit.

Signed-off-by: Shilpasri G Bhat 
Suggested-by: Preeti U Murthy 
---
 drivers/cpufreq/cpufreq_governor.c | 39 +++---
 drivers/cpufreq/cpufreq_governor.h |  9 ++---
 2 files changed, 17 insertions(+), 31 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index 1b44496..de4896c 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cpufreq_governor.h"
 
@@ -119,37 +120,29 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
 * actually is. This is undesirable for latency-sensitive bursty
 * workloads.
 *
-* To avoid this, we reuse the 'load' from the previous
-* time-window and give this task a chance to start with a
-* reasonably high CPU frequency. (However, we shouldn't over-do
-* this copy, lest we get stuck at a high load (high frequency)
-* for too long, even when the current system load has actually
-* dropped down. So we perform the copy only once, upon the
-* first wake-up from idle.)
+* To avoid this, we use the task's cumulative load which woke
+* up the idle CPU to suitably scale the CPU frequency. For a
+* sibling CPU we use the cumulative load of the current task on
+* that CPU.
+*
+* A task is considered to be CPU intensive if its cumulative
+* load is greater th

[RFC 0/2] CPU frequency scaled from a task's load on an idle wakeup

[Shilpasri G Bhat]

This patch set aims to solve a problem in cpufreq governor's CPU
load calculation logic when the CPU wakes up after an idle period.
In the current logic when a CPU wakes up from an idle state the
'previous load' of the CPU is used as its current load on the
alternate wakeups.

A latency-sensitive-bursty task will be benefited from this logic if
it wakes up on a CPU on which it was initially running, with a
non-compromised CPU 'previous load' i.e, the 'previous load' holds
the last calculated CPU load before the task went to sleep. In such
a case, the cpufreq governor will account to high previous CPU load
and decides to run at high frequency.

The problem in this logic is that the 'previous load' which is meant
to help certain latency-sensitive-bursty tasks can get used by some
periodic-small tasks(like kernel daemons) to its advantage if the
small task woke up first on the CPU. This will deprive the the
latency-sensitive-bursty tasks from running at high frequency until
the cpufreq governor notices the 100% CPU utilization. If this pattern
gets repeated in the due course of bursty task's execution we will
land on the same problem which 'prev_load' had originally set forth to 
solve.

Probably we could reduce these inefficiencies if the cpufreq
governor was aware of the task's nature, while calculating the load
during an idle-wakeup scenario. So instead of using the previous
load for the CPU , the load can be deduced on the basis of incoming
task's load.

In this patch we use a metric built on top of 'load_avg_contrib'.
'load_avg_contrib' of a task's sched entity can describe the nature
of the task in terms of its CPU utilization. The properties of this
metric to encapsulate the CPU utilization of a task makes it a
potential candidate for scaling CPU frequency. However, due to the
nature of its design 'load_avg_contrib' cannot pick up the task's
load rapidly after a wakeup. As we are trying to solve the problem
on idle-wakeup case we cannot use this metric value as is to scale
the frequency. So we measure the cumulative moving average of
'load_avg_contrib'.

The cumulative average of 'load_avg_contrib' at a given point is the
average of all the values of 'load_avg_contrib' up until that point.
The current average of a new 'load_avg_contrib' value is as below:

Cumulative_average(n+1) = x(n+1) + Cumulative_average(n) * n
---
n+1
where,
Cumulative_average(n+1) is the current cumulative average
x(n+1) is the latest 'load_avg_contrib' value
Cumulative_average(n) is the previous cumulative average
n+1 is the number of 'load_avg_contrib' values so far

The cumulative average of 'load_avg_contrib' will help us smooth out
the short-term fluctuations and highlight long-term trend of
'load-avg_contrib' metric. So cumulative average of the task can
depict the nature of the task more effectively. Thus we can scale CPU
frequency based on the cumulative average of the task and make
calculative decisions whether to decrease or increase the frequency
depending on the nature of the task.

Shilpasri G Bhat (2):
  sched/fair: Add cumulative average of load_avg_contrib to a task
  cpufreq: governor: CPU frequency scaled from task's cumulative-load on
an idle wakeup

 drivers/cpufreq/cpufreq_governor.c | 39 +++---
 drivers/cpufreq/cpufreq_governor.h |  9 ++---
 include/linux/sched.h  |  4 
 kernel/sched/core.c| 35 ++
 kernel/sched/fair.c|  6 +-
 kernel/sched/sched.h   |  2 +-
 6 files changed, 62 insertions(+), 33 deletions(-)

-- 
1.9.3

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

Re: [PATCH 5/5] Documentation: Add documentation for rt5033 multifunction device

[Beomho Seo]

Thank you for your advice.
I'll fix them and send v2 patch soon.

On 11/07/2014 07:34 PM, Mark Brown wrote:
> On Fri, Nov 07, 2014 at 11:52:07AM +0900, Beomho Seo wrote:
> 
>> +Required properties:
>> +- compatible = Must be "richtek,rt5033-regulator"
>> +
>> +regulators {
>> +compatible = "richtek,rt5033-regulator";
> 
> There should be no need for this extra compatible, it's not adding
> anything we didn't know from the fact that it's part of the MFD.
> 
>> +regulator-name {
>> +regulator-name = LDO/BUCK
>> +standard regulator constraints...
>> +};
> 
> Better to just say something like "regulator subnodes called X, Y and Z"
> described using the standard regulator binding in...
> 

Best regards,
Beomho Seo
--
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/

[LKP] [sunrpc] WARNING: CPU: 1 PID: 1890 at lib/list_debug.c:36 __list_add+0xcb/0xd0()

[lkp]

FYI, we noticed a wraning changes on

git://git.samba.org/jlayton/linux svc-pool-lock
commit 3a41085d37f2374f6ae6539f5dca3d1d53e50431 ("sunrpc: search for a thread 
under RCU")

<5>[   21.635477] Key type id_legacy registered
<4>[   21.638149] [ cut here ]
<4>[   21.638359] [ cut here ]
<4>[   21.638363] WARNING: CPU: 1 PID: 1890 at lib/list_debug.c:36 
__list_add+0xcb/0xd0()
<4>[   21.638364] list_add double add: new=88007be38000, 
prev=88007e835088, next=88007be38000.
<4>[   21.638376] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfsd 
auth_rpcgss ipmi_watchdog ipmi_msghandler sg sr_mod sd_mod cdrom ata_generic 
pata_acpi mxm_wmi pcspkr pata_marvell serio_raw firewire_ohci firewire_core 
ahci libahci crc_itu_t i2c_i801 libata parport_pc winbond_cir parport rc_core 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel 
snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer snd wmi 
i7core_edac soundcore edac_core acpi_cpufreq
<4>[   21.638377] CPU: 1 PID: 1890 Comm: nfsv4.0-svc Tainted: G  I
3.18.0-rc3-ga798bc5 #1
<4>[   21.638378] Hardware name:  /DX58SO, BIOS 
SOX5810J.86A.4196.2009.0715.1958 07/15/2009
<4>[   21.638380]  0009 88007bd03d48 8188f71f 
25a825a8
<4>[   21.638381]  88007bd03d98 88007bd03d88 8106b3c1 
8800bf7c1b00
<4>[   21.638381]  88007be38000 88007be38000 88007e835088 
88007e835098
<4>[   21.638382] Call Trace:
<4>[   21.638385]  [] dump_stack+0x4e/0x68
<4>[   21.638388]  [] warn_slowpath_common+0x81/0xa0
<4>[   21.638389]  [] warn_slowpath_fmt+0x46/0x50
<4>[   21.638390]  [] __list_add+0xcb/0xd0
<4>[   21.638392]  [] svc_recv+0x69a/0xa30
<4>[   21.638399]  [] ? nfs_callback_authenticate+0x50/0x50 
[nfsv4]
<4>[   21.638406]  [] ? nfs_callback_authenticate+0x50/0x50 
[nfsv4]
<4>[   21.638412]  [] nfs4_callback_svc+0x3b/0x60 [nfsv4]
<4>[   21.638414]  [] kthread+0xdb/0x100
<4>[   21.638415]  [] ? kthread_create_on_node+0x180/0x180
<4>[   21.638417]  [] ret_from_fork+0x7c/0xb0
<4>[   21.638418]  [] ? kthread_create_on_node+0x180/0x180
<4>[   21.638419] ---[ end trace a8ecfce57c7c54ab ]---
<4>[   21.646613] WARNING: CPU: 2 PID: 1876 at lib/list_debug.c:36 
__list_add+0xcb/0xd0()
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.18.0-rc3-ga798bc5 (kbuild@cairo) (gcc version 
4.9.1 (Debian 4.9.1-19) ) #1 SMP Fri Nov 7 06:36:39 CST 2014
[0.00] Command line: 
BOOT_IMAGE=/kernel/x86_64-rhel/a798bc55fde3928d93b1624b6f40382446e8ccc4/vmlinuz-3.18.0-rc3-ga798bc5
 user=lkp 
job=/lkp/scheduled/nhm4/cyclic_fsmark-performance-1x-32t-1HDD-xfs-nfsv4-8K-400M-fsyncBeforeClose-16d-256fpd-x86_64-rhel-HEAD-a798bc55fde3928d93b1624b6f40382446e8ccc4-0.yaml
 ARCH=x86_64 
BOOT_IMAGE=/kernel/x86_64-rhel/a798bc55fde3928d93b1624b6f40382446e8ccc4/vmlinuz-3.18.0-rc3-ga798bc5
 kconfig=x86_64-rhel commit=a798bc55fde3928d93b1624b6f40382446e8ccc4 
branch=linux-devel/devel-hourly-2014110706 root=/dev/ram0 max_uptime=3600 
RESULT_ROOT=/result/nhm4/fsmark/performance-1x-32t-1HDD-xfs-nfsv4-8K-400M-fsyncBeforeClose-16d-256fpd/debian-x86_64.cgz/x86_64-rhel/a798bc55fde3928d93b1624b6f40382446e8ccc4/0
 ip=nhm4::dhcp libata.force=1.5Gbps earlyprintk=ttyS0,115200 debug 
apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga<6>
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x0100-0x0008efff] usable
[0.00] BIOS-e820: [mem 0x0008f000-0x0008] reserved
[0.00] BIOS-e820: [mem 0x0009-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbcadafff] usable
[0.00] BIOS-e820: [mem 0xbcadb000-0xbcd2bfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbcd2c000-0xbf6bcfff] usable
[0.00] BIOS-e820: [mem 0xbf6bd000-0xbf6befff] reserved
[0.00] BIOS-e820: [mem 0xbf6bf000-0xbf713fff] usable
[0.00] BIOS-e820: [mem 0xbf714000-0xbf7befff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf7bf000-0xbf7e5fff] usable
[0.00] BIOS-e820: [mem 0xbf7e6000-0xbf7fefff] ACPI data
[0.00] BIOS-e820: [mem 0xbf7ff000-0xbf7f] usable
[0.00] BIOS-e820: [mem 0xbf80-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfcff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] bootconsole [earlyser0]

[no subject]

[3.5% WONGA LOANS OFFER]

3.5% WONGA LOANS OFFER.pdf
Description: Adobe PDF document

[LKP] [x86, irq] BUG: kernel boot hang

[lkp]

FYI, we noticed the below changes on

https://github.com/jiangliu/linux.git irqdomain/p4v1
commit e530b4be849e7c865c95f25008eb52b72ec96341 ("x86, irq: Use cached IOAPIC 
entry instead of reading from hardware")


+--+++
|  | ff34368973 | e530b4be84 |
+--+++
| boot_successes   | 10 | 1  |
| boot_failures| 0  | 14 |
| BUG:kernel_boot_hang | 0  | 14 |
+--+++


[  302.136037] Waiting up to 20 more seconds for network.
[  312.136042] Waiting up to 10 more seconds for network.

BUG: kernel boot hang
Elapsed time: 310
qemu-system-x86_64 -enable-kvm -cpu Westmere -kernel 
/kernel/x86_64-lkp/dfc6ac916357d686ca861cb0a996ed85413d5d00/vmlinuz-3.18.0-rc3-00128-gdfc6ac9
 -append 'user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-ia32-31/rand_boot-1-yocto-minimal-i386.cgz-x86_64-lkp-dfc6ac916357d686ca861cb0a996ed85413d5d00-1.yaml
 ARCH=x86_64 
BOOT_IMAGE=/kernel/x86_64-lkp/dfc6ac916357d686ca861cb0a996ed85413d5d00/vmlinuz-3.18.0-rc3-00128-gdfc6ac9
 kconfig=x86_64-lkp commit=dfc6ac916357d686ca861cb0a996ed85413d5d00 
branch=linux-devel/devel-roam-lkp-201411081809 root=/dev/ram0 max_uptime=3600 
RESULT_ROOT=/result/vm-kbuild-yocto-ia32/boot/1/yocto-minimal-i386.cgz/x86_64-lkp/dfc6ac916357d686ca861cb0a996ed85413d5d00/0
 ip=vm-kbuild-yocto-ia32-31::dhcp earlyprintk=ttyS0,115200 debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
drbd.minor_count=8'  -initrd /fs/sdh1/initrd-vm-kbuild-yocto-ia32-31 -m 320 
-smp 1 -net nic,vlan=1,model=e1000 -net user,vlan=1 -boot order=nc -no-reboot 
-watchdog i6300esb -rtc base=localtime -drive 
file=/fs/sdh1/disk0-vm-kbuild-yocto-ia32-31,media=disk,if=virtio -pidfile 
/dev/shm/kboot/pid-vm-kbuild-yocto-ia32-31 -serial 
file:/dev/shm/kboot/serial-vm-kbuild-yocto-ia32-31 -daemonize -display none 
-monitor null 

Thanks,
Fengguang
early console in setup code
Probing EDD (edd=off to disable)... ok
early console in decompress_kernel

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.18.0-rc3-00128-gdfc6ac9 (kbuild@roam) (gcc 
version 4.9.1 (Debian 4.9.1-19) ) #41 SMP Sat Nov 8 18:13:44 CST 2014
[0.00] Command line: user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-ia32-31/rand_boot-1-yocto-minimal-i386.cgz-x86_64-lkp-dfc6ac916357d686ca861cb0a996ed85413d5d00-1.yaml
 ARCH=x86_64 
BOOT_IMAGE=/kernel/x86_64-lkp/dfc6ac916357d686ca861cb0a996ed85413d5d00/vmlinuz-3.18.0-rc3-00128-gdfc6ac9
 kconfig=x86_64-lkp commit=dfc6ac916357d686ca861cb0a996ed85413d5d00 
branch=linux-devel/devel-roam-lkp-201411081809 root=/dev/ram0 max_uptime=3600 
RESULT_ROOT=/result/vm-kbuild-yocto-ia32/boot/1/yocto-minimal-i386.cgz/x86_64-lkp/dfc6ac916357d686ca861cb0a996ed85413d5d00/0
 ip=vm-kbuild-yocto-ia32-31::dhcp earlyprintk=ttyS0,115200 debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
drbd.minor_count=8
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x13ffdfff] usable
[0.00] BIOS-e820: [mem 0x13ffe000-0x13ff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] bootconsole [earlyser0] enabled
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
[0.00] Hypervisor detected: KVM
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x13ffe max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 008000 mask FF8000 uncachable
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   

Re: linux-next: manual merge of the driver-core tree with the sound-asoc tree

[Greg KH]

On Mon, Nov 10, 2014 at 03:51:42PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Mon, 10 Nov 2014 13:38:53 +0900 Greg KH  wrote:
> >
> > On Mon, Nov 10, 2014 at 03:31:32PM +1100, Stephen Rothwell wrote:
> > > 
> > > Today's linux-next merge of the driver-core tree got a conflict in
> > > sound/soc/intel/sst-haswell-pcm.c between commit 2e4f75919e5a ("ASoC:
> > > Intel: Add PM support to HSW/BDW PCM driver") from the sound-asoc tree
> > > and commit 3c1af8802e45 ("ASoC: intel: drop owner assignment from
> > > platform_drivers") from the driver-core tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> > > 
> > > -- 
> > > Cheers,
> > > Stephen Rothwells...@canb.auug.org.au
> > > 
> > > diff --cc sound/soc/intel/sst-haswell-pcm.c
> > > index 7eb9afc9b33d,ad21e636edc6..
> > > --- a/sound/soc/intel/sst-haswell-pcm.c
> > > +++ b/sound/soc/intel/sst-haswell-pcm.c
> > > @@@ -1173,9 -899,6 +1173,8 @@@ static const struct dev_pm_ops hsw_pcm_
> > >   static struct platform_driver hsw_pcm_driver = {
> > >   .driver = {
> > >   .name = "haswell-pcm-audio",
> > > - .owner = THIS_MODULE,
> > >  +.pm = &hsw_pcm_pm,
> > >  +
> > >   },
> > >   
> > >   .probe = hsw_pcm_dev_probe,
> > 
> > 
> > Fix looks good, thanks.
> 
> I assume that there was a good reason not to farm these patches out to
> their respective maintainers?

Yes, It was easier to hit everything in one tree, at one time, so that
is what Wolfram did.  Sorry for the merge conflicts, I didn't think
anyone would be adding .driver attributes to files after they had been
added to the tree.

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/

Re: linux-next: manual merge of the tty tree with the tty.current tree

[Greg KH]

On Mon, Nov 10, 2014 at 03:49:58PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the tty tree got a conflict in
> drivers/tty/serial/8250/8250_mtk.c between commit cd92208f6996 ("tty:
> serial: 8250_mtk: Fix quot calculation") from the tty.current tree and
> commit 2a768264eef0 ("tty: serial: Fix mediatek UART driver setting
> baudrate issue") from the tty tree.
> 
> I fixed it up (I just used the version from the tty tree) and can carry
> the fix as necessary (no action is required).

Thanks, I've already resolved this in the tree, so you will not need
this tomorrow.

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] AHCI: Add generic MSI-X interrupt support to SATA PCI driver

[Robert Richter]

From: Sunil Goutham 

This patch adds generic support for MSI-X interrupts to the SATA PCI
driver. Only single interrupt support is implemented. Thus, per-port
interrupts can not yet be enabled.

The driver now checks the device for the existence of MSI-X and tries
to enable the interrupt. Otherwise, if a device is not MSI-X capable,
the initialization is skipped and MSI or intx interrupts are
configured.

This patch also enables AHCI for Cavium Thunder SoCs that uses MSI-X.

Signed-off-by: Sunil Goutham 
Signed-off-by: Robert Richter 
---
 arch/arm64/Kconfig |  1 +
 drivers/ata/ahci.c | 40 +++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index ac9afde76dea..55970474d3ae 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -145,6 +145,7 @@ config ARCH_THUNDER
bool "Cavium Inc. Thunder SoC Family"
help
  This enables support for Cavium's Thunder Family of SoCs.
+   select SATA_AHCI
 
 config ARCH_VEXPRESS
bool "ARMv8 software model (Versatile Express)"
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5f039f191067..8e43ccb72c95 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -52,6 +52,7 @@
 
 enum {
AHCI_PCI_BAR_STA2X11= 0,
+   AHCI_PCI_BAR_CAVIUM = 0,
AHCI_PCI_BAR_ENMOTUS= 2,
AHCI_PCI_BAR_STANDARD   = 5,
 };
@@ -483,6 +484,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
/* Enmotus */
{ PCI_DEVICE(0x1c44, 0x8000), board_ahci },
 
+   /* Cavium */
+   { PCI_DEVICE(0x177d, 0xa01c), .driver_data = board_ahci },
+
/* Generic, PCI class code for AHCI */
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
  PCI_CLASS_STORAGE_SATA_AHCI, 0xff, board_ahci },
@@ -1188,11 +1192,43 @@ static inline void ahci_gtf_filter_workaround(struct 
ata_host *host)
 {}
 #endif
 
+static int ahci_init_msix(struct pci_dev *pdev, unsigned int n_ports,
+ struct ahci_host_priv *hpriv)
+{
+   int rc, nvec;
+   struct msix_entry entry = {};
+
+   /* check if msix is supported */
+   nvec = pci_msix_vec_count(pdev);
+   if (nvec <= 0)
+   return 0;
+
+   /* per-port msix interrupts are not supported */
+   if (n_ports > 1 && nvec >= n_ports)
+   return -ENOSYS;
+
+   /* only enable the first entry (entry.entry = 0) */
+   rc = pci_enable_msix_exact(pdev, &entry, 1);
+   if (rc < 0)
+   return rc;
+
+   pdev->irq = entry.vector;
+
+   return 1;
+}
+
 static int ahci_init_interrupts(struct pci_dev *pdev, unsigned int n_ports,
struct ahci_host_priv *hpriv)
 {
int rc, nvec;
 
+   nvec = ahci_init_msix(pdev, n_ports, hpriv);
+   if (nvec > 0)
+   return nvec;
+
+   if (nvec && nvec != -ENOSYS)
+   dev_err(&pdev->dev, "failed to enable MSI-X: %d", nvec);
+
if (hpriv->flags & AHCI_HFLAG_NO_MSI)
goto intx;
 
@@ -1271,11 +1307,13 @@ static int ahci_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
dev_info(&pdev->dev,
 "PDC42819 can only drive SATA devices with this 
driver\n");
 
-   /* Both Connext and Enmotus devices use non-standard BARs */
+   /* Some devices use non-standard BARs */
if (pdev->vendor == PCI_VENDOR_ID_STMICRO && pdev->device == 0xCC06)
ahci_pci_bar = AHCI_PCI_BAR_STA2X11;
else if (pdev->vendor == 0x1c44 && pdev->device == 0x8000)
ahci_pci_bar = AHCI_PCI_BAR_ENMOTUS;
+   else if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
+   ahci_pci_bar = AHCI_PCI_BAR_CAVIUM;
 
/*
 * The JMicron chip 361/363 contains one SATA controller and one
-- 
2.1.3

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

Re: [PATCH/RFC] workqueue: allow rescuer thread to do more work.

[NeilBrown]

On Fri, 7 Nov 2014 11:03:40 +0800 Lai Jiangshan  wrote:

> 
> 
> On 11/07/2014 12:58 AM, Dongsu Park wrote:
> > Hi Tejun & Neil,
> > 
> > On 04.11.2014 09:22, Tejun Heo wrote:
> >> On Thu, Oct 30, 2014 at 10:19:32AM +1100, NeilBrown wrote:
>    Given that workder depletion is pool-wide
>  event, maybe it'd make sense to trigger rescuers immediately while
>  workers are in short supply?  e.g. while there's a manager stuck in
>  maybe_create_worker() with the mayday timer already triggered?
> >>>
> >>> So what if I change "need_more_worker" to "need_to_create_worker" ?
> >>> Then it will stop as soon as there in an idle worker thread.
> >>> That is the condition that keeps maybe_create_worker() looping.
> >>> ??
> >>
> >> Yeah, that'd be a better condition and can work out.  Can you please
> >> write up a patch to do that and do some synthetic tests excercising
> >> the code path?  Also please cc Lai Jiangshan 
> >> when posting the patch.
> > 
> > This issue looks exactly like what I've encountered occasionally in our test
> > setup. (with a custom kernel based on 3.12, MD/raid1, dm-multipath, etc.)
> > When a system suffers from high memory pressure, and at the same time
> > underlying devices of RAID arrays are repeatedly removed and re-added,
> > then sometimes the whole system gets locked up on a worker pool's lock.
> > So I had to fix our custom MD code to allocate a separate ordered workqueue
> > with WQ_MEM_RECLAIM, apart from md_wq or md_misc_wq.
> > Then the lockup seemed to have disappeared.
> > 
> > Now that I read the Neil's patch, which looks like an ultimate solution
> > to the problem I have seen. I'm really looking forward to seeing this
> > change in mainline.
> > 
> > How about the attached patch? Based on the Neil's patch, I replaced
> > need_more_worker() with need_to_create_worker() as Tejun suggested.
> > 
> > Test is running with this patch, which seems to be working for now.
> > But I'm going to observe the test result carefully for a few more days.
> > 
> > Regards,
> > Dongsu
> > 
> > 
> >>From de9aadd6fb742ea8acce4245a27946d3f233ab7f Mon Sep 17 00:00:00 2001
> > From: Dongsu Park 
> > Date: Wed, 5 Nov 2014 17:28:07 +0100
> > Subject: [RFC PATCH] workqueue: allow rescuer thread to do more work
> > 
> > Original commit message from NeilBrown :
> > 
> > When there is serious memory pressure, all workers in a pool could be
> > blocked, and a new thread cannot be created because it requires memory
> > allocation.
> > 
> > In this situation a WQ_MEM_RECLAIM workqueue will wake up the rescuer
> > thread to do some work.
> > 
> > The rescuer will only handle requests that are already on ->worklist.
> > If max_requests is 1, that means it will handle a single request.
> > 
> > The rescuer will be woken again in 100ms to handle another max_requests
> > requests.
> 
> 
> I also observed this problem by review when I was developing
> the per-pwq-worklist patchset which has a side-affect that it also naturally
> fix the problem.
> 
> However, it is nothing about correctness and I made promise to Frederic 
> Weisbecker
> for working on unbound pool for power-saving, then the per-pwq-worklist 
> patchset
> is put off. So I have to ack it.

Thanks!
However testing showed that the patch isn't quite right.
The test on ->nr_active is not correct.  I was meaning to test "are there
any requests that have been activated but not yet serviced", but this test
only covers the first half.

If a queue allows a number of active requests (max_active > 1), and several
are blocked waiting for something (e.g. more memory), then max_active will be
positive even though there is no useful work for the rescuer thread to do -
so it will spin.

Jan Kara and I came up with a different patch which testing has shown is
quite successful.  However it makes changes to when mayday_clear_cpu() is
set, and that isn't relevant in the current kernel.

I've ported the patch to -mainline, but haven't really tested it properly
(just compile tested so far).
That version is below.

thanks,
NeilBrown


> 
> > 
> > I've seen a machine (running a 3.0 based "enterprise" kernel) with
> > thousands of requests queued for xfslogd, which has a max_requests of 1,
> > and is needed for retiring all 'xfs' write requests.  When one of the
> > worker pools gets into this state, it progresses extremely slowly and
> > possibly never recovers (only waited an hour or two).
> > 
> > So if, after handling everything on worklist, there is again something
> > on worklist (counted in nr_active), and if the queue is still congested,
> > keep processing instead of waiting for the next wake-up.
> > 
> > 
> > Dongsu Park: replaced need_more_worker() with need_to_create_worker(),
> > as suggested by Tejun.
> > 
> > Signed-off-by: Dongsu Park 
> > Link: https://lkml.org/lkml/2014/10/29/55
> > Cc: Tejun Heo 
> > Cc: Lai Jiangshan 
> > Original-by: NeilBrown 
> > Signed-off-by: NeilBrown 
> > ---
> >  kernel/work

RE: [PATCH net-next v2 2/3] r8152: cleartheflagofSCHEDULE_TASKLETintasklet

[Hayes Wang]

 Francois Romieu [mailto:rom...@fr.zoreil.com] 
> Sent: Sunday, November 09, 2014 6:12 AM
[...]
> The performance explanation leaves me a bit unconvinced. Without any
> figure one could simply go for the always locked clear_bit because of:
> 1. the "I'm racy" message that the open-coded test + set sends
> 2. the extra work needed to avoid 1 (comment, explain, ...).

Thanks. I would modify this patch with clear_bit only.

> The extra time could thus be used to see what happens when napi is
> shoehorned in this tasklet machinery. I'd naively expect it to be
> relevant for efficiency.

I thought about NAPI, but I gave up. The reasons are
1. I don't sure if it would run when autosuspending.
2. There is no hw interrupt for USB device. And I have
   no idea about how to check if the USB transfer is
   completed by polling.
3. I have to control the rx packets numbers in poll().
   However, I couldn't control the packets number for
   each bulk-in transfer. I have to do extra works to
   deal with the rx flow.
4. I don't find much different between tasklet and NAPI.

Best Regards,
Hayes
--
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/4] inet: Add skb_copy_datagram_iter

[David Miller]

From: Al Viro 
Date: Sun, 9 Nov 2014 21:19:08 +

> 1) does sparc64 access_ok() need to differ for 32bit and 64bit tasks?

sparc64 will just fault no matter what kind of task it is.

It is impossible for a user task to generate a reference to
a kernel virtual address, as kernel and user accesses each
go via a separate address space identifier.
--
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: [f2fs-dev] [PATCH 3/5] f2fs: control the memory footprint used by ino entries

[Jaegeuk Kim]

On Mon, Nov 10, 2014 at 12:28:34PM +0900, Changman Lee wrote:
> On Sat, Nov 08, 2014 at 11:36:07PM -0800, Jaegeuk Kim wrote:
> > This patch adds to control the memory footprint used by ino entries.
> > This will conduct best effort, not strictly.
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/node.c| 28 ++--
> >  fs/f2fs/node.h|  3 ++-
> >  fs/f2fs/segment.c |  3 ++-
> >  3 files changed, 26 insertions(+), 8 deletions(-)
> > 
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> > index 44b8afe..4ea2c47 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -31,22 +31,38 @@ bool available_free_memory(struct f2fs_sb_info *sbi, 
> > int type)
> >  {
> > struct f2fs_nm_info *nm_i = NM_I(sbi);
> > struct sysinfo val;
> > +   unsigned long avail_ram;
> > unsigned long mem_size = 0;
> > bool res = false;
> >  
> > si_meminfo(&val);
> > -   /* give 25%, 25%, 50% memory for each components respectively */
> > +
> > +   /* only uses low memory */
> > +   avail_ram = val.totalram - val.totalhigh;
> > +
> > +   /* give 25%, 25%, 50%, 50% memory for each components respectively */
> 
> Hi Jaegeuk,
> 
> The memory usage of nm_i should be 100% but it's 125%.
> Mistake or intended?

I contemplated whether this 100% was an exact number that we expected.
The answer was NO, since this number was just an estimated one.
There were no strict constrains to limit memory footprints even the previous
codes were used whatever 25%, 25%, and 50%.

So, here, I'd like to add additional threshold for INO_ENTRIES on a basis
of the given threshold.
In addition, I don't want to add any complex equations to satisfy 100% at all.
It's meaningless.

Thanks,

> 
> > if (type == FREE_NIDS) {
> > -   mem_size = (nm_i->fcnt * sizeof(struct free_nid)) >> 12;
> > -   res = mem_size < ((val.totalram * nm_i->ram_thresh / 100) >> 2);
> > +   mem_size = (nm_i->fcnt * sizeof(struct free_nid)) >>
> > +   PAGE_CACHE_SHIFT;
> > +   res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 2);
> > } else if (type == NAT_ENTRIES) {
> > -   mem_size = (nm_i->nat_cnt * sizeof(struct nat_entry)) >> 12;
> > -   res = mem_size < ((val.totalram * nm_i->ram_thresh / 100) >> 2);
> > +   mem_size = (nm_i->nat_cnt * sizeof(struct nat_entry)) >>
> > +   PAGE_CACHE_SHIFT;
> > +   res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 2);
> > } else if (type == DIRTY_DENTS) {
> > if (sbi->sb->s_bdi->dirty_exceeded)
> > return false;
> > mem_size = get_pages(sbi, F2FS_DIRTY_DENTS);
> > -   res = mem_size < ((val.totalram * nm_i->ram_thresh / 100) >> 1);
> > +   res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 1);
> > +   } else if (type == INO_ENTRIES) {
> > +   int i;
> > +
> > +   if (sbi->sb->s_bdi->dirty_exceeded)
> > +   return false;
> > +   for (i = 0; i <= UPDATE_INO; i++)
> > +   mem_size += (sbi->ino_num[i] * sizeof(struct ino_entry))
> > +   >> PAGE_CACHE_SHIFT;
> > +   res = mem_size < ((avail_ram * nm_i->ram_thresh / 100) >> 1);
> > }
> > return res;
> >  }
> > diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
> > index acb71e5..d10b644 100644
> > --- a/fs/f2fs/node.h
> > +++ b/fs/f2fs/node.h
> > @@ -106,7 +106,8 @@ static inline void raw_nat_from_node_info(struct 
> > f2fs_nat_entry *raw_ne,
> >  enum mem_type {
> > FREE_NIDS,  /* indicates the free nid list */
> > NAT_ENTRIES,/* indicates the cached nat entry */
> > -   DIRTY_DENTS /* indicates dirty dentry pages */
> > +   DIRTY_DENTS,/* indicates dirty dentry pages */
> > +   INO_ENTRIES,/* indicates inode entries */
> >  };
> >  
> >  struct nat_entry_set {
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index 16721b5d..e094675 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -276,7 +276,8 @@ void f2fs_balance_fs_bg(struct f2fs_sb_info *sbi)
> >  {
> > /* check the # of cached NAT entries and prefree segments */
> > if (try_to_free_nats(sbi, NAT_ENTRY_PER_BLOCK) ||
> > -   excess_prefree_segs(sbi))
> > +   excess_prefree_segs(sbi) ||
> > +   available_free_memory(sbi, INO_ENTRIES))
> > f2fs_sync_fs(sbi->sb, true);
> >  }
> >  
> > -- 
> > 2.1.1
> > 
> > 
> > --
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or

Re: [PATCH v8 4/8] ARM: dts: Enable Broadcom Cygnus SoC

[Scott Branden]

On 14-11-09 12:38 PM, Arnd Bergmann wrote:

On Sunday 09 November 2014 09:23:11 Greg Kroah-Hartman wrote:

On Sat, Nov 08, 2014 at 10:49:09PM -0800, Olof Johansson wrote:

+/*
+ * Copyright 2014 Broadcom Corporation.  All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed
to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.



We ask for new DT contents to be added with dual BSD/GPL license, to
allow for reuse of the DT data structures in other projects as well.
There's currently a lot of activity going on relicensing the current
files so I recommend sorting it out before they are added if you can.



This may take more time than you think.  I am going to have to go through
legal to get such a license created. Also, why would you need dual license?
If it is BSD that should serve both purposes?


I haven't followed the discussion close enough to know if there's been
discussion about single-license BSD vs dual BSD/GPL.


I think for all practical purposes, BSD and dual BSD/GPL is the same and
listing it as dual was meant as a clarification to make it easier to see
that all files in the kernel are GPLv2 compatible.
A dual BSD/GPL may involve having me get a lawyer to create such a 
header.  I would prefer to leave it as GPL for now until some concrete 
decision has finally been made on this by the rest of the community? 
Or, I can put it as BSD right now if that helps?



At the very least, please start the process of getting it changed.

Also, I see now that this isn't even a clean GPL v2, given "Unless you
and Broadcom..." language. I see the bnx2x driver had that in the
past, but none of the Kona contributions did. I strongly suggest
sticking to the normal copyrights here and not making things more
complicated than they have to.


I'm thinking that the "unless you and Broadcom..." language really
doesn't mean much other than what all other files in the kernel mean
from what I can tell.  This should just default to GPLv2 and everyone
should be ok.


I would hope so at least. It's certainly not obvious whether that means
Broadcom can give additional rights to someone over what someone else
contributed upstream, or worse if this becomes GPL-incompatible and
makes the kernel undistributable for anybody who has an additional
license agreement that doesn't give them all the rights that they already
had under the GPL.

I'll change the header on these files so there are no disagreements.


Arnd



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

Re: [RFC] Add of_path property for all devices with a node

[Benjamin Herrenschmidt]

On Fri, 2014-11-07 at 17:35 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2014-11-07 at 17:33 +1100, Benjamin Herrenschmidt wrote:
> 
> > So I came up with this patch, 
> 
> And here is the actual patch, which might help :-) It's pretty trivial
> and small...

So not much reactions here .. a bit more on IRC, where Olof suggested
that rather than a file containing a path, we could use a symlink since
the devtree is now in sysfs, so we can do relative links.

That means keeping the legacy "devspec" files in the few places where
they exist, possibly behind a deprecated-default-y config option (though
we might never be able to deprecate them...), but there aren't many.

Any preference either way ?

Cheers,
Ben.


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

Re: [PATCH] mmc: wmt-sdmmc: fix unmatched release_mem_region

[Alexey Charkov]

2014-11-10 1:18 GMT+03:00 lautriv :
> On 11/09/2014 10:55 PM, Fabio Estevam wrote:
>>
>> On Sun, Nov 9, 2014 at 7:12 PM, Alexey Charkov  wrote:
>>
>>> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +   if (!res) {
>>> +   ret = -ENODEV;
>>> +   goto fail1;
>>
>> You could save this NULL check...
>>
>>> +   }
>>>  mmc = mmc_alloc_host(sizeof(struct wmt_mci_priv), &pdev->dev);
>>>  if (!mmc) {
>>>  dev_err(&pdev->dev, "Failed to allocate mmc_host\n");
>>> @@ -813,7 +819,7 @@ static int wmt_mci_probe(struct platform_device
>>> *pdev)
>>>  if (of_get_property(np, "cd-inverted", NULL))
>>>  priv->cd_inverted = 1;
>>>
>>> -   priv->sdmmc_base = of_iomap(np, 0);
>>
>> If you move ' res = platform_get_resource' right here as
>> devm_ioremap_resource() already does the NULL check.
>>
>>> +   priv->sdmmc_base = devm_ioremap_resource(&pdev->dev, res);
>>>  if (!priv->sdmmc_base) {
>>>  dev_err(&pdev->dev, "Failed to map IO space\n");
>>>  ret = -ENOMEM;
>
> This was the original intention but it would fall between the failX jumps, i
> discussed that with Alexey and we decided to change it with the cleanup to
> hold this patch small.

I think Fabio means something slightly different than what we
discussed. We haven't realized that the first thing
devm_ioremap_resource does is exactly that (!res) check, so we can
skip ours altogether.

Looking at the function code a bit closer, we should also make the
check look like "if (IS_ERR(priv->sdmmc_base)", kill the dev_err call
(as it's also done internally), and then just do "ret =
PTR_ERR(priv->sdmmc_base)" and jump to the label.

Thanks a lot,
Alexey
--
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 6/6] drivers: soc: samsung: Add support for Exynos7 pmu

[amit daniel kachhap]

On Sat, Nov 8, 2014 at 11:05 PM, Pankaj Dubey  wrote:
> Hi Amit,
>
> On 8 November 2014 18:46, Amit Daniel Kachhap  wrote:
>> Add PMU settings for exynos7. This is required for future suspend-to-ram,
>> cpuidle and power domain support.
>>
>> Note: In this patch some static declarations lines are over 80
>> characters per line for easy redability.
>>
>> Reviewed-by: Pankaj Dubey 
>> Signed-off-by: Eunseok Choi 
>> Signed-off-by: Abhilash Kesavan 
>> Signed-off-by: Amit Daniel Kachhap 
>> ---
>>  .../devicetree/bindings/arm/samsung/pmu.txt|1 +
>>  drivers/soc/samsung/exynos-pmu.c   |  425 
>> 
>>  include/linux/soc/samsung/exynos-regs-pmu.h|  273 +
>>  3 files changed, 699 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt 
>> b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
>> index 1e1979b..67b2113 100644
>> --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
>> +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
>> @@ -10,6 +10,7 @@ Properties:
>>- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
>>- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
>>- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
>> +  - "samsung,exynos7-pmu" - for Exynos7 SoC.
>> second value must be always "syscon".
>>
>>   - reg : offset and length of the register set.
>> diff --git a/drivers/soc/samsung/exynos-pmu.c 
>> b/drivers/soc/samsung/exynos-pmu.c
>> index a73c1ea..9416cfd 100644
>> --- a/drivers/soc/samsung/exynos-pmu.c
>> +++ b/drivers/soc/samsung/exynos-pmu.c
>> @@ -11,6 +11,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -46,6 +47,7 @@ struct exynos_pmu_context {
>>
>>  static void __iomem *pmu_base_addr;
>>  static struct exynos_pmu_context *pmu_context;
>> +extern u32 exynos_get_eint_wake_mask(void);
>>
>>  static inline void pmu_raw_writel(u32 val, u32 offset)
>>  {
>> @@ -356,6 +358,211 @@ static const struct exynos_pmu_conf 
>> exynos5250_pmu_config[] = {
>> { PMU_TABLE_END,},
>>  };
>>
>> +static const struct exynos_pmu_conf exynos7_pmu_config[] = {
>> +   /* { .offset = address offset, .val = { AFTR, LPA, SLEEP } } */
>
> Nit: address offset -> offset
>
>> +   { EXYNOS7_ATLAS_CPU0_SYS_PWR_REG,   { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_CENTRAL_SYS_PWR_REG,   { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU0_CPUSEQUENCER_SYS_PWR_REG,  { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_ATLAS_CPU1_SYS_PWR_REG,   { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_CENTRAL_SYS_PWR_REG,   { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU1_CPUSEQUENCER_SYS_PWR_REG,  { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_ATLAS_CPU2_SYS_PWR_REG,   { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_CENTRAL_SYS_PWR_REG,   { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU2_CPUSEQUENCER_SYS_PWR_REG,  { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_ATLAS_CPU3_SYS_PWR_REG,   { 0x0, 0x0, 
>> 0x8 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_CENTRAL_SYS_PWR_REG,   { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DIS_IRQ_ATLAS_CPU3_CPUSEQUENCER_SYS_PWR_REG,  { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_ATLAS_NONCPU_SYS_PWR_REG, { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_ATLAS_DBG_SYS_PWR_REG,{ 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_ATLAS_L2_SYS_PWR_REG, { 0x0, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_CLKSTOP_CMU_TOP_SYS_PWR_REG,  { 0x1, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_CLKRUN_CMU_TOP_SYS_PWR_REG,   { 0x1, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_RESET_CMU_TOP_SYS_PWR_REG,{ 0x1, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_RESET_CPUCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_CLKSTOP_CMU_MIF_SYS_PWR_REG,  { 0x1, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_CLKRUN_CMU_MIF_SYS_PWR_REG,   { 0x1, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_RESET_CMU_MIF_SYS_PWR_REG,{ 0x1, 0x1, 
>> 0x0 } },
>> +   { EXYNOS7_DDRPHY_DLLLOCK_SYS_PWR_REG,   { 0x1, 0x1, 
>> 0x1 } },
>> +   { EXYNOS7_DISABLE_PLL_CMU_TOP_SYS_PWR_REG,  { 0x1, 0x0, 
>> 0x0 } },
>> +   { EXYNOS7_DISABLE_PLL_CMU_MIF_SYS_PWR_REG,   

Re: [PATCH] cpufreq: respect the min/max settings from user space

[Viresh Kumar]

On 28 October 2014 08:55, Vince Hsu  wrote:
> Hi Viresh,
>
> Could you remind me where can I find this patch upstream? It seems this was
> missed?

Rafael hasn't picked it up. You can normally look at the tree Rafael
manages:

git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git

Can you please resend it to 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/

linux-next: manual merge of the usb-gadget tree with the driver-core tree

[Stephen Rothwell]

Hi Felipe,

Today's linux-next merge of the usb-gadget tree got a conflict in
drivers/usb/gadget/udc/pxa27x_udc.c between commit 6d3f5f2d895b ("usb:
gadget: udc: drop owner assignment from platform_drivers") from the
driver-core tree and commit 1803fe15ad54 ("usb: gadget: pxa27x_udc: add
devicetree support") from the usb-gadget tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc drivers/usb/gadget/udc/pxa27x_udc.c
index 61bceedf515d,69e7b816d880..
--- a/drivers/usb/gadget/udc/pxa27x_udc.c
+++ b/drivers/usb/gadget/udc/pxa27x_udc.c
@@@ -2614,6 -2589,8 +2589,7 @@@ MODULE_ALIAS("platform:pxa27x-udc")
  static struct platform_driver udc_driver = {
.driver = {
.name   = "pxa27x-udc",
 -  .owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(udc_pxa_dt_ids),
},
.probe  = pxa_udc_probe,
.remove = pxa_udc_remove,


pgp1TinPedrAy.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 2/6] drivers: soc: Add support for Exynos PMU driver

[amit daniel kachhap]

On Sat, Nov 8, 2014 at 10:45 PM, Pankaj Dubey  wrote:
> Hi Amit,
>
> On 8 November 2014 18:46, Amit Daniel Kachhap  wrote:
>> This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
>> to "drivers/soc/samsung". This driver is mainly used for setting misc bits of
>> register from PMU IP of Exynos SoC which will be required to configure
>> before Suspend/Resume. Currently all these settings are done in
>> "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
>> support,there is a need of DT based implementation of PMU driver.
>>
>> This driver uses already existing DT binding information.
>>
>> Signed-off-by: Pankaj Dubey 
>> Signed-off-by: Amit Daniel Kachhap 
>> ---
>>  arch/arm/mach-exynos/Makefile  |2 +-
>>  drivers/soc/Kconfig|1 +
>>  drivers/soc/Makefile   |1 +
>>  drivers/soc/samsung/Kconfig|   19 
>> +++
>>  drivers/soc/samsung/Makefile   |1 +
>>  .../pmu.c => drivers/soc/samsung/exynos-pmu.c  |0
>>  6 files changed, 23 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/soc/samsung/Kconfig
>>  create mode 100644 drivers/soc/samsung/Makefile
>>  rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (100%)
>>
>> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
>> index bcefb54..b91b382 100644
>> --- a/arch/arm/mach-exynos/Makefile
>> +++ b/arch/arm/mach-exynos/Makefile
>> @@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
>> -I$(srctree)/$(src)/include -I$(srctree)
>>
>>  # Core
>>
>> -obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o
>> +obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o exynos-smc.o firmware.o
>>
>>  obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
>>  obj-$(CONFIG_PM_SLEEP) += suspend.o
>> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
>> index 76d6bd4..90f33b9 100644
>> --- a/drivers/soc/Kconfig
>> +++ b/drivers/soc/Kconfig
>> @@ -3,5 +3,6 @@ menu "SOC (System On Chip) specific Drivers"
>>  source "drivers/soc/qcom/Kconfig"
>>  source "drivers/soc/ti/Kconfig"
>>  source "drivers/soc/versatile/Kconfig"
>> +source "drivers/soc/samsung/Kconfig"
>>
>>  endmenu
>> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
>> index 063113d..44d220d 100644
>> --- a/drivers/soc/Makefile
>> +++ b/drivers/soc/Makefile
>> @@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_QCOM) += qcom/
>>  obj-$(CONFIG_ARCH_TEGRA)   += tegra/
>>  obj-$(CONFIG_SOC_TI)   += ti/
>>  obj-$(CONFIG_PLAT_VERSATILE)   += versatile/
>> +obj-$(CONFIG_ARCH_EXYNOS)  += samsung/
>> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
>> new file mode 100644
>> index 000..beb6dfc
>> --- /dev/null
>> +++ b/drivers/soc/samsung/Kconfig
>> @@ -0,0 +1,19 @@
>> +#
>> +# SAMSUNG SOC drivers
>> +#
>> +menuconfig SOC_SAMSUNG
>> +   bool "Samsung SOC drivers support"
>> +
>> +if SOC_SAMSUNG
>> +
>> +config MFD_EXYNOS_PMU
>
> MFD_EXYNOS_PMU? I think it should be only EXYNOS_PMU,
> as we are moving here in drivers/soc giving reason as it does not fit
> into MFD.
>
>> +   tristate "Support Exynos Power Management Unit"
>
> I think this config should not be user visible config option, as I remember
> same was pointed out by Tomasz some times back.
I agree to some extent so set its property to default yes. But as this
is now a platform driver so I let it visible.
>
>> +   depends on ARM || ARM64
>
> How about only making depends on ARCH_EXYNOS?
Right makes sense. Will post v3 with this change.

Regards,
Amit
>
>> +   default y
>> +   help
>> + Exynos SoC have Power Management Unit (PMU) which controls power 
>> and
>> + operation state of Exynos SoC in two different ways. This driver
>> + provides implementation of PMU driver and provides basic 
>> functionality
>> + required during these operation state.
>> +
>> +endif #SOC_SAMSUNG
>> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
>> new file mode 100644
>> index 000..9d30f61
>> --- /dev/null
>> +++ b/drivers/soc/samsung/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_MFD_EXYNOS_PMU)   += exynos-pmu.o
>> diff --git a/arch/arm/mach-exynos/pmu.c b/drivers/soc/samsung/exynos-pmu.c
>> similarity index 100%
>> rename from arch/arm/mach-exynos/pmu.c
>> rename to drivers/soc/samsung/exynos-pmu.c
>> --
>> 1.7.9.5
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj

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

[Vinod Koul]

On Mon, Nov 10, 2014 at 11:58:46AM +1100, Stephen Rothwell wrote:
> Hi Vinod,
> 
> After merging the slave-dma tree, today's linux-next build (x86_64 
> allmodconfig)
> failed like this:
> 
> drivers/dma/at_xdmac.c: In function 'at_xdmac_off':
> drivers/dma/at_xdmac.c:317:2: error: implicit declaration of function 
> 'writel_relaxed' [-Werror=implicit-function-declaration]
>   at_xdmac_write(atxdmac, AT_XDMAC_GD, -1L);
>   ^
> 
> Caused by commit e1f7c9eee707 ("dmaengine: at_xdmac: creation of the
> atmel eXtended DMA Controller driver").
Thanks Stephen,

I have fixed this error and warning, the tree is updated now

-- 
~Vinod

> 
> Also, lots of warnings like:
> 
> drivers/dma/at_xdmac.c: In function 'at_xdmac_prep_slave_sg':
> include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of 
> type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
>   static struct _ddebug  __aligned(8)   \
> ^
> include/linux/dynamic_debug.h:84:2: note: in expansion of macro 
> 'DEFINE_DYNAMIC_DEBUG_METADATA'
>   DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
>   ^
> include/linux/device.h:1107:2: note: in expansion of macro 'dynamic_dev_dbg'
>   dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
>   ^
> drivers/dma/at_xdmac.c:621:3: note: in expansion of macro 'dev_dbg'
>dev_dbg(chan2dev(chan),
>^
> 
> I have used the slave-dma tree from next-20141106 for today.
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au



-- 


signature.asc
Description: Digital signature

Re: [PATCH 1/1] perf tools: perf diff for different binaries

[Namhyung Kim]

Hi Kan,

On Thu, 6 Nov 2014 14:16:23 +, Kan Liang wrote:
> The diff code doesn’t define event_op mmap2, so it fails to get the symbol.

Looks like a bug in perf diff code.  (It's too easy to miss... :-/ )


> You are right, it’s ip address. The meaning of symbol for diff and report 
> should
> be same.

Agreed.


>
> But I still think the author intends to compare the ip address. Low 
> granularity is
> still useful for debugging the scaling issue. So we'd better keep both of 
> them,
> and give ip address sorting a proper key name. 
>
> "ip" means "IP address executed at the time of sample "
> "symbol" means "name of function executed at the time of sample"

I think the term 'IP address' is confusing since users might expect
network address.


>
> What about the attached patch?
>
> Thanks,
> Kan
>
> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
> index 25114c9..3063fbd 100644
> --- a/tools/perf/builtin-diff.c
> +++ b/tools/perf/builtin-diff.c
> @@ -357,6 +357,7 @@ static int diff__process_sample_event(struct perf_tool 
> *tool __maybe_unused,
>  static struct perf_tool tool = {
> .sample = diff__process_sample_event,
> .mmap   = perf_event__process_mmap,
> +   .mmap2  = perf_event__process_mmap2,
> .comm   = perf_event__process_comm,
> .exit   = perf_event__process_exit,
> .fork   = perf_event__process_fork,

Please send it as a separate fix.


> @@ -743,7 +744,7 @@ static const struct option options[] = {
> OPT_STRING('S', "symbols", &symbol_conf.sym_list_str, 
> "symbol[,symbol...]",
>"only consider these symbols"),
> OPT_STRING('s', "sort", &sort_order, "key[,key2...]",
> -  "sort by key(s): pid, comm, dso, symbol, parent, cpu, 
> srcline, ..."
> +  "sort by key(s): pid, comm, dso, symbol, ip, parent, cpu, 
> srcline, ..."

With this, you also need to update the documentation.


>" Please refer the man page for the complete list."),
> OPT_STRING('t', "field-separator", &symbol_conf.field_sep, 
> "separator",
>"separator for columns, no spaces will be added between "
> @@ -1164,6 +1165,9 @@ int cmd_diff(int argc, const char **argv, const char 
> *prefix __maybe_unused)
> if (setup_sorting() < 0)
> usage_with_options(diff_usage, options);
>
> +   if (sort__has_ip)
> +   tool.mmap2 = NULL;
> +

I don't think this is the right thing to do.  And I guess you need to
identify symbols anyway.


> setup_pager();
>
> sort__setup_elide(NULL);
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index 9402885..a59f389 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -20,6 +20,7 @@ int   have_ignore_callees = 0;
>  intsort__need_collapse = 0;
>  intsort__has_parent = 0;
>  intsort__has_sym = 0;
> +intsort__has_ip = 0;

Why is this needed?


>  intsort__has_dso = 0;
>  enum sort_mode sort__mode = SORT_MODE__NORMAL;
>
> @@ -272,9 +273,32 @@ static int hist_entry__sym_snprintf(struct hist_entry 
> *he, char *bf,
>  he->level, bf, size, width);
>  }
>
> +static int64_t
> +sort__sym_name_cmp(struct hist_entry *left, struct hist_entry *right)
> +{
> +   const char *sym_name_l, *sym_name_r;
> +
> +   if (!left->ms.sym || !right->ms.sym)
> +   return cmp_null(right->ms.sym, left->ms.sym);
> +
> +   sym_name_l = left->ms.sym->name;
> +   sym_name_r = right->ms.sym->name;
> +
> +   return strcmp(sym_name_l, sym_name_r);
> +}

Looks like doing same thing as sort__sym_sort().


> +
>  struct sort_entry sort_sym = {
> .se_header  = "Symbol",
> .se_cmp = sort__sym_cmp,
> +   .se_collapse= sort__sym_name_cmp,

This will change the behavior of perf report somewhat.


> +   .se_sort= sort__sym_sort,
> +   .se_snprintf= hist_entry__sym_snprintf,
> +   .se_width_idx   = HISTC_SYMBOL,
> +};
> +
> +struct sort_entry sort_ip = {
> +   .se_header  = "IP address",
> +   .se_cmp = sort__sym_cmp,

I think what you need is "symbol+offset" comparison so the .se_cmp
should compare hist_entry->ip (ie. mapped addr) instead of sym->start.

But I'm still not sure how it's meaningful since a bit of change will
result in changing offsets so that it cannot find a match.

Thanks,
Namhyung


> .se_sort= sort__sym_sort,
> .se_snprintf= hist_entry__sym_snprintf,
> .se_width_idx   = HISTC_SYMBOL,
> @@ -1170,6 +1194,7 @@ static struct sort_dimension common_sort_dimensions[] = 
> {
> DIM(SORT_COMM, "comm", sort_comm),
> DIM(SORT_DSO, "dso", sort_dso),
> DIM(SORT_SYM, "symbol", sort_sym),
> +   DIM(SORT_IP, "ip", sort_ip),
> DIM(SORT_PARENT, "parent", sort_parent),
> DIM(SORT_CPU, "cpu", sor

Re: [PATCH v2 3/6] drivers: soc: samsung: Fix a spelling mistake

[amit daniel kachhap]

On Sat, Nov 8, 2014 at 9:26 PM, Pankaj Dubey  wrote:
> Hi Amit,
>
>
> On 8 November 2014 18:46, Amit Daniel Kachhap  wrote:
>> This patches changes the name of exynos5_list_diable_wfi_wfe to
>> exynos5_list_disable_wfi_wfe.
>>
>
> Same change I have posted earlier [1] and Kukjin has taken same in his 
> for-next.
>
> 1: http://www.spinics.net/lists/arm-kernel/msg372742.html
ok but this patch is still not visible in linux-next. I will rebase my
v3 patch series against Kukjin for-next
>
> Thanks,
> Pankaj Dubey
>
>
>> Signed-off-by: Amit Daniel Kachhap 
>> ---
>>  drivers/soc/samsung/exynos-pmu.c |8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/soc/samsung/exynos-pmu.c 
>> b/drivers/soc/samsung/exynos-pmu.c
>> index 35774e8..3832cda 100644
>> --- a/drivers/soc/samsung/exynos-pmu.c
>> +++ b/drivers/soc/samsung/exynos-pmu.c
>> @@ -361,7 +361,7 @@ static unsigned int const exynos5_list_both_cnt_feed[] = 
>> {
>> EXYNOS5_TOP_PWR_SYSMEM_OPTION,
>>  };
>>
>> -static unsigned int const exynos5_list_diable_wfi_wfe[] = {
>> +static unsigned int const exynos5_list_disable_wfi_wfe[] = {
>> EXYNOS5_ARM_CORE1_OPTION,
>> EXYNOS5_FSYS_ARM_OPTION,
>> EXYNOS5_ISP_ARM_OPTION,
>> @@ -392,11 +392,11 @@ static void exynos5_powerdown_conf(enum sys_powerdown 
>> mode)
>> /*
>>  * Disable WFI/WFE on XXX_OPTION
>>  */
>> -   for (i = 0; i < ARRAY_SIZE(exynos5_list_diable_wfi_wfe); i++) {
>> -   tmp = pmu_raw_readl(exynos5_list_diable_wfi_wfe[i]);
>> +   for (i = 0; i < ARRAY_SIZE(exynos5_list_disable_wfi_wfe); i++) {
>> +   tmp = pmu_raw_readl(exynos5_list_disable_wfi_wfe[i]);
>> tmp &= ~(EXYNOS5_OPTION_USE_STANDBYWFE |
>>  EXYNOS5_OPTION_USE_STANDBYWFI);
>> -   pmu_raw_writel(tmp, exynos5_list_diable_wfi_wfe[i]);
>> +   pmu_raw_writel(tmp, exynos5_list_disable_wfi_wfe[i]);
>> }
>>  }
>>
>> --
>> 1.7.9.5
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms

[Viresh Kumar]

On 27 October 2014 09:09, Yuantian Tang  wrote:
> Do we have a conclusion yet?

No. You can keep your initial duplication of Kconfig entries for the time being.
--
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] x86, kvm, vmx: Always use LOAD_IA32_EFER if available

[Wanpeng Li]

Hi Andy,
On Fri, Nov 07, 2014 at 06:25:18PM -0800, Andy Lutomirski wrote:
>At least on Sandy Bridge, letting the CPU switch IA32_EFER is much
>faster than switching it manually.
>
>I benchmarked this using the vmexit kvm-unit-test (single run, but
>GOAL multiplied by 5 to do more iterations):
>
>Test  Before  AfterChange
>cpuid   2000   1932-3.40%
>vmcall  1914   1817-5.07%
>mov_from_cr8  13 13 0.00%
>mov_to_cr819 19 0.00%
>inl_from_pmtimer   19164  10619   -44.59%
>inl_from_qemu  15662  10302   -34.22%

What's the difference of IA32_EFER between guest and host in your config?

IIUC,
- NX is not consistent
  IA32_EFER will be auto load w/ and w/o the patch.
- SCE is not consistent 
  IA32_EFER will be switched through wrmsr(urn) w/o the patch, and auto load
  w/ the patch.

Regards,
Wanpeng Li 

>inl_from_kernel 3916   3802-2.91%
>outl_to_kernel  2230   2194-1.61%
>mov_dr   172176 2.33%
>ipi(skipped)  (skipped)
>ipi+halt   (skipped)  (skipped)
>ple-round-robin   13 13 0.00%
>wr_tsc_adjust_msr   1920   1845-3.91%
>rd_tsc_adjust_msr   1892   1814-4.12%
>mmio-no-eventfd:pci-mem16394  11165   -31.90%
>mmio-wildcard-eventfd:pci-mem   4607   4645 0.82%
>mmio-datamatch-eventfd:pci-mem  4601   4610 0.20%
>portio-no-eventfd:pci-io   11507   7942   -30.98%
>portio-wildcard-eventfd:pci-io  2239   2225-0.63%
>portio-datamatch-eventfd:pci-io 2250   2234-0.71%
>
>I haven't explicitly computed the significance of these numbers,
>but this isn't subtle.
>
>Signed-off-by: Andy Lutomirski 
>---
> arch/x86/kvm/vmx.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>index 3e556c68351b..e72b9660e51c 100644
>--- a/arch/x86/kvm/vmx.c
>+++ b/arch/x86/kvm/vmx.c
>@@ -1659,8 +1659,14 @@ static bool update_transition_efer(struct vcpu_vmx 
>*vmx, int efer_offset)
>   vmx->guest_msrs[efer_offset].mask = ~ignore_bits;
> 
>   clear_atomic_switch_msr(vmx, MSR_EFER);
>-  /* On ept, can't emulate nx, and must switch nx atomically */
>-  if (enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX)) {
>+
>+  /*
>+   * On EPT, we can't emulate NX, so we must switch EFER atomically.
>+   * On CPUs that support "load IA32_EFER", always switch EFER
>+   * atomically, since it's faster than switching it manually.
>+   */
>+  if (cpu_has_load_ia32_efer ||
>+  (enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX))) {
>   guest_efer = vmx->vcpu.arch.efer;
>   if (!(guest_efer & EFER_LMA))
>   guest_efer &= ~EFER_LME;
>-- 
>1.9.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe kvm" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the driver-core tree with the pm tree

[Greg KH]

On Mon, Nov 10, 2014 at 03:18:56PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/input/keyboard/gpio_keys_polled.c between commit b26d4e2283b6
> ("input: gpio_keys_polled: Make use of device property API") from the
> pm tree and commit 1d05726c315c ("input: keyboard: drop owner
> assignment from platform_drivers") from the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/input/keyboard/gpio_keys_polled.c
> index c9c1c8ca7267,10f0098f3c77..
> --- a/drivers/input/keyboard/gpio_keys_polled.c
> +++ b/drivers/input/keyboard/gpio_keys_polled.c
> @@@ -297,8 -307,7 +297,7 @@@ static struct platform_driver gpio_keys
>   .probe  = gpio_keys_polled_probe,
>   .driver = {
>   .name   = DRV_NAME,
> - .owner  = THIS_MODULE,
>  -.of_match_table = of_match_ptr(gpio_keys_polled_of_match),
>  +.of_match_table = gpio_keys_polled_of_match,
>   },
>   };
>   module_platform_driver(gpio_keys_polled_driver);


Looks good, 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/

Re: linux-next: manual merge of the driver-core tree with the l2-mtd tree

[Greg KH]

On Mon, Nov 10, 2014 at 03:28:01PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/mtd/devices/docg3.c between commit a59459f29fb7 ("mtd: docg3:
> add device-tree support") from the l2-mtd tree and commit c37c1e160546
> ("mtd: devices: drop owner assignment from platform_drivers") from the
> driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/mtd/devices/docg3.c
> index 0d9d3ee68b61,72346048532d..
> --- a/drivers/mtd/devices/docg3.c
> +++ b/drivers/mtd/devices/docg3.c
> @@@ -2130,8 -2129,6 +2130,7 @@@ MODULE_DEVICE_TABLE(of, docg3_dt_ids)
>   static struct platform_driver g3_driver = {
>   .driver = {
>   .name   = "docg3",
> - .owner  = THIS_MODULE,
>  +.of_match_table = of_match_ptr(docg3_dt_ids),
>   },
>   .suspend= docg3_suspend,
>   .resume = docg3_resume,


Looks good, 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/

Re: linux-next: manual merge of the driver-core tree with the mfd tree

[Greg KH]

On Mon, Nov 10, 2014 at 03:24:26PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/mfd/syscon.c between commit d4ad08b424c1 ("mfd: syscon:
> Decouple syscon interface from platform devices") from the mfd tree and
> commit 78a835416ad6 ("mfd: drop owner assignment from
> platform_drivers") from the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/mfd/syscon.c
> index 72373b113885,e85c052b302c..
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@@ -219,7 -166,7 +219,6 @@@ static const struct platform_device_id 
>   static struct platform_driver syscon_driver = {
>   .driver = {
>   .name = "syscon",
> - .owner = THIS_MODULE,
>  -.of_match_table = of_syscon_match,
>   },
>   .probe  = syscon_probe,
>   .id_table   = syscon_ids,


Looks good, 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/

Re: linux-next: manual merge of the driver-core tree with the tree

[Greg KH]

On Mon, Nov 10, 2014 at 03:21:25PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/leds/leds-gpio.c between commit a43f2cbbb009 ("leds: leds-gpio:
> Make use of device property API") from the  tree and commit
> 81902d5f658f ("leds: drop owner assignment from platform_drivers") from
> the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/leds/leds-gpio.c
> index b3c5d9d6a42b,ac4768f2b2b4..
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@@ -281,8 -287,7 +281,7 @@@ static struct platform_driver gpio_led_
>   .remove = gpio_led_remove,
>   .driver = {
>   .name   = "leds-gpio",
> - .owner  = THIS_MODULE,
>  -.of_match_table = of_match_ptr(of_gpio_leds_match),
>  +.of_match_table = of_gpio_leds_match,
>   },
>   };
>   


Looks good, 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/

Re: [PATCH v5 12/16] cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq

[Viresh Kumar]

On 24 October 2014 20:09, Mikko Perttunen  wrote:
> From: Tuomas Tynkkynen 
>
> The Tegra124 will use a different driver for frequency scaling, so
> rename the old driver (which handles only Tegra20) appropriately.
>
> Signed-off-by: Tuomas Tynkkynen 
> Signed-off-by: Mikko Perttunen 
> ---
>  drivers/cpufreq/Kconfig.arm   |   6 +-
>  drivers/cpufreq/Makefile  |   2 +-
>  drivers/cpufreq/tegra-cpufreq.c   | 218 
> --
>  drivers/cpufreq/tegra20-cpufreq.c | 218 
> ++
>  4 files changed, 222 insertions(+), 222 deletions(-)
>  delete mode 100644 drivers/cpufreq/tegra-cpufreq.c
>  create mode 100644 drivers/cpufreq/tegra20-cpufreq.c

Its just not readable enough.. You should have used: git format-patch -C -M
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the driver-core tree with the sound-asoc tree

[Stephen Rothwell]

Hi Greg,

On Mon, 10 Nov 2014 13:38:53 +0900 Greg KH  wrote:
>
> On Mon, Nov 10, 2014 at 03:31:32PM +1100, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the driver-core tree got a conflict in
> > sound/soc/intel/sst-haswell-pcm.c between commit 2e4f75919e5a ("ASoC:
> > Intel: Add PM support to HSW/BDW PCM driver") from the sound-asoc tree
> > and commit 3c1af8802e45 ("ASoC: intel: drop owner assignment from
> > platform_drivers") from the driver-core tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> > 
> > -- 
> > Cheers,
> > Stephen Rothwells...@canb.auug.org.au
> > 
> > diff --cc sound/soc/intel/sst-haswell-pcm.c
> > index 7eb9afc9b33d,ad21e636edc6..
> > --- a/sound/soc/intel/sst-haswell-pcm.c
> > +++ b/sound/soc/intel/sst-haswell-pcm.c
> > @@@ -1173,9 -899,6 +1173,8 @@@ static const struct dev_pm_ops hsw_pcm_
> >   static struct platform_driver hsw_pcm_driver = {
> > .driver = {
> > .name = "haswell-pcm-audio",
> > -   .owner = THIS_MODULE,
> >  +  .pm = &hsw_pcm_pm,
> >  +
> > },
> >   
> > .probe = hsw_pcm_dev_probe,
> 
> 
> Fix looks good, thanks.

I assume that there was a good reason not to farm these patches out to
their respective maintainers?

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


pgpNCHNH7HaOM.pgp
Description: OpenPGP digital signature

Re: linux-next: manual merge of the driver-core tree with the sound-asoc tree

[Greg KH]

On Mon, Nov 10, 2014 at 03:31:32PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> sound/soc/intel/sst-haswell-pcm.c between commit 2e4f75919e5a ("ASoC:
> Intel: Add PM support to HSW/BDW PCM driver") from the sound-asoc tree
> and commit 3c1af8802e45 ("ASoC: intel: drop owner assignment from
> platform_drivers") from the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc sound/soc/intel/sst-haswell-pcm.c
> index 7eb9afc9b33d,ad21e636edc6..
> --- a/sound/soc/intel/sst-haswell-pcm.c
> +++ b/sound/soc/intel/sst-haswell-pcm.c
> @@@ -1173,9 -899,6 +1173,8 @@@ static const struct dev_pm_ops hsw_pcm_
>   static struct platform_driver hsw_pcm_driver = {
>   .driver = {
>   .name = "haswell-pcm-audio",
> - .owner = THIS_MODULE,
>  +.pm = &hsw_pcm_pm,
>  +
>   },
>   
>   .probe = hsw_pcm_dev_probe,


Fix looks good, 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/

linux-next: manual merge of the tty tree with the tty.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the tty tree got a conflict in
drivers/tty/serial/8250/8250_mtk.c between commit cd92208f6996 ("tty:
serial: 8250_mtk: Fix quot calculation") from the tty.current tree and
commit 2a768264eef0 ("tty: serial: Fix mediatek UART driver setting
baudrate issue") from the tty tree.

I fixed it up (I just used the version from the tty tree) and can carry
the fix as necessary (no action is required).

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


pgp9H5jGdOshU.pgp
Description: OpenPGP digital signature