Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Davidlohr Bueso]

On Tue, 2015-02-03 at 07:58 +0100, Alexander Holler wrote:
> Am 03.02.2015 um 07:05 schrieb Al Viro:
> > On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote:
> >> +  if (inode) {
> >> +  // TODO:
> >> +  // if (inode is file and 's' flag is set)
> >> +  //  secure = true;
> >> +  if (!secure)
> >> +  iput(inode);/* truncate the inode here */
> >> +  else {
> >> +  struct super_block *sb = inode->i_sb;
> >> +  if (sb->s_op->set_secure_delete)
> >> +  sb->s_op->set_secure_delete(sb, true);
> >> +  // TODO: We should fail if secure isn't supported,
> >> +  // look up how that's possible here.
> >> +  iput(inode);/* truncate the inode here */
> >> +  // TODO: check if sb is still valid after the inode is 
> >> gone
> >> +  sync_filesystem(sb);
> >> +  if (sb->s_op->set_secure_delete)
> >> +  sb->s_op->set_secure_delete(sb, false);
> >> +  }
> > 
> > Charming.  Now, what exactly happens if two such syscalls overlap in time?
> 
> What do you think will happen? I assume you haven't looked at how I've
> implemented set_secure_delete(). CHarming.

Chill, why don't you.

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

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Al Viro]

On Tue, Feb 03, 2015 at 07:58:50AM +0100, Alexander Holler wrote:

> > Charming.  Now, what exactly happens if two such syscalls overlap in time?
> 
> What do you think will happen? I assume you haven't looked at how I've
> implemented set_secure_delete(). CHarming.

AFAICS, you get random unlink() happening at the same time hit by that
mess, whether they'd asked for it or not.  What's more, this counter
of yours is *not* guaranteed to be elevated during the final iput() of the
inode you wanted to get - again, ls -lR racing with that syscall can
elevate the refcount of dentry, making d_delete() in vfs_unlink() just
remove that dentry from hash, while keeping it positive.  If dentry
reference grabbed by stat(2) is released after both dput() and iput() in
do_unlinkat(), the final iput() will be done when stat(2) drops its
reference to dentry, triggering immediate dentry_kill() (since dentry
has already been unhashed) and dentry_iput() from it.

IOW, this counter is both too crude (it's fs-wide, for crying out loud)
*and* not guaranteed to cover enough.  _IF_ you want that behaviour at
all, it ought to be an in-core inode flag set by that syscall and
checked by truncation logics to decide whether to do normal truncate of
this "overwrite with zeroes" thing.

While we are at it, "overwrite with zeroes" is too weak if the attacker
might get hold of the actual hardware.  Google for details - it's far too
long story for l-k posting.  Look for data recovery and secure data erasure...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself

[Manuel Lauss]

On Tue, Feb 3, 2015 at 4:33 AM, Bo Shen  wrote:
> Let the wm8731 codec to manage clock by itself.
>
> As all at91 related boards have been switch to CCF framework. So, on
> the at91 related boards which use wm8731 will let it manage the clock,
> or else the board use wm8731 is broken.
>
> However, at the same time the wm8731 codec is used on other boards,
> I am sure this change will broken some boards.
>
> For example: poodle and corgi based on PXA SoC (in default configuration
> file, no one use it). DB1200 board which is a mips based board. So I have
> no idea how to fix them.
>
> So, my suggestion is to add CCF check based on the following patch? Any
> idea or suggestions?

What about the patch below?  It makes absence of mclk object non-fatal and
checks if wm8731->mclk is non-NULL before enabling/disabling it.  Works on
my DB1200/DB1300 boards:

diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index b115ed8..648b8cd 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -13,6 +13,7 @@
  * published by the Free Software Foundation.
  */

+#include 
 #include 
 #include 
 #include 
@@ -45,6 +46,7 @@ static const char
*wm8731_supply_names[WM8731_NUM_SUPPLIES] = {
 /* codec private data */
 struct wm8731_priv {
 struct regmap *regmap;
+struct clk *mclk;
 struct regulator_bulk_data supplies[WM8731_NUM_SUPPLIES];
 const struct snd_pcm_hw_constraint_list *constraints;
 unsigned int sysclk;
@@ -389,6 +391,8 @@ static int wm8731_set_dai_sysclk(struct
snd_soc_dai *codec_dai,
 switch (clk_id) {
 case WM8731_SYSCLK_XTAL:
 case WM8731_SYSCLK_MCLK:
+if (wm8731->mclk && clk_set_rate(wm8731->mclk, freq))
+return -EINVAL;
 wm8731->sysclk_type = clk_id;
 break;
 default:
@@ -490,6 +494,8 @@ static int wm8731_set_bias_level(struct
snd_soc_codec *codec,

 switch (level) {
 case SND_SOC_BIAS_ON:
+if (wm8731->mclk)
+clk_prepare_enable(wm8731->mclk);
 break;
 case SND_SOC_BIAS_PREPARE:
 break;
@@ -508,6 +514,8 @@ static int wm8731_set_bias_level(struct
snd_soc_codec *codec,
 snd_soc_write(codec, WM8731_PWR, reg | 0x0040);
 break;
 case SND_SOC_BIAS_OFF:
+if (wm8731->mclk)
+clk_disable_unprepare(wm8731->mclk);
 snd_soc_write(codec, WM8731_PWR, 0x);
 regulator_bulk_disable(ARRAY_SIZE(wm8731->supplies),
wm8731->supplies);
@@ -666,6 +674,12 @@ static int wm8731_spi_probe(struct spi_device *spi)
 if (wm8731 == NULL)
 return -ENOMEM;

+wm8731->mclk = devm_clk_get(>dev, "mclk");
+if (IS_ERR(wm8731->mclk)) {
+wm8731->mclk = NULL;
+dev_warn(>dev, "assuming static MCLK\n");
+}
+
 mutex_init(>lock);

 wm8731->regmap = devm_regmap_init_spi(spi, _regmap);
@@ -719,6 +733,12 @@ static int wm8731_i2c_probe(struct i2c_client *i2c,

 mutex_init(>lock);

+wm8731->mclk = devm_clk_get(>dev, "mclk");
+if (IS_ERR(wm8731->mclk)) {
+wm8731->mclk = NULL;
+dev_warn(>dev, "assuming static MCLK\n");
+}
+
 wm8731->regmap = devm_regmap_init_i2c(i2c, _regmap);
 if (IS_ERR(wm8731->regmap)) {
 ret = PTR_ERR(wm8731->regmap);

-- 

Manuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 03.02.2015 um 07:05 schrieb Al Viro:

On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote:

+   if (inode) {
+   // TODO:
+   // if (inode is file and 's' flag is set)
+   //  secure = true;
+   if (!secure)
+   iput(inode);/* truncate the inode here */
+   else {
+   struct super_block *sb = inode->i_sb;
+   if (sb->s_op->set_secure_delete)
+   sb->s_op->set_secure_delete(sb, true);
+   // TODO: We should fail if secure isn't supported,
+   // look up how that's possible here.
+   iput(inode);/* truncate the inode here */
+   // TODO: check if sb is still valid after the inode is 
gone
+   sync_filesystem(sb);
+   if (sb->s_op->set_secure_delete)
+   sb->s_op->set_secure_delete(sb, false);
+   }


Charming.  Now, what exactly happens if two such syscalls overlap in time?
Moroever, what makes you equate unlink() with inode removal?  What happens
if you race e.g. with stat(2) on the same thing?  Or if there's an opened
file over that sucker, for that matter?


Sorry, but I first had to make breakfast after I've got angry about the 
usual arrogance of most Linux kernel maintainers.


I've already answered the first question.

Now to the second. That still might be a problem. But that's why this is 
a RFC, why there is a WIP (Work In Progress) before the patch, why I've 
written I've never looked at those sources before, why I've written they 
are imperfect and why I've written I have not spend much time on these 
patches. I've posted them to show how I think the problem might be 
solved. These patches evolved out of desperation that otherwise users 
have to wait another 30 years until they will be offered a way to really 
delete files.


If the removal is somehow scheduled then, of course, the secure flag has 
to be scheduled too.


Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [x86_64, entry] 103dd9885d1: +7.3% will-it-scale.per_process_ops

[Huang Ying]

FYI, we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/entry
commit 103dd9885d1e96be0c7493ce9a33af0732e35441 ("x86_64, entry: Use sysret to 
return to userspace when possible")


testbox/testcase/testparams: lkp-sb03/will-it-scale/open2

261ebee6aee55a47  103dd9885d1e96be0c7493ce9a  
  --  
 %stddev %change %stddev
 \  |\  
 35.96 ±  6% -39.8%  21.66 ±  7%  will-it-scale.time.user_time
237495 ±  1%  +5.2% 249861 ±  1%  will-it-scale.per_thread_ops
739981 ±  0%  +7.3% 793911 ±  0%  will-it-scale.per_process_ops
   127 ± 20% -66.9% 42 ± 30%  sched_debug.cfs_rq[14]:/.load
   127 ± 20% -66.9% 42 ± 30%  sched_debug.cpu#14.load
58 ± 21% -39.3% 35 ± 43%  sched_debug.cfs_rq[7]:/.load
58 ± 21% -39.3% 35 ± 43%  sched_debug.cpu#7.load
  3442 ± 25% -42.5%   1978 ± 20%  sched_debug.cpu#28.sched_goidle
  3591 ± 36%+128.5%   8204 ± 17%  sched_debug.cpu#10.ttwu_local
  8241 ± 21% -36.9%   5202 ± 19%  sched_debug.cpu#28.nr_switches
  5411 ± 18% -39.0%   3301 ± 13%  sched_debug.cpu#14.ttwu_local
  8800 ± 15% -27.8%   6356 ± 20%  sched_debug.cpu#9.ttwu_count
42 ± 22% -33.3% 28 ± 47%  
sched_debug.cfs_rq[14]:/.runnable_load_avg
67 ± 46% +87.1%126 ± 31%  sched_debug.cpu#12.load
573932 ±  1% +59.5% 915353 ±  1%  slabinfo.kmalloc-256.active_objs
  8970 ±  1% +59.5%  14305 ±  1%  slabinfo.kmalloc-256.num_slabs
  8970 ±  1% +59.5%  14305 ±  1%  slabinfo.kmalloc-256.active_slabs
574152 ±  1% +59.5% 915575 ±  1%  slabinfo.kmalloc-256.num_objs
 35.96 ±  6% -39.8%  21.66 ±  7%  time.user_time
  1358 ± 24% -31.9%924 ± 34%  sched_debug.cpu#31.ttwu_local
  2487 ± 14% -32.6%   1677 ±  9%  sched_debug.cpu#31.sched_goidle
 17643 ±  8% -33.6%  11719 ±  5%  sched_debug.cpu#14.nr_switches
  8632 ± 11% -34.9%   5617 ± 14%  sched_debug.cpu#14.ttwu_count
29 ± 12% +31.9% 38 ± 15%  sched_debug.cpu#12.cpu_load[1]
115453 ±  3% +48.3% 171178 ±  2%  numa-meminfo.node0.SUnreclaim
 28672 ±  2% +49.2%  42775 ±  2%  
numa-vmstat.node0.nr_slab_unreclaimable
  3313 ± 15% +35.0%   4472 ± 13%  sched_debug.cpu#11.curr->pid
132090 ±  3% +42.8% 188646 ±  2%  numa-meminfo.node0.Slab
200693 ±  1% +42.8% 286535 ±  0%  meminfo.SUnreclaim
 50431 ±  1% +42.0%  71624 ±  1%  proc-vmstat.nr_slab_unreclaimable
26 ± 12% +29.8% 33 ± 12%  sched_debug.cpu#12.cpu_load[4]
 20434 ±  2% +38.4%  28286 ±  2%  
numa-vmstat.node1.nr_slab_unreclaimable
 82040 ±  2% +36.9% 112273 ±  2%  numa-meminfo.node1.SUnreclaim
 14623 ± 26% +55.6%  22751 ± 12%  sched_debug.cpu#10.nr_switches
235487 ±  1% +36.5% 321407 ±  0%  meminfo.Slab
842597 ± 20% -30.2% 588471 ± 26%  
sched_debug.cfs_rq[27]:/.min_vruntime
  6502 ± 25% +54.2%  10028 ± 11%  sched_debug.cpu#10.sched_goidle
100197 ±  2% +29.4% 129675 ±  2%  numa-meminfo.node1.Slab
237178 ±  1% -23.2% 182260 ±  2%  softirqs.RCU
  7310 ±  4% -26.2%   5397 ±  6%  sched_debug.cpu#14.sched_goidle
  6148 ± 12% -22.7%   4751 ± 10%  sched_debug.cpu#31.nr_switches
 44905 ± 20% -28.5%  32101 ± 25%  
sched_debug.cfs_rq[27]:/.exec_clock
32 ±  6% +38.3% 44 ± 19%  sched_debug.cpu#1.cpu_load[0]
   139 ± 15% -25.4%104 ± 18%  
sched_debug.cfs_rq[23]:/.tg_load_contrib
  3454 ± 14% -17.7%   2844 ±  6%  sched_debug.cpu#31.curr->pid
   438 ±  8% -11.5%388 ±  5%  
sched_debug.cfs_rq[31]:/.tg_runnable_contrib
30 ±  1% +11.6% 33 ±  6%  sched_debug.cpu#23.cpu_load[4]
 20115 ±  7% -11.3%  17841 ±  6%  
sched_debug.cfs_rq[31]:/.avg->runnable_avg_sum
35 ± 11% -19.0% 28 ±  9%  sched_debug.cpu#21.cpu_load[0]
32 ±  6% +31.2% 42 ± 19%  
sched_debug.cfs_rq[1]:/.runnable_load_avg
32 ± 11% +27.1% 41 ± 10%  sched_debug.cpu#9.cpu_load[2]
30 ±  1%  +9.9% 33 ±  6%  sched_debug.cpu#23.cpu_load[3]
   575 ±  5% +12.4%647 ±  6%  
sched_debug.cfs_rq[23]:/.tg_runnable_contrib
 26412 ±  5% +12.5%  29710 ±  6%  
sched_debug.cfs_rq[23]:/.avg->runnable_avg_sum
29 ± 18% +33.6% 38 ± 14%  sched_debug.cpu#12.cpu_load[0]
32 ±  5% +32.1% 43 ± 17%  sched_debug.cpu#1.cpu_load[1]
33 ±  6% +26.3% 42 ± 16%  sched_debug.cpu#1.cpu_load[2]
424232 ±  2% +13.7% 482375 ±  1%  numa-meminfo.node0.MemUsed
  3558 ±  6% +14.5%   4076 ±  3%  

Re: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Daniel Vetter]

On Mon, Feb 02, 2015 at 05:36:10PM -0500, Rob Clark wrote:
> well, I guess anyways when it comes to sharing buffers, it won't be
> the vram placement of the bo that gets shared ;-)

Actually that's pretty much what I'd like to be able to do for i915.
Except that vram is just a specially protected chunk of main memory.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Daniel Vetter]

On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter  wrote:
> >> My initial thought is for dma-buf to not try to prevent something than
> >> an exporter can actually do.. I think the scenario you describe could
> >> be handled by two sg-lists, if the exporter was clever enough.
> >
> > That's already needed, each attachment has it's own sg-list. After all
> > there's no array of dma_addr_t in the sg tables, so you can't use one sg
> > for more than one mapping. And due to different iommu different devices
> > can easily end up with different addresses.
> 
> 
> Well, to be fair it may not be explicitly stated, but currently one
> should assume the dma_addr_t's in the dmabuf sglist are bogus.  With
> gpu's that implement per-process/context page tables, I'm not really
> sure that there is a sane way to actually do anything else..

Hm, what does per-process/context page tables have to do here? At least on
i915 we have a two levels of page tables:
- first level for vm/device isolation, used through dma api
- 2nd level for per-gpu-context isolation and context switching, handled
  internally.

Since atm the dma api doesn't have any context of contexts or different
pagetables, I don't see who you could use that at all.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFCv3 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

[Daniel Vetter]

On Mon, Feb 02, 2015 at 09:46:16PM +, Russell King - ARM Linux wrote:
> On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> > On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter  wrote:
> > >> My initial thought is for dma-buf to not try to prevent something than
> > >> an exporter can actually do.. I think the scenario you describe could
> > >> be handled by two sg-lists, if the exporter was clever enough.
> > >
> > > That's already needed, each attachment has it's own sg-list. After all
> > > there's no array of dma_addr_t in the sg tables, so you can't use one sg
> > > for more than one mapping. And due to different iommu different devices
> > > can easily end up with different addresses.
> > 
> > 
> > Well, to be fair it may not be explicitly stated, but currently one
> > should assume the dma_addr_t's in the dmabuf sglist are bogus.  With
> > gpu's that implement per-process/context page tables, I'm not really
> > sure that there is a sane way to actually do anything else..
> 
> That's incorrect - and goes dead against the design of scatterlists.
> 
> Not only that, but it is entirely possible that you may get handed
> memory via dmabufs for which there are no struct page's associated
> with that memory - think about display systems which have their own
> video memory which is accessible to the GPU, but it isn't system
> memory.
> 
> In those circumstances, you have to use the dma_addr_t's and not the
> pages.

Yeah exactly. At least with i915 we'd really want to be able to share
stolen memory in some cases, and since that's stolen there's no struct
pages for them. On top of that any cpu access is also blocked to that
range in the memory controller, so the dma_addr_t is really the _only_
thing you can use to get at those memory ranges. And afaik the camera pipe
on intel soc can get there - unfortunately that one doesn't have an
upstream driver :(

And just to clarify: All current dma-buf exporter that I've seen implement
the sg mapping correctly and _do_ map the sg table into device address
space with dma_map_sg. In other words: The dma_addr_t are all valid, it's
just that e.g. with ttm no one has bothered to teach ttm a dma-buf
correctly. The internal abstraction is all there, ttm-internal buffer
object interface match what dma-buf exposes fairly closes (hey I didn't do
shit when designing those interfaces ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [mm] 721c21c17ab: +11.7% will-it-scale.per_thread_ops

[Huang Ying]

FYI, we noticed the below changes on

commit 721c21c17ab958abf19a8fc611c3bd4743680e38 ("mm: mmu_gather: use tlb->end 
!= 0 only for TLB invalidation")


testbox/testcase/testparams: nhm4/will-it-scale/performance-readseek1

   v3.19-rc4  721c21c17ab958abf19a8fc611  
  --  
 %stddev %change %stddev
 \  |\  
  0.56 ±  1%  +5.2%   0.59 ±  1%  will-it-scale.scalability
   1807741 ±  0%  +2.3%1848641 ±  0%  will-it-scale.per_thread_ops
   740 ± 30% +40.9%   1043 ± 26%  sched_debug.cpu#4.ttwu_local
  1335 ± 20% +23.7%   1651 ± 17%  sched_debug.cpu#4.ttwu_count
   506 ±  9% +40.8%712 ±  1%  cpuidle.C1-NHM.usage
   120 ±  9% +33.1%160 ± 11%  sched_debug.cpu#7.load
   120 ±  9% +26.2%151 ± 10%  sched_debug.cfs_rq[7]:/.load
90 ±  5% -16.2% 75 ± 16%  sched_debug.cpu#6.cpu_load[4]
96 ±  7% +16.7%112 ± 10%  
sched_debug.cfs_rq[2]:/.runnable_load_avg

testbox/testcase/testparams: nhm4/will-it-scale/performance-pread2

   v3.19-rc4  721c21c17ab958abf19a8fc611  
  --  
900692 ±  1% +11.7%1005724 ±  0%  will-it-scale.per_thread_ops
  28033529 ±  0%  -1.2%   27698665 ±  0%  
will-it-scale.time.voluntary_context_switches
   671 ± 22% +40.4%942 ± 27%  
sched_debug.cfs_rq[7]:/.blocked_load_avg
   802 ± 19% +30.9%   1049 ± 25%  
sched_debug.cfs_rq[7]:/.tg_load_contrib
 44840 ±  6% +15.6%  51846 ±  6%  meminfo.DirectMap4k
 18284 ±  1%  -7.4%  16926 ±  2%  vmstat.system.in
378463 ±  0%  -1.2% 373746 ±  0%  vmstat.system.cs

testbox/testcase/testparams: nhm4/will-it-scale/performance-readseek3

   v3.19-rc4  721c21c17ab958abf19a8fc611  
  --  
  0.55 ±  0%  +9.9%   0.60 ±  5%  will-it-scale.scalability
   1791707 ±  0%  +2.9%1843202 ±  0%  will-it-scale.per_thread_ops
   187 ± 41%+167.3%501 ± 23%  
sched_debug.cfs_rq[0]:/.blocked_load_avg
   281 ± 29%+121.3%622 ± 18%  
sched_debug.cfs_rq[0]:/.tg_load_contrib
   110 ±  9% +25.5%138 ± 13%  sched_debug.cfs_rq[5]:/.load
   110 ±  9% +25.9%138 ± 13%  sched_debug.cpu#5.load
   178 ±  6% -19.5%144 ± 16%  sched_debug.cpu#4.cpu_load[1]
94 ±  6% +12.9%107 ±  8%  
sched_debug.cfs_rq[3]:/.runnable_load_avg
  1.78 ±  7% +17.4%   2.09 ±  0%  
perf-profile.cpu-cycles.put_page.shmem_file_read_iter.new_sync_read.__vfs_read.vfs_read
   187 ±  9% -19.1%152 ± 16%  sched_debug.cpu#4.cpu_load[2]
   757 ±  5% +10.6%838 ±  2%  slabinfo.kmalloc-2048.active_objs
  3064 ±  7%  +7.8%   3302 ±  6%  sched_debug.cpu#1.curr->pid
  5.23 ±  2%  +8.8%   5.69 ±  4%  
perf-profile.cpu-cycles.security_file_permission.rw_verify_area.vfs_read.sys_read.system_call_fastpath
  3.23 ±  4%  +8.0%   3.48 ±  5%  
perf-profile.cpu-cycles.copy_page_to_iter_iovec.copy_page_to_iter.shmem_file_read_iter.new_sync_read.__vfs_read
  4216 ±  7%  +7.5%   4531 ±  5%  slabinfo.kmalloc-192.active_objs

nhm4: Nehalem
Memory: 4G

lkp-sbx04: Sandy Bridge-EX
Memory: 64G




 will-it-scale.per_thread_ops

  1.04e+06 ++---+
   |   OO  O|
  1.02e+06 ++ O   O  O  O  OO O  O   O  |
 1e+06 O+ O  O   OO O
   |O  O  O |
98 ++   |
   ||
96 ++   |
   ||
94 ++   |
92 ++   |
   *..  *..*|
90 ++  +|
   |  *...*.. + |
88 ++*--+



[*] bisect-good sample
[O] bisect-bad  sample

To reproduce:

apt-get install ruby ruby-oj
git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local   job.yaml


Disclaimer:
Results have been estimated 

[PATCH 2/2] ALSA: line6: fixup of line6_start_timer argument type

[Nicholas Mc Guire]

line6_start_timer passes an unsigned int as argument to be used in mod_timer
which is then used by mod_timer as unsigned long, this just fixes up the 
argument type. This change helps make static code checkers happy.

Signed-off-by: Nicholas Mc Guire 
---

The change of argument type was checked against all call-sites - in all cases
it is passing in a constant (either VARIAX_STARTUP_DELAY1 or POD_STARTUP_DELAY)
which should be fine with the argument type change.

Patch was compile tested for x86_64_defconfig + CONFIG_SOUND=y,
CONFIG_SND_USB_POD=m (implies CONFIG_SND_USB_LINE6=y)

Patch is against 3.0.19-rc6 (localversion = -next-20150202)

 sound/usb/line6/driver.c |2 +-
 sound/usb/line6/driver.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 3cf12cc..e2a2603 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -162,7 +162,7 @@ static int line6_send_raw_message_async_part(struct message 
*msg,
 /*
Setup and start timer.
 */
-void line6_start_timer(struct timer_list *timer, unsigned int msecs,
+void line6_start_timer(struct timer_list *timer, unsigned long msecs,
   void (*function)(unsigned long), unsigned long data)
 {
setup_timer(timer, function, data);
diff --git a/sound/usb/line6/driver.h b/sound/usb/line6/driver.h
index fa877a3..2276b78 100644
--- a/sound/usb/line6/driver.h
+++ b/sound/usb/line6/driver.h
@@ -159,7 +159,7 @@ extern int line6_send_sysex_message(struct usb_line6 *line6,
const char *buffer, int size);
 extern ssize_t line6_set_raw(struct device *dev, struct device_attribute *attr,
 const char *buf, size_t count);
-extern void line6_start_timer(struct timer_list *timer, unsigned int msecs,
+extern void line6_start_timer(struct timer_list *timer, unsigned long msecs,
  void (*function)(unsigned long),
  unsigned long data);
 extern int line6_version_request_async(struct usb_line6 *line6);
-- 
1.7.10.4

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

[PATCH 1/2] ALSA: line6: use msecs_to_jiffies for conversion

[Nicholas Mc Guire]

This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var).


Signed-off-by: Nicholas Mc Guire 
---

Converting milliseconds to jiffies by val * HZ / 1000 is technically
not wrong but msecs_to_jiffies(val) is the cleaner solution and handles
all corner cases correctly. This is a minor API cleanup only.

Patch was only compile tested for x86_64_defconfig + CONFIG_SOUND=y,
CONFIG_SND_USB_POD=m (implies CONFIG_SND_USB_LINE6=y)

Patch is against 3.0.19-rc6 (localversion = -next-20150202)

 sound/usb/line6/driver.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 2328ec9..3cf12cc 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -166,7 +166,7 @@ void line6_start_timer(struct timer_list *timer, unsigned 
int msecs,
   void (*function)(unsigned long), unsigned long data)
 {
setup_timer(timer, function, data);
-   mod_timer(timer, jiffies + msecs * HZ / 1000);
+   mod_timer(timer, jiffies + msecs_to_jiffies(msecs));
 }
 EXPORT_SYMBOL_GPL(line6_start_timer);
 
-- 
1.7.10.4

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

Re: [PATCH 0/6] PCI: MMCONFIG clean up

[Tomasz Nowicki]

On 02.02.2015 21:42, Bjorn Helgaas wrote:

On Wed, Nov 19, 2014 at 05:04:45PM +0100, Tomasz Nowicki wrote:

MMCFG ACPI table has no arch dependencies so it can be used across all
architectures. Currently MMCONFIG related code resides in arch/x86 directories.
This patch set is goint to isolate non-architecure specific code and make
it accessible from drivers/pci/ directory.

Tomasz Nowicki (6):
   x86, acpi, pci: Reorder logic of pci_mmconfig_insert() function
   x86, acpi, pci: Move arch-agnostic MMCFG code out of arch/x86/
 directory
   x86, acpi, pci: Move PCI config space accessors.
   x86, acpi, pci: mmconfig_{32,64}.c code refactoring - remove code
 duplication.
   x86, acpi, pci: mmconfig_64.c becomes default implementation for arch
 agnostic low-level direct PCI config space accessors via MMCONFIG.
   pci, acpi: Share ACPI PCI config space accessors.


Hi Tomasz,

I'm just checking to make sure we aren't deadlocked here, with me waiting
for you and you waiting for me.  I gave you some comments about
abbreviations (MCFG/MMCFG/MMCONFIG/ECAM), weak functions, code placement
(drivers/acpi vs. drivers/pci), and the mmio_config_*() naming, so I've
been waiting to continue those discussions.  But maybe you're waiting for
me, too?

I think this sort of cleanup is a great idea and I hope we can make some
progress on it.  If it's easier to do it in small pieces, e.g., starting
out by moving code and renaming things with no functional changes, that
would be great with me.


Hi Bjorn,

It is not deadlock, it is rather me suffering with lack of time :)

I definitely want to make that cleanup happen and was about to start 
working on it again. Thanks for remanding me, patches/comments should 
come up soon.


Regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kprobes/x86: Use 5-byte NOP when the code might be modified by ftrace

[Masami Hiramatsu]

(2015/02/03 2:48), Petr Mladek wrote:
> can_probe() checks if the given address points to the beginning of
> an instruction. It analyzes all the instructions from the beginning
> of the function until the given address. The code might be modified
> by another Kprobe. In this case, the current code is read into a buffer,
> int3 breakpoint is replaced by the saved opcode in the buffer, and
> can_probe() analyzes the buffer instead.
> 
> There is a bug that __recover_probed_insn() tries to restore
> the original code even for Kprobes using the ftrace framework.
> But in this case, the opcode is not stored. See the difference
> between arch_prepare_kprobe() and arch_prepare_kprobe_ftrace().
> The opcode is stored by arch_copy_kprobe() only from
> arch_prepare_kprobe().
> 
> This patch makes Kprobe to use the ideal 5-byte NOP when the code
> can be modified by ftrace. It is the original instruction, see
> ftrace_make_nop() and ftrace_nop_replace().
> 
> Note that we always need to use the NOP for ftrace locations. Kprobes
> do not block ftrace and the instruction might get modified at anytime.
> It might even be in an inconsistent state because it is modified step
> by step using the int3 breakpoint.
> 
> The patch also fixes indentation of the touched comment.
> 
> Note that I found this problem when playing with Kprobes. I did it
> on x86_64 with gcc-4.8.3 that supported -mfentry. I modified
> samples/kprobes/kprobe_example.c and added offset 5 to put
> the probe right after the fentry area:
> 
> --- cut ---
>  static struct kprobe kp = {
>   .symbol_name= "do_fork",
> + .offset = 5,
>  };
> --- cut ---
> 
> Then I was able to load kprobe_example before jprobe_example
> but not the other way around:
> 
> $> modprobe jprobe_example
> $> modprobe kprobe_example
> modprobe: ERROR: could not insert 'kprobe_example': Invalid or incomplete 
> multibyte or wide character
> 
> It did not make much sense and debugging pointed to the bug
> described above.
> 

This looks good to me :)

Acked-by: Masami Hiramatsu 

Ingo, could you merge this as an urgent fix?

Thank you!

> Signed-off-by: Petr Mladek 
> ---
>  arch/x86/kernel/kprobes/core.c | 42 
> --
>  1 file changed, 28 insertions(+), 14 deletions(-)
> 
> Changes against v1:
> 
>   + always use 5-byte NOP for ftrace location
>   + fix indentation of the touched comment
> 
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 98f654d466e5..2f464b56766a 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -223,27 +223,41 @@ static unsigned long
>  __recover_probed_insn(kprobe_opcode_t *buf, unsigned long addr)
>  {
>   struct kprobe *kp;
> + unsigned long faddr;
>  
>   kp = get_kprobe((void *)addr);
> - /* There is no probe, return original address */
> - if (!kp)
> + faddr = ftrace_location(addr);
> + /*
> +  * Use the current code if it is not modified by Kprobe
> +  * and it cannot be modified by ftrace.
> +  */
> + if (!kp && !faddr)
>   return addr;
>  
>   /*
> -  *  Basically, kp->ainsn.insn has an original instruction.
> -  *  However, RIP-relative instruction can not do single-stepping
> -  *  at different place, __copy_instruction() tweaks the displacement of
> -  *  that instruction. In that case, we can't recover the instruction
> -  *  from the kp->ainsn.insn.
> +  * Basically, kp->ainsn.insn has an original instruction.
> +  * However, RIP-relative instruction can not do single-stepping
> +  * at different place, __copy_instruction() tweaks the displacement of
> +  * that instruction. In that case, we can't recover the instruction
> +  * from the kp->ainsn.insn.
>*
> -  *  On the other hand, kp->opcode has a copy of the first byte of
> -  *  the probed instruction, which is overwritten by int3. And
> -  *  the instruction at kp->addr is not modified by kprobes except
> -  *  for the first byte, we can recover the original instruction
> -  *  from it and kp->opcode.
> +  * On the other hand, in case on normal Kprobe, kp->opcode has a copy
> +  * of the first byte of the probed instruction, which is overwritten
> +  * by int3. And the instruction at kp->addr is not modified by kprobes
> +  * except for the first byte, we can recover the original instruction
> +  * from it and kp->opcode.
> +  *
> +  * In case of Kprobes using ftrace, we do not have a copy of
> +  * the original instruction. In fact, the ftrace location might
> +  * be modified at anytime and even could be in an inconsistent state.
> +  * Fortunately, we know that the original code is the ideal 5-byte
> +  * long NOP.
>*/
> - memcpy(buf, kp->addr, MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
> - buf[0] = kp->opcode;
> + memcpy(buf, (void *)addr, MAX_INSN_SIZE * 

[PATCH v3] gianfar: correct the bad expression while writing bit-pattern

[Sanjeev Sharma]

This patch correct the bad expression while writing the
bit-pattern from software's buffer to hardware registers.

Signed-off-by: Sanjeev Sharma 
---
Changes in v3:
  - corrected the expression by introducing tab->fe[i].prop.

 drivers/net/ethernet/freescale/gianfar_ethtool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/gianfar_ethtool.c 
b/drivers/net/ethernet/freescale/gianfar_ethtool.c
index 3e1a9c1..fda12fb 100644
--- a/drivers/net/ethernet/freescale/gianfar_ethtool.c
+++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c
@@ -1586,7 +1586,7 @@ static int gfar_write_filer_table(struct gfar_private 
*priv,
return -EBUSY;
 
/* Fill regular entries */
-   for (; i < MAX_FILER_IDX - 1 && (tab->fe[i].ctrl | tab->fe[i].ctrl);
+   for (; i < MAX_FILER_IDX - 1 && (tab->fe[i].ctrl | tab->fe[i].prop);
 i++)
gfar_write_filer(priv, i, tab->fe[i].ctrl, tab->fe[i].prop);
/* Fill the rest with fall-troughs */
-- 
1.7.11.7

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

Re: [RFC PATCH 1/8] nsproxy - refactor setns()

[Ian Kent]

Oops!
Please ignore these, mistakenly sent.

On Tue, 2015-02-03 at 15:16 +0800, Ian Kent wrote:
> For usermode helpers to execute within a namspace a slightly different
> entry point to setns() that takes a namspace inode is needed.
> 
> Signed-off-by: Ian Kent 
> Cc: Benjamin Coddington 
> Cc: Al Viro 
> Cc: J. Bruce Fields 
> Cc: David Howells 
> Cc: Trond Myklebust 
> Cc: Oleg Nesterov 
> Cc: Eric W. Biederman 
> Cc: Jeff Layton 
> ---
>  include/linux/nsproxy.h |1 +
>  kernel/nsproxy.c|   21 ++---
>  2 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/nsproxy.h b/include/linux/nsproxy.h
> index 35fa08f..c75bf12 100644
> --- a/include/linux/nsproxy.h
> +++ b/include/linux/nsproxy.h
> @@ -62,6 +62,7 @@ extern struct nsproxy init_nsproxy;
>   *
>   */
>  
> +int setns_inode(struct inode *inode, int nstype);
>  int copy_namespaces(unsigned long flags, struct task_struct *tsk);
>  void exit_task_namespaces(struct task_struct *tsk);
>  void switch_task_namespaces(struct task_struct *tsk, struct nsproxy *new);
> diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
> index 49746c8..27cc544 100644
> --- a/kernel/nsproxy.c
> +++ b/kernel/nsproxy.c
> @@ -218,20 +218,15 @@ void exit_task_namespaces(struct task_struct *p)
>   switch_task_namespaces(p, NULL);
>  }
>  
> -SYSCALL_DEFINE2(setns, int, fd, int, nstype)
> +int setns_inode(struct inode *inode, int nstype)
>  {
>   struct task_struct *tsk = current;
>   struct nsproxy *new_nsproxy;
> - struct file *file;
>   struct ns_common *ns;
>   int err;
>  
> - file = proc_ns_fget(fd);
> - if (IS_ERR(file))
> - return PTR_ERR(file);
> -
>   err = -EINVAL;
> - ns = get_proc_ns(file_inode(file));
> + ns = get_proc_ns(inode);
>   if (nstype && (ns->ops->type != nstype))
>   goto out;
>  
> @@ -248,6 +243,18 @@ SYSCALL_DEFINE2(setns, int, fd, int, nstype)
>   }
>   switch_task_namespaces(tsk, new_nsproxy);
>  out:
> + return err;
> +}
> +
> +SYSCALL_DEFINE2(setns, int, fd, int, nstype)
> +{
> + struct file *file;
> + int err;
> +
> + file = proc_ns_fget(fd);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> + err = setns_inode(file_inode(file), nstype);
>   fput(file);
>   return err;
>  }
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


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

linux-next: Tree for Feb 3

[Stephen Rothwell]

Hi all,

Changes since 20150202:

The target-updates tree gained a conflict against Linus' tree.

The clk tree gained conflicts against the arm-soc tree.

Non-merge commits (relative to Linus' tree): 7173
 7143 files changed, 301126 insertions(+), 167764 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 206 trees (counting Linus' and 30 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (e36f014edff7 Linux 3.19-rc7)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the 
debian/ directory)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (fba289054f24 ARM: 8298/1: ARM_KERNMEM_PERMS only 
works with MMU enabled)
CONFLICT (content): Merge conflict in arch/arm/mm/dma-mapping.c
Merging m68k-current/for-linus (f27bd5bfeda5 m68k: Wire up execveat)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused 
force_32bit_msi quirk)
Merging powerpc-merge-mpe/fixes (c59c961ca511 Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() 
needs to disable interrupts.)
Merging net/master (bdbbb8527b6f ipv4: tcp: get rid of ugly unicast_sock)
Merging ipsec/master (59343cd7c480 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging sound-current/for-linus (4161b4505f16 ALSA: ak411x: Fix stall in work 
callback)
Merging pci-current/for-linus (51ac3d2f0c50 PCI: Add NEC variants to Stratus 
ftServer PCIe DMI check)
Merging wireless-drivers/master (e3f31175a3ee ath9k: fix race condition in irq 
processing during hardware reset)
Merging driver-core.current/driver-core-linus (26bc420b59a3 Linux 3.19-rc6)
Merging tty.current/tty-linus (ec6f34e5b552 Linux 3.19-rc5)
Merging usb.current/usb-linus (e36f014edff7 Linux 3.19-rc7)
Merging usb-gadget-fixes/fixes (0df8fc37f6e4 usb: phy: never defer probe in 
non-OF case)
Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for 
RUGGEDCOM USB Serial Console)
Merging staging.current/staging-linus (e36f014edff7 Linux 3.19-rc7)
Merging char-misc.current/char-misc-linus (e36f014edff7 Linux 3.19-rc7)
Merging input-current/for-linus (47c1ffb2b6b6 Input: elantech - add more 
Fujtisu notebooks to force crc_enabled)
Merging crypto-current/master (3e14dcf7cb80 crypto: add missing crypto module 
aliases)
Merging ide/master (f96fe225677b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays 
with sub-devices tests)
Merging rr-fixes/fixes (d5db139ab376 module: make module_refcount() a signed 
integer.)
Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci 
device type in vfio_pci_probe())
Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for 
transhuge-stress test)
Merging drm-intel-fixes/for-linux-next-fixes (6b96d705f3cf drm/i915: BDW Fix 
Halo PCI IDs marked as ULT.)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (bdc99b3c7694 ARC: [axs101] Fix HDMI frequency divider for 
v3 m

[RFC PATCH 1/8] nsproxy - refactor setns()

[Ian Kent]

For usermode helpers to execute within a namspace a slightly different
entry point to setns() that takes a namspace inode is needed.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 include/linux/nsproxy.h |1 +
 kernel/nsproxy.c|   21 ++---
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/include/linux/nsproxy.h b/include/linux/nsproxy.h
index 35fa08f..c75bf12 100644
--- a/include/linux/nsproxy.h
+++ b/include/linux/nsproxy.h
@@ -62,6 +62,7 @@ extern struct nsproxy init_nsproxy;
  *
  */
 
+int setns_inode(struct inode *inode, int nstype);
 int copy_namespaces(unsigned long flags, struct task_struct *tsk);
 void exit_task_namespaces(struct task_struct *tsk);
 void switch_task_namespaces(struct task_struct *tsk, struct nsproxy *new);
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
index 49746c8..27cc544 100644
--- a/kernel/nsproxy.c
+++ b/kernel/nsproxy.c
@@ -218,20 +218,15 @@ void exit_task_namespaces(struct task_struct *p)
switch_task_namespaces(p, NULL);
 }
 
-SYSCALL_DEFINE2(setns, int, fd, int, nstype)
+int setns_inode(struct inode *inode, int nstype)
 {
struct task_struct *tsk = current;
struct nsproxy *new_nsproxy;
-   struct file *file;
struct ns_common *ns;
int err;
 
-   file = proc_ns_fget(fd);
-   if (IS_ERR(file))
-   return PTR_ERR(file);
-
err = -EINVAL;
-   ns = get_proc_ns(file_inode(file));
+   ns = get_proc_ns(inode);
if (nstype && (ns->ops->type != nstype))
goto out;
 
@@ -248,6 +243,18 @@ SYSCALL_DEFINE2(setns, int, fd, int, nstype)
}
switch_task_namespaces(tsk, new_nsproxy);
 out:
+   return err;
+}
+
+SYSCALL_DEFINE2(setns, int, fd, int, nstype)
+{
+   struct file *file;
+   int err;
+
+   file = proc_ns_fget(fd);
+   if (IS_ERR(file))
+   return PTR_ERR(file);
+   err = setns_inode(file_inode(file), nstype);
fput(file);
return err;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 PATCH 2/8] kmod - rename call_usermodehelper() flags parameter

[Ian Kent]

The wait parameter of call_usermodehelper() is not quite a parameter
that describes the wait behaviour alone and will later be used to
request exec within a namespace.

So change its name to flags.

Signed-off-by: Ian Kent 
Cc: Benjamin Coddington 
Cc: Al Viro 
Cc: J. Bruce Fields 
Cc: David Howells 
Cc: Trond Myklebust 
Cc: Oleg Nesterov 
Cc: Eric W. Biederman 
Cc: Jeff Layton 
---
 include/linux/kmod.h |4 ++--
 kernel/kmod.c|   16 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index 0555cc6..15bdeed 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -67,7 +67,7 @@ struct subprocess_info {
 };
 
 extern int
-call_usermodehelper(char *path, char **argv, char **envp, int wait);
+call_usermodehelper(char *path, char **argv, char **envp, int flags);
 
 extern struct subprocess_info *
 call_usermodehelper_setup(char *path, char **argv, char **envp, gfp_t gfp_mask,
@@ -75,7 +75,7 @@ call_usermodehelper_setup(char *path, char **argv, char 
**envp, gfp_t gfp_mask,
  void (*cleanup)(struct subprocess_info *), void 
*data);
 
 extern int
-call_usermodehelper_exec(struct subprocess_info *info, int wait);
+call_usermodehelper_exec(struct subprocess_info *info, int flags);
 
 extern struct ctl_table usermodehelper_table[];
 
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 2777f40..14c0188 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -534,7 +534,7 @@ EXPORT_SYMBOL(call_usermodehelper_setup);
  * asynchronously if wait is not set, and runs as a child of keventd.
  * (ie. it runs with full root capabilities).
  */
-int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
+int call_usermodehelper_exec(struct subprocess_info *sub_info, int flags)
 {
DECLARE_COMPLETION_ONSTACK(done);
int retval = 0;
@@ -553,14 +553,14 @@ int call_usermodehelper_exec(struct subprocess_info 
*sub_info, int wait)
 * This makes it possible to use umh_complete to free
 * the data structure in case of UMH_NO_WAIT.
 */
-   sub_info->complete = (wait == UMH_NO_WAIT) ? NULL : 
-   sub_info->wait = wait;
+   sub_info->complete = (flags == UMH_NO_WAIT) ? NULL : 
+   sub_info->wait = flags;
 
queue_work(khelper_wq, _info->work);
-   if (wait == UMH_NO_WAIT)/* task has freed sub_info */
+   if (flags == UMH_NO_WAIT)   /* task has freed sub_info */
goto unlock;
 
-   if (wait & UMH_KILLABLE) {
+   if (flags & UMH_KILLABLE) {
retval = wait_for_completion_killable();
if (!retval)
goto wait_done;
@@ -595,17 +595,17 @@ EXPORT_SYMBOL(call_usermodehelper_exec);
  * This function is the equivalent to use call_usermodehelper_setup() and
  * call_usermodehelper_exec().
  */
-int call_usermodehelper(char *path, char **argv, char **envp, int wait)
+int call_usermodehelper(char *path, char **argv, char **envp, int flags)
 {
struct subprocess_info *info;
-   gfp_t gfp_mask = (wait == UMH_NO_WAIT) ? GFP_ATOMIC : GFP_KERNEL;
+   gfp_t gfp_mask = (flags == UMH_NO_WAIT) ? GFP_ATOMIC : GFP_KERNEL;
 
info = call_usermodehelper_setup(path, argv, envp, gfp_mask,
 NULL, NULL, NULL);
if (info == NULL)
return -ENOMEM;
 
-   return call_usermodehelper_exec(info, wait);
+   return call_usermodehelper_exec(info, flags);
 }
 EXPORT_SYMBOL(call_usermodehelper);
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] change non-atomic bitops method

[Wang, Yalin]

> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Tuesday, February 03, 2015 2:39 PM
> To: Wang, Yalin
> Cc: 'Kirill A. Shutemov'; 'a...@arndb.de'; 'linux-a...@vger.kernel.org';
> 'linux-kernel@vger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
> 
> On Tue, 3 Feb 2015 13:42:45 +0800 "Wang, Yalin" 
> wrote:
> >
> > ...
> >
> > #ifdef CHECK_BEFORE_SET
> > if (p[i] != times)
> > #endif
> >
> > ...
> >
> > 
> > One run on CPU0, reader thread run on CPU1,
> > Test result:
> > sudo ./cache_test
> > reader:8.426228173
> > 8.672198335
> >
> > With -DCHECK_BEFORE_SET
> > sudo ./cache_test_check
> > reader:7.537036819
> > 10.799746531
> >
> 
> You aren't measuring the right thing.  You should compare
> 
>   if (p[i] != x)
>   p[i] = x;
> 
> versus
> 
>   p[i] = x;
> 
> and you should do this for two cases:
> 
> a) p[i] == x
> 
> b) p[i] != x
> 
> 
> The first code sequence will be slower when (p[i] != x) and faster when
> (p[i] == x).
> 
> 
> Next, we should instrument the kernel to work out the frequency of
> set_bit on an already-set bit.
> 
> It is only with both these ratios that we can work out whether the
> patch is a net gain.  My suspicion is that set_bit on an already-set
> bit is so rare that the patch will be a loss.
I see, let's change the test a little:
1)
memset(p, 0, SIZE);
if (p[i] != 0)
p[i] = 0;  // never called

#sudo ./cache_test_check
6.698153838
reader:7.529402625


2)
memset(p, 0, SIZE);
if (p[i] == 0)
p[i] = 0; // always called
#sudo ./cache_test_check
reader:7.895421311
9.000889973

Thanks




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

Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances

[Tomeu Vizoso]

On 02/02/2015 11:41 PM, Mike Turquette wrote:
> Quoting Tero Kristo (2015-02-02 11:32:01)
>> On 02/01/2015 11:24 PM, Mike Turquette wrote:
>>> Quoting Tomeu Vizoso (2015-01-23 03:03:30)
 Moves clock state to struct clk_core, but takes care to change as little 
 API as
 possible.

 struct clk_hw still has a pointer to a struct clk, which is the
 implementation's per-user clk instance, for backwards compatibility.

 The struct clk that clk_get_parent() returns isn't owned by the caller, 
 but by
 the clock implementation, so the former shouldn't call clk_put() on it.

 Because some boards in mach-omap2 still register clocks statically, their 
 clock
 registration had to be updated to take into account that the clock 
 information
 is stored in struct clk_core now.
>>>
>>> Tero, Paul & Tony,
>>>
>>> Tomeu's patch unveils a problem with omap3_noncore_dpll_enable and
>>> struct dpll_data, namely this snippet from
>>> arch/arm/mach-omap2/dpll3xxx.c:
>>>
>>>  parent = __clk_get_parent(hw->clk);
>>>
>>>  if (__clk_get_rate(hw->clk) == __clk_get_rate(dd->clk_bypass)) {
>>>  WARN(parent != dd->clk_bypass,
>>>  "here0, parent name is %s, bypass name is 
>>> %s\n",
>>>  __clk_get_name(parent), 
>>> __clk_get_name(dd->clk_bypass));
>>>  r = _omap3_noncore_dpll_bypass(clk);
>>>  } else {
>>>  WARN(parent != dd->clk_ref,
>>>  "here1, parent name is %s, ref name is 
>>> %s\n",
>>>  __clk_get_name(parent), 
>>> __clk_get_name(dd->clk_ref));
>>>  r = _omap3_noncore_dpll_lock(clk);
>>>  }
>>>
>>> struct dpll_data has members clk_ref and clk_bypass which are struct clk
>>> pointers. This was always a bit of a violation of the clk.h contract
>>> since drivers are not supposed to deref struct clk pointers. Now that we
>>> generate unique pointers for each call to clk_get (clk_ref & clk_bypass
>>> are populated by of_clk_get in ti_clk_register_dpll) then the pointer
>>> comparisons above will never be equal (even if they resolve down to the
>>> same struct clk_core). I added the verbose traces to the WARNs above to
>>> illustrate the point: the names are always the same but the pointers
>>> differ.
>>>
>>> AFAICT this doesn't break anything, but booting on OMAP3+ results in
>>> noisy WARNs.
>>>
>>> I think the correct fix is to replace clk_bypass and clk_ref pointers
>>> with a simple integer parent_index. In fact we already have this index.
>>> See how the pointers are populated in ti_clk_register_dpll:
>>
>> The problem is we still need to be able to get runtime parent clock 
>> rates (the parent rate may change also), so simple index value is not 
>> sufficient. We need a handle of some sort to the bypass/ref clocks. The 
>> DPLL code generally requires knowledge of the bypass + reference clock 
>> rates to work properly, as it calculates the M/N values based on these.
> 
> We can maybe introduce something like of_clk_get_parent_rate, as we have
> analogous stuff for getting parent names and indexes. Without
> introducing a new helper you could probably just do:
> 
>   clk_ref = clk_get_parent_by_index(dpll_clk, 0);
>   ref_rate = clk_get_rate(clk_ref);
> 
>   clk_bypass = clk_get_parent_by_index(dpll_clk, 1);
>   bypass_rate = clk_get_rate(clk_bypass);
> 
> Currently the semantics around this call are weird. It seems like it
> would create a new struct clk pointer but it does not. So don't call
> clk_put on clk_ref and clk_bypass yet. That might change in the future
> as we iron out this brave new world that we all live in. Probably best
> to leave a FIXME in there.
> 
> Stephen & Tomeu, let me know if I got any of that wrong.

I think you got it right, just wanted to mention that we can and
probably should make the clk_get_parent_* calls in the consumer API to
return per-user clk instances but that we need to make sure first that
callers call clk_put afterwards.

This should also allow us to remove the reference to struct clk from
clk_hw, which is at best awkward.

Regards,

Tomeu

>>
>> Shall I change the DPLL code to check against clk_hw pointers or what is 
>> the preferred approach here? The patch at the end does this and fixes 
>> the dpll related warnings.
> 
> Yes, for now that is fine, but feels a bit hacky to me. I don't know
> honestly, let me sleep on it. Anyways for 3.20 that is perfectly fine
> but we might want to switch to something like the scheme above.
> 
>>
>> Btw, the rate constraints patch broke boot for me completely, but sounds 
>> like you reverted it already.
> 
> Fixed with Stephen's patch from last week. Thanks for dealing with all
> the breakage so promptly. It has helped a lot!
> 
> Regards,
> Mike
> 
>>
>> -Tero
>>
>> 
>>
>> Author: Tero Kristo 
>> Date:   Mon Feb 2 17:19:17 

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 03.02.2015 um 07:05 schrieb Al Viro:
> On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote:
>> +if (inode) {
>> +// TODO:
>> +// if (inode is file and 's' flag is set)
>> +//  secure = true;
>> +if (!secure)
>> +iput(inode);/* truncate the inode here */
>> +else {
>> +struct super_block *sb = inode->i_sb;
>> +if (sb->s_op->set_secure_delete)
>> +sb->s_op->set_secure_delete(sb, true);
>> +// TODO: We should fail if secure isn't supported,
>> +// look up how that's possible here.
>> +iput(inode);/* truncate the inode here */
>> +// TODO: check if sb is still valid after the inode is 
>> gone
>> +sync_filesystem(sb);
>> +if (sb->s_op->set_secure_delete)
>> +sb->s_op->set_secure_delete(sb, false);
>> +}
> 
> Charming.  Now, what exactly happens if two such syscalls overlap in time?

What do you think will happen? I assume you haven't looked at how I've
implemented set_secure_delete(). CHarming.

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

Re: [RFC PATCH v3 3/3] mm/compaction: enhance compaction finish condition

[Joonsoo Kim]

On Mon, Feb 02, 2015 at 09:51:01PM +0800, Zhang Yanfei wrote:
> Hello,
> 
> At 2015/2/2 18:20, Vlastimil Babka wrote:
> > On 02/02/2015 08:15 AM, Joonsoo Kim wrote:
> >> Compaction has anti fragmentation algorithm. It is that freepage
> >> should be more than pageblock order to finish the compaction if we don't
> >> find any freepage in requested migratetype buddy list. This is for
> >> mitigating fragmentation, but, there is a lack of migratetype
> >> consideration and it is too excessive compared to page allocator's anti
> >> fragmentation algorithm.
> >>
> >> Not considering migratetype would cause premature finish of compaction.
> >> For example, if allocation request is for unmovable migratetype,
> >> freepage with CMA migratetype doesn't help that allocation and
> >> compaction should not be stopped. But, current logic regards this
> >> situation as compaction is no longer needed, so finish the compaction.
> > 
> > This is only for order >= pageblock_order, right? Perhaps should be told 
> > explicitly.
> 
> I might be wrong. If we applied patch1, so after the system runs for some 
> time,
> there must be no MIGRATE_CMA free pages in the system, right? If so, the
> example above doesn't exist anymore.

Hello,

Compaction could migrate all pages on MIGRATE_CMA pageblock, and,
in this case, order >= pageblock_order could be true. And, cma freepages
are used only for fallback so even if applying patch1, it could be possible.

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: [RFC PATCH 0/5] compaction: changing initial position of scanners

[Joonsoo Kim]

On Mon, Jan 19, 2015 at 11:05:15AM +0100, Vlastimil Babka wrote:
> Even after all the patches compaction received in last several versions, it
> turns out that its effectivneess degrades considerably as the system ages
> after reboot. For example, see how success rates of stress-highalloc from
> mmtests degrades when we re-execute it several times, first time being after
> fresh reboot:
>  3.19-rc4  3.19-rc4  
> 3.19-rc4
> 4-nothp-1 4-nothp-2 
> 4-nothp-3
> Success 1 Min 25.00 (  0.00%)   13.00 ( 48.00%)9.00 ( 
> 64.00%)
> Success 1 Mean36.20 (  0.00%)   23.40 ( 35.36%)   16.40 ( 
> 54.70%)
> Success 1 Max 41.00 (  0.00%)   34.00 ( 17.07%)   25.00 ( 
> 39.02%)
> Success 2 Min 25.00 (  0.00%)   15.00 ( 40.00%)   10.00 ( 
> 60.00%)
> Success 2 Mean37.20 (  0.00%)   25.00 ( 32.80%)   17.20 ( 
> 53.76%)
> Success 2 Max 44.00 (  0.00%)   36.00 ( 18.18%)   25.00 ( 
> 43.18%)
> Success 3 Min 84.00 (  0.00%)   81.00 (  3.57%)   78.00 (  
> 7.14%)
> Success 3 Mean85.80 (  0.00%)   82.80 (  3.50%)   80.40 (  
> 6.29%)
> Success 3 Max 87.00 (  0.00%)   84.00 (  3.45%)   82.00 (  
> 5.75%)
> 
> Wouldn't it be much better, if it looked like this?
> 
>3.18  3.18  3.18
>  3.19-rc4  3.19-rc4  
> 3.19-rc4
> 5-nothp-1 5-nothp-2 
> 5-nothp-3
> Success 1 Min 49.00 (  0.00%)   42.00 ( 14.29%)   41.00 ( 
> 16.33%)
> Success 1 Mean51.00 (  0.00%)   45.00 ( 11.76%)   42.60 ( 
> 16.47%)
> Success 1 Max 55.00 (  0.00%)   51.00 (  7.27%)   46.00 ( 
> 16.36%)
> Success 2 Min 53.00 (  0.00%)   47.00 ( 11.32%)   44.00 ( 
> 16.98%)
> Success 2 Mean59.60 (  0.00%)   50.80 ( 14.77%)   48.20 ( 
> 19.13%)
> Success 2 Max 64.00 (  0.00%)   56.00 ( 12.50%)   52.00 ( 
> 18.75%)
> Success 3 Min 84.00 (  0.00%)   82.00 (  2.38%)   78.00 (  
> 7.14%)
> Success 3 Mean85.60 (  0.00%)   82.80 (  3.27%)   79.40 (  
> 7.24%)
> Success 3 Max 86.00 (  0.00%)   83.00 (  3.49%)   80.00 (  
> 6.98%)
> 
> In my humble opinion, it would :) Much lower degradation, and a nice
> improvement in the first iteration as a bonus.
> 
> So what sorcery is this? Nothing much, just a fundamental change of the
> compaction scanners operation...
> 
> As everyone knows [1] the migration scanner starts at the first pageblock
> of a zone, and goes towards the end, and the free scanner starts at the
> last pageblock and goes towards the beginning. Somewhere in the middle of the
> zone, the scanners meet:
> 
>zone_start   zone_end
>|   |
>-
>M| =><= |
>migrate_pfn free_pfn
> 
> In my tests, the scanners meet around the middle of the pageblock on the first
> iteration, and around the 1/3 on subsequent iterations. Which means the
> migration scanner doesn't see the larger part of the zone at all. For more
> details why it's bad, see Patch 4 description.
> 
> To make sure we eventually scan the whole zone with the migration scanner, we
> could e.g. reverse the directions after each run. But that would still be
> biased, and with 1/3 of zone reachable from each side, we would still omit the
> middle 1/3 of a zone.
> 
> Or we could stop terminating compaction when the scanners meet, and let them
> continue to scan the whole zone. Mel told me it used to be the case long ago,
> but that approach would result in migrating pages back and forth during single
> compaction run, which wouldn't be cool.
> 
> So the approach taken by this patchset is to let scanners start at any
> so-called pivot pfn within the zone, and keep their direction:
> 
>zone_start pivot zone_end
>||  |
>-
>  <= |FFFMM| =>
> free_pfn migrate_pfn
> 
> Eventually, one of the scanners will reach the zone boundary and wrap around,
> e.g. the in the case of the free scanner:
> 
>zone_start pivot zone_end
>||  |
>-
>F| =>   <= 

[PATCH] arch/cpuidle-powernv: Avoid endianness conversions while parsing DT

[Preeti U Murthy]

We currently read the information about idle states from the DT
so as to find out the cpu idle states supported by the platform.
Use those APIs to read from the DT that can avoid endianness
conversions of the property values.

Signed-off-by: Preeti U Murthy 
---

 arch/powerpc/platforms/powernv/setup.c |   35 ++--
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index d2de7d5..39d1971 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -409,37 +409,39 @@ static int __init pnv_init_idle_states(void)
 {
struct device_node *power_mgt;
int dt_idle_states;
-   const __be32 *idle_state_flags;
-   u32 len_flags, flags;
+   u32 *flags;
int i;
 
supported_cpuidle_states = 0;
 
if (cpuidle_disable != IDLE_NO_OVERRIDE)
-   return 0;
+   goto out;
 
if (!firmware_has_feature(FW_FEATURE_OPALv3))
-   return 0;
+   goto out;
 
power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
if (!power_mgt) {
pr_warn("opal: PowerMgmt Node not found\n");
-   return 0;
+   goto out;
+   }
+   dt_idle_states = of_property_count_u32_elems(power_mgt,
+   "ibm,cpu-idle-state-flags");
+   if (dt_idle_states < 0) {
+   pr_warn("cpuidle-powernv: no idle states found in the DT\n");
+   goto out;
}
 
-   idle_state_flags = of_get_property(power_mgt,
-   "ibm,cpu-idle-state-flags", _flags);
-   if (!idle_state_flags) {
-   pr_warn("DT-PowerMgmt: missing ibm,cpu-idle-state-flags\n");
-   return 0;
+   flags = kzalloc(sizeof(*flags) * dt_idle_states, GFP_KERNEL);
+   if (of_property_read_u32_array(power_mgt,
+   "ibm,cpu-idle-state-flags", flags, dt_idle_states)) {
+   pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-flags in 
DT\n");
+   goto out_free;
}
 
-   dt_idle_states = len_flags / sizeof(u32);
+   for (i = 0; i < dt_idle_states; i++)
+   supported_cpuidle_states |= flags[i];
 
-   for (i = 0; i < dt_idle_states; i++) {
-   flags = be32_to_cpu(idle_state_flags[i]);
-   supported_cpuidle_states |= flags;
-   }
if (!(supported_cpuidle_states & OPAL_PM_SLEEP_ENABLED_ER1)) {
patch_instruction(
(unsigned int *)pnv_fastsleep_workaround_at_entry,
@@ -449,6 +451,9 @@ static int __init pnv_init_idle_states(void)
PPC_INST_NOP);
}
pnv_alloc_idle_core_states();
+out_free:
+   kfree(flags);
+out:
return 0;
 }
 

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

Re: [RFC] change non-atomic bitops method

[Andrew Morton]

On Tue, 3 Feb 2015 13:42:45 +0800 "Wang, Yalin"  
wrote:
>
> ...
>
> #ifdef CHECK_BEFORE_SET
>   if (p[i] != times)
> #endif
>
> ...
>
> 
> One run on CPU0, reader thread run on CPU1,
> Test result:
> sudo ./cache_test
> reader:8.426228173
> 8.672198335
> 
> With -DCHECK_BEFORE_SET
> sudo ./cache_test_check
> reader:7.537036819
> 10.799746531
> 

You aren't measuring the right thing.  You should compare

if (p[i] != x)
p[i] = x;

versus

p[i] = x;

and you should do this for two cases:

a) p[i] == x

b) p[i] != x


The first code sequence will be slower when (p[i] != x) and faster when
(p[i] == x).


Next, we should instrument the kernel to work out the frequency of
set_bit on an already-set bit.

It is only with both these ratios that we can work out whether the
patch is a net gain.  My suspicion is that set_bit on an already-set
bit is so rare that the patch will be a loss.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] driver/cpuidle-powernv: Avoid endianness conversions while parsing DT

[Preeti U Murthy]

We currently read the information about idle states from the DT
so as to populate the cpuidle table. Use those APIs to read from
the DT that can avoid endianness conversions of the property values
in the cpuidle driver.

Signed-off-by: Preeti U Murthy 
---
This patch is based ontop of the mainline + V4 of "cpuidle/powernv:
Read target_residency value of idle states from DT if available".

 drivers/cpuidle/cpuidle-powernv.c |   30 --
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index 3aa27a0..4f76fc7 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -161,9 +161,7 @@ static int powernv_add_idle_states(void)
struct device_node *power_mgt;
int nr_idle_states = 1; /* Snooze */
int dt_idle_states;
-   const __be32 *idle_state_flags;
-   u32 len_flags, flags;
-   u32 *latency_ns, *residency_ns;
+   u32 *latency_ns, *residency_ns, *flags;
int i, rc;
 
/* Currently we have snooze statically defined */
@@ -174,15 +172,19 @@ static int powernv_add_idle_states(void)
goto out;
}
 
-   idle_state_flags = of_get_property(power_mgt,
-   "ibm,cpu-idle-state-flags", _flags);
-   if (!idle_state_flags) {
-   pr_warn("cpuidle-powernv : missing
-   ibm,cpu-idle-state-flags in DT\n");
+   /* Read values of any property to determine the num of idle states */
+   dt_idle_states = of_property_count_u32_elems(power_mgt, 
"ibm,cpu-idle-state-flags");
+   if (dt_idle_states < 0) {
+   pr_warn("cpuidle-powernv: no idle states found in the DT\n");
goto out;
}
 
-   dt_idle_states = len_flags / sizeof(u32);
+   flags = kzalloc(sizeof(*flags) * dt_idle_states, GFP_KERNEL);
+   if (of_property_read_u32_array(power_mgt,
+   "ibm,cpu-idle-state-flags", flags, dt_idle_states)) {
+   pr_warn("cpuidle-powernv : missing ibm,cpu-idle-state-flags in 
DT\n");
+   goto out_free_flags;
+   }
 
latency_ns = kzalloc(sizeof(*latency_ns) * dt_idle_states, GFP_KERNEL);
rc = of_property_read_u32_array(power_mgt,
@@ -199,21 +201,19 @@ static int powernv_add_idle_states(void)
 
for (i = 0; i < dt_idle_states; i++) {
 
-   flags = be32_to_cpu(idle_state_flags[i]);
-
/*
 * Cpuidle accepts exit_latency and target_residency in us.
 * Use default target_residency values if f/w does not expose 
it.
 */
-   if (flags & OPAL_PM_NAP_ENABLED) {
+   if (flags[i] & OPAL_PM_NAP_ENABLED) {
/* Add NAP state */
strcpy(powernv_states[nr_idle_states].name, "Nap");
strcpy(powernv_states[nr_idle_states].desc, "Nap");
powernv_states[nr_idle_states].flags = 0;
powernv_states[nr_idle_states].target_residency = 100;
powernv_states[nr_idle_states].enter = _loop;
-   } else if (flags & OPAL_PM_SLEEP_ENABLED ||
-   flags & OPAL_PM_SLEEP_ENABLED_ER1) {
+   } else if (flags[i] & OPAL_PM_SLEEP_ENABLED ||
+   flags[i] & OPAL_PM_SLEEP_ENABLED_ER1) {
/* Add FASTSLEEP state */
strcpy(powernv_states[nr_idle_states].name, 
"FastSleep");
strcpy(powernv_states[nr_idle_states].desc, 
"FastSleep");
@@ -236,6 +236,8 @@ static int powernv_add_idle_states(void)
kfree(residency_ns);
 out_free_latency:
kfree(latency_ns);
+out_free_flags:
+   kfree(flags);
 out:
return nr_idle_states;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V4] cpuidle/powernv: Read target_residency value of idle states from DT if available

[Preeti U Murthy]

The device tree now exposes the residency values for different idle states. Read
these values instead of calculating residency from the latency values. The 
values
exposed in the DT are validated for optimal power efficiency. However to 
maintain
compatibility with the older firmware code which does not expose residency
values, use default values as a fallback mechanism. While at it, use better
APIs to parse the powermgmt device tree node.

Signed-off-by: Preeti U Murthy 
Acked-by: Stewart Smith 
Acked-by: Michael Ellerman 
---
Changes from the previous versions: https://lkml.org/lkml/2015/2/2/12
1. Used better APIs
2. Code Cleanups
3. Reverted back to the V2 of this patch as suggested in the above link,
in addition to a few cleanups and carried forward the Acks from V2

 drivers/cpuidle/cpuidle-powernv.c |   71 ++---
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/cpuidle/cpuidle-powernv.c 
b/drivers/cpuidle/cpuidle-powernv.c
index 2726663..3aa27a0 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -161,69 +162,81 @@ static int powernv_add_idle_states(void)
int nr_idle_states = 1; /* Snooze */
int dt_idle_states;
const __be32 *idle_state_flags;
-   const __be32 *idle_state_latency;
-   u32 len_flags, flags, latency_ns;
-   int i;
+   u32 len_flags, flags;
+   u32 *latency_ns, *residency_ns;
+   int i, rc;
 
/* Currently we have snooze statically defined */
 
power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
if (!power_mgt) {
pr_warn("opal: PowerMgmt Node not found\n");
-   return nr_idle_states;
+   goto out;
}
 
-   idle_state_flags = of_get_property(power_mgt, 
"ibm,cpu-idle-state-flags", _flags);
+   idle_state_flags = of_get_property(power_mgt,
+   "ibm,cpu-idle-state-flags", _flags);
if (!idle_state_flags) {
-   pr_warn("DT-PowerMgmt: missing ibm,cpu-idle-state-flags\n");
-   return nr_idle_states;
+   pr_warn("cpuidle-powernv : missing
+   ibm,cpu-idle-state-flags in DT\n");
+   goto out;
}
 
-   idle_state_latency = of_get_property(power_mgt,
-   "ibm,cpu-idle-state-latencies-ns", NULL);
-   if (!idle_state_latency) {
-   pr_warn("DT-PowerMgmt: missing 
ibm,cpu-idle-state-latencies-ns\n");
-   return nr_idle_states;
+   dt_idle_states = len_flags / sizeof(u32);
+
+   latency_ns = kzalloc(sizeof(*latency_ns) * dt_idle_states, GFP_KERNEL);
+   rc = of_property_read_u32_array(power_mgt,
+   "ibm,cpu-idle-state-latencies-ns", latency_ns, dt_idle_states);
+   if (rc) {
+   pr_warn("cpuidle-powernv: missing
+   ibm,cpu-idle-state-latencies-ns in DT\n");
+   goto out_free_latency;
}
 
-   dt_idle_states = len_flags / sizeof(u32);
+   residency_ns = kzalloc(sizeof(*residency_ns) * dt_idle_states, 
GFP_KERNEL);
+   rc = of_property_read_u32_array(power_mgt,
+   "ibm,cpu-idle-state-residency-ns", residency_ns, 
dt_idle_states);
 
for (i = 0; i < dt_idle_states; i++) {
 
flags = be32_to_cpu(idle_state_flags[i]);
 
-   /* Cpuidle accepts exit_latency in us and we estimate
-* target residency to be 10x exit_latency
+   /*
+* Cpuidle accepts exit_latency and target_residency in us.
+* Use default target_residency values if f/w does not expose 
it.
 */
-   latency_ns = be32_to_cpu(idle_state_latency[i]);
if (flags & OPAL_PM_NAP_ENABLED) {
/* Add NAP state */
strcpy(powernv_states[nr_idle_states].name, "Nap");
strcpy(powernv_states[nr_idle_states].desc, "Nap");
powernv_states[nr_idle_states].flags = 0;
-   powernv_states[nr_idle_states].exit_latency =
-   ((unsigned int)latency_ns) / 1000;
-   powernv_states[nr_idle_states].target_residency =
-   ((unsigned int)latency_ns / 100);
+   powernv_states[nr_idle_states].target_residency = 100;
powernv_states[nr_idle_states].enter = _loop;
-   nr_idle_states++;
-   }
-
-   if (flags & OPAL_PM_SLEEP_ENABLED ||
+   } else if (flags & OPAL_PM_SLEEP_ENABLED ||
flags & OPAL_PM_SLEEP_ENABLED_ER1) {
/* Add FASTSLEEP state */
strcpy(powernv_states[nr_idle_states].name, 

Re: nvram and generic_nvram modules are problematic, was Re: [PATCH] arch: m68k: mac: misc.c: Remove some unused functions

[Finn Thain]

On Sun, 1 Feb 2015, Russell King - ARM Linux wrote:

> On Sun, Feb 01, 2015 at 02:39:42PM +1100, Finn Thain wrote:
> > I find the ARM support in drivers/char/nvram to be surprising, not to 
> > say questionable. The /proc/driver/nvram implementation, given 
> > defined(__arm__), decodes the NVRAM contents in exactly the same 
> > format as when defined(__i386__) || defined(__x86_64__).
> 
> That's because it's used on the Netwinder and EBSA285 platforms, which 
> are PCI-like, complete with a southbridge which makes them look like a 
> PC.

Well, that explains the presence of RTC NVRAM, but the question was also 
about the format of that NVRAM.

The the code in question in drivers/char/nvram.c decodes RTC NVRAM on ARM 
as if it took the same format as x86 PC RTC NVRAM. Apparently they are not 
in the same format (for EBSA-285 at least).

I downloaded the EBSA-285 BIOS,
ftp://ftp.arm.linux.org.uk/pub/armlinux/source/boot/bios-1.11.tar.gz

This is from bios/init/cfg.c --

img_nr = rtc_read_cmos(0);
root_dev = rtc_read_cmos(2) | rtc_read_cmos(3) << 8;

for (i = 0; i < 80; i++) {
extra_args[i] = rtc_read_cmos(128+i);
if (!extra_args[i])
break;
}
extra_args[79] = '\0';

(Like /dev/nvram, file offset 0 is actually device offset 14.)

This EBSA-285 BIOS code uses bytes 128 through 208 as "extra_args", 
whereas /dev/nvram has only 114 bytes in total. The EBSA-285 BIOS doesn't 
read or write any checksum.

The first two bytes aren't reported in /proc/driver/nvram, whereas 
EBSA-285 BIOS uses them for img_nr and root_dev. The next one is reported 
as "floppy type" on x86 PC, though the EBSA-285 BIOS uses it for 
root_dev >> 8.

This is from an x86 PC, for example:

# cat /proc/driver/nvram 
Checksum status: valid
# floppies : 1
Floppy 0 type  : none
Floppy 1 type  : none
HD 0 type  : 01
HD 1 type  : none
HD type 48 data: 512/0/0 C/H/S, precomp 0, lz 256
HD type 49 data: 1/124/0 C/H/S, precomp 0, lz 0
DOS base memory: 640 kB
Extended memory: 64512 kB (configured), 64512 kB (tested)
Gfx adapter: EGA, VGA, ... (with BIOS)
FPU: installed

My original question was whether the CONFIG_PROC_FS support found in 
drivers/char/nvram.c should be moved to arch/x86 and arch/m68k.

So that question now seems to hinge on the Netwinder ROM ("nettrom") which 
I gather is proprietary (I didn't find any source code). Does anyone know 
what format the Netwinder NVRAM takes?

If NVRAM on Netwinder has a different format to x86 PC, then the 
CONFIG_PROC_FS code in drivers/char/nvram should go elsewhere.

And if the NVRAM on Netwinder had no checksum, drivers/char/nvram.c would 
become a generic /dev/nvram misc device, and drivers/char/generic_nvram.c 
could go away, along with its inherent problems.

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Al Viro]

On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote:
> + if (inode) {
> + // TODO:
> + // if (inode is file and 's' flag is set)
> + //  secure = true;
> + if (!secure)
> + iput(inode);/* truncate the inode here */
> + else {
> + struct super_block *sb = inode->i_sb;
> + if (sb->s_op->set_secure_delete)
> + sb->s_op->set_secure_delete(sb, true);
> + // TODO: We should fail if secure isn't supported,
> + // look up how that's possible here.
> + iput(inode);/* truncate the inode here */
> + // TODO: check if sb is still valid after the inode is 
> gone
> + sync_filesystem(sb);
> + if (sb->s_op->set_secure_delete)
> + sb->s_op->set_secure_delete(sb, false);
> + }

Charming.  Now, what exactly happens if two such syscalls overlap in time?
Moroever, what makes you equate unlink() with inode removal?  What happens
if you race e.g. with stat(2) on the same thing?  Or if there's an opened
file over that sucker, for that 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/

Re: [PATCH v2] i7core_edac: release resources on error in i7core_create_sysfs_devices

[Junjie Mao]

Guenter Roeck  writes:

> On Tue, Feb 03, 2015 at 10:40:14AM +0800, Junjie Mao wrote:
>> v2: do not call kfree on allocated devs after device_initialize is called
>> 
>> Signed-off-by: Junjie Mao 
>> ---
>>  drivers/edac/i7core_edac.c | 37 +
>>  1 file changed, 25 insertions(+), 12 deletions(-)
>> 
>> diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
>> index 9cd0b301f81b..f6a7b676d69c 100644
>> --- a/drivers/edac/i7core_edac.c
>> +++ b/drivers/edac/i7core_edac.c
>> @@ -1167,17 +1167,17 @@ static int i7core_create_sysfs_devices(struct 
>> mem_ctl_info *mci)
>>  return rc;
>>  rc = device_create_file(>dev, _attr_inject_type);
>>  if (rc < 0)
>> -return rc;
>> +goto fail_remove_inject_section;
>>  rc = device_create_file(>dev, _attr_inject_eccmask);
>>  if (rc < 0)
>> -return rc;
>> +goto fail_remove_inject_type;
>>  rc = device_create_file(>dev, _attr_inject_enable);
>>  if (rc < 0)
>> -return rc;
>> +goto fail_remove_inject_eccmask;
>> 
>>  pvt->addrmatch_dev = kzalloc(sizeof(*pvt->addrmatch_dev), GFP_KERNEL);
>>  if (!pvt->addrmatch_dev)
>> -return rc;
>> +goto fail_remove_inject_enable;
>> 
>>  pvt->addrmatch_dev->type = _type;
>>  pvt->addrmatch_dev->bus = mci->dev.bus;
>> @@ -1190,16 +1190,13 @@ static int i7core_create_sysfs_devices(struct 
>> mem_ctl_info *mci)
>> 
>>  rc = device_add(pvt->addrmatch_dev);
>>  if (rc < 0)
>> -return rc;
>> +goto fail_free_addrmatch_dev;
>> 
>>  if (!pvt->is_registered) {
>>  pvt->chancounts_dev = kzalloc(sizeof(*pvt->chancounts_dev),
>>GFP_KERNEL);
>> -if (!pvt->chancounts_dev) {
>> -put_device(pvt->addrmatch_dev);
>> -device_del(pvt->addrmatch_dev);
>> -return rc;
>> -}
>> +if (!pvt->chancounts_dev)
>> +goto fail_del_addrmatch_dev;
>> 
>>  pvt->chancounts_dev->type = _channel_counts_type;
>>  pvt->chancounts_dev->bus = mci->dev.bus;
>> @@ -1211,10 +1208,26 @@ static int i7core_create_sysfs_devices(struct 
>> mem_ctl_info *mci)
>>  edac_dbg(1, "creating %s\n", dev_name(pvt->chancounts_dev));
>> 
>>  rc = device_add(pvt->chancounts_dev);
>> -if (rc < 0)
>> -return rc;
>> +if (rc < 0) {
>> +put_device(pvt->chancounts_dev);
>> +goto fail_del_addrmatch_dev;
>> +}
>>  }
>>  return 0;
>> +
>> +fail_del_addrmatch_dev:
>> +device_del(pvt->addrmatch_dev);
>> +fail_free_addrmatch_dev:
>> +put_device(pvt->addrmatch_dev);
>> +fail_remove_inject_enable:
>> +device_create_file(>dev, _attr_inject_enable);
>> +fail_remove_inject_eccmask:
>> +device_create_file(>dev, _attr_inject_eccmask);
>> +fail_remove_inject_type:
>> +device_create_file(>dev, _attr_inject_type);
>> +fail_remove_inject_section:
>> +device_create_file(>dev, _attr_inject_section);
>
> I don't know the code, but calling device_create_file() on failures
> is quite unusual. Are you sure this is correct ?
>
> Guenter

I should call device_remove_file here. Terribly sorry for the
carelessness.

Best Regards
Junjie Mao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i7core_edac: release resources on error in i7core_create_sysfs_devices

[Junjie Mao]

v3: call device_remove_file on failure

v2: do not call kfree on allocated devs after device_initialize is called

Signed-off-by: Junjie Mao 
---
 drivers/edac/i7core_edac.c | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 9cd0b301f81b..240e9a3303c4 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1167,17 +1167,17 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)
return rc;
rc = device_create_file(>dev, _attr_inject_type);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_section;
rc = device_create_file(>dev, _attr_inject_eccmask);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_type;
rc = device_create_file(>dev, _attr_inject_enable);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_eccmask;
 
pvt->addrmatch_dev = kzalloc(sizeof(*pvt->addrmatch_dev), GFP_KERNEL);
if (!pvt->addrmatch_dev)
-   return rc;
+   goto fail_remove_inject_enable;
 
pvt->addrmatch_dev->type = _type;
pvt->addrmatch_dev->bus = mci->dev.bus;
@@ -1190,16 +1190,13 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)
 
rc = device_add(pvt->addrmatch_dev);
if (rc < 0)
-   return rc;
+   goto fail_free_addrmatch_dev;
 
if (!pvt->is_registered) {
pvt->chancounts_dev = kzalloc(sizeof(*pvt->chancounts_dev),
  GFP_KERNEL);
-   if (!pvt->chancounts_dev) {
-   put_device(pvt->addrmatch_dev);
-   device_del(pvt->addrmatch_dev);
-   return rc;
-   }
+   if (!pvt->chancounts_dev)
+   goto fail_del_addrmatch_dev;
 
pvt->chancounts_dev->type = _channel_counts_type;
pvt->chancounts_dev->bus = mci->dev.bus;
@@ -1211,10 +1208,26 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)
edac_dbg(1, "creating %s\n", dev_name(pvt->chancounts_dev));
 
rc = device_add(pvt->chancounts_dev);
-   if (rc < 0)
-   return rc;
+   if (rc < 0) {
+   put_device(pvt->chancounts_dev);
+   goto fail_del_addrmatch_dev;
+   }
}
return 0;
+
+fail_del_addrmatch_dev:
+   device_del(pvt->addrmatch_dev);
+fail_free_addrmatch_dev:
+   put_device(pvt->addrmatch_dev);
+fail_remove_inject_enable:
+   device_remove_file(>dev, _attr_inject_enable);
+fail_remove_inject_eccmask:
+   device_remove_file(>dev, _attr_inject_eccmask);
+fail_remove_inject_type:
+   device_remove_file(>dev, _attr_inject_type);
+fail_remove_inject_section:
+   device_remove_file(>dev, _attr_inject_section);
+   return rc;
 }
 
 static void i7core_delete_sysfs_devices(struct mem_ctl_info *mci)
-- 
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 v3 14/24] vfio: powerpc/spapr: Register memory

[Alexey Kardashevskiy]

On 02/03/2015 11:11 AM, Alex Williamson wrote:
> On Thu, 2015-01-29 at 20:21 +1100, Alexey Kardashevskiy wrote:
>> The existing implementation accounts the whole DMA window in
>> the locked_vm counter which is going to be even worse with multiple
>> containers and huge DMA windows.
>>
>> This introduces 2 ioctls to register/unregister DMA memory which
>> receive user space address and size of the memory region which
>> needs to be pinned/unpinned and counted in locked_vm.
>>
>> If any memory region was registered, all subsequent DMA map requests
>> should address already pinned memory. If no memory was registered,
>> then the amount of memory required for a single default memory will be
>> accounted when the container is enabled and every map/unmap will pin/unpin
>> a page.
>>
>> Dynamic DMA window and in-kernel acceleration will require memory to
>> be registered in order to work.
>>
>> The accounting is done per VFIO container. When the support of
>> multiple groups per container is added, we will have accurate locked_vm
>> accounting.
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>>  drivers/vfio/vfio_iommu_spapr_tce.c | 333 
>> 
>>  include/uapi/linux/vfio.h   |  29 
>>  2 files changed, 331 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c 
>> b/drivers/vfio/vfio_iommu_spapr_tce.c
>> index 8256275..d0987ae 100644
>> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
>> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
>> @@ -86,8 +86,169 @@ struct tce_container {
>>  struct mutex lock;
>>  struct iommu_group *grp;
>>  bool enabled;
>> +struct list_head mem_list;
>>  };
>>  
>> +struct tce_memory {
>> +struct list_head next;
>> +struct rcu_head rcu;
>> +__u64 vaddr;
>> +__u64 size;
>> +__u64 pfns[];
>> +};
> 
> So we're using 2MB of kernel memory per 1G of user mapped memory, right?
> Or are we using bigger pages here?  I'm not sure the kmalloc below is
> the appropriate allocator for something that can be so large.

ok, vmalloc it is then.


>> +
>> +static void tce_unpin_pages(struct tce_container *container,
>> +struct tce_memory *mem, __u64 vaddr, __u64 size)
>> +{
>> +__u64 off;
>> +struct page *page = NULL;
>> +
>> +
>> +for (off = 0; off < size; off += PAGE_SIZE) {
>> +if (!mem->pfns[off >> PAGE_SHIFT])
>> +continue;
>> +
>> +page = pfn_to_page(mem->pfns[off >> PAGE_SHIFT]);
>> +if (!page)
>> +continue;
>> +
>> +put_page(page);
>> +mem->pfns[off >> PAGE_SHIFT] = 0;
>> +}
> 
> Seems cleaner to count by 1 rather than PAGE_SIZE (ie. shift size once
> instead of off 3 times).
>
>> +}
>> +
>> +static void release_tce_memory(struct rcu_head *head)
>> +{
>> +struct tce_memory *mem = container_of(head, struct tce_memory, rcu);
>> +
>> +kfree(mem);
>> +}
>> +
>> +static void tce_do_unregister_pages(struct tce_container *container,
>> +struct tce_memory *mem)
>> +{
>> +tce_unpin_pages(container, mem, mem->vaddr, mem->size);
>> +decrement_locked_vm(mem->size);
>> +list_del_rcu(>next);
>> +call_rcu_sched(>rcu, release_tce_memory);
>> +}
>> +
>> +static long tce_unregister_pages(struct tce_container *container,
>> +__u64 vaddr, __u64 size)
>> +{
>> +struct tce_memory *mem, *memtmp;
>> +
>> +if (container->enabled)
>> +return -EBUSY;
>> +
>> +if ((vaddr & ~PAGE_MASK) || (size & ~PAGE_MASK))
>> +return -EINVAL;
>> +
>> +list_for_each_entry_safe(mem, memtmp, >mem_list, next) {
>> +if ((mem->vaddr == vaddr) && (mem->size == size)) {
>> +tce_do_unregister_pages(container, mem);
>> +return 0;
>> +}
>> +}
>> +
>> +return -ENOENT;
>> +}
>> +
>> +static long tce_pin_pages(struct tce_container *container,
>> +struct tce_memory *mem, __u64 vaddr, __u64 size)
>> +{
>> +__u64 off;
>> +struct page *page = NULL;
>> +
>> +for (off = 0; off < size; off += PAGE_SIZE) {
>> +if (1 != get_user_pages_fast(vaddr + off,
>> +1/* pages */, 1/* iswrite */, )) {
>> +tce_unpin_pages(container, mem, vaddr, off);
>> +return -EFAULT;
>> +}
>> +
>> +mem->pfns[off >> PAGE_SHIFT] = page_to_pfn(page);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static long tce_register_pages(struct tce_container *container,
>> +__u64 vaddr, __u64 size)
>> +{
>> +long ret;
>> +struct tce_memory *mem;
>> +
>> +if (container->enabled)
>> +return -EBUSY;
>> +
>> +if ((vaddr & ~PAGE_MASK) || (size & ~PAGE_MASK) ||
>> +((vaddr + size) < vaddr))
>> +return -EINVAL;
>> +
>> +/* Any overlap with registered chunks? */
>> +rcu_read_lock();
>> +

[PATCHv2] kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM

[David Gibson]

On POWER, storage caching is usually configured via the MMU - attributes
such as cache-inhibited are stored in the TLB and the hashed page table.

This makes correctly performing cache inhibited IO accesses awkward when
the MMU is turned off (real mode).  Some CPU models provide special
registers to control the cache attributes of real mode load and stores but
this is not at all consistent.  This is a problem in particular for SLOF,
the firmware used on KVM guests, which runs entirely in real mode, but
which needs to do IO to load the kernel.

To simplify this qemu implements two special hypercalls, H_LOGICAL_CI_LOAD
and H_LOGICAL_CI_STORE which simulate a cache-inhibited load or store to
a logical address (aka guest physical address).  SLOF uses these for IO.

However, because these are implemented within qemu, not the host kernel,
these bypass any IO devices emulated within KVM itself.  The simplest way
to see this problem is to attempt to boot a KVM guest from a virtio-blk
device with iothread / dataplane enabled.  The iothread code relies on an
in kernel implementation of the virtio queue notification, which is not
triggered by the IO hcalls, and so the guest will stall in SLOF unable to
load the guest OS.

This patch addresses this by providing in-kernel implementations of the
2 hypercalls, which correctly scan the KVM IO bus.  Any access to an
address not handled by the KVM IO bus will cause a VM exit, hitting the
qemu implementation as before.

Note that a userspace change is also required, in order to enable these
new hcall implementations with KVM_CAP_PPC_ENABLE_HCALL.

Signed-off-by: David Gibson 
---
 arch/powerpc/include/asm/kvm_book3s.h |  3 ++
 arch/powerpc/kvm/book3s.c | 76 +++
 arch/powerpc/kvm/book3s_hv.c  | 12 ++
 arch/powerpc/kvm/book3s_pr_papr.c | 28 +
 4 files changed, 119 insertions(+)

v2:
  - Removed some debugging printk()s that were accidentally left in
  - Fix endianness; like all PAPR hypercalls, these should always act
big-endian, even if the guest is little-endian (in practice this
makes no difference, since the only user is SLOF, which is always
big-endian)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index 942c7b1..578e550 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -292,6 +292,9 @@ static inline bool kvmppc_supports_magic_page(struct 
kvm_vcpu *vcpu)
return !is_kvmppc_hv_enabled(vcpu->kvm);
 }
 
+extern int kvmppc_h_logical_ci_load(struct kvm_vcpu *vcpu);
+extern int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu);
+
 /* Magic register values loaded into r3 and r4 before the 'sc' assembly
  * instruction for the OSI hypercalls */
 #define OSI_SC_MAGIC_R30x113724FA
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 888bf46..7b51492 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -820,6 +820,82 @@ void kvmppc_core_destroy_vm(struct kvm *kvm)
 #endif
 }
 
+int kvmppc_h_logical_ci_load(struct kvm_vcpu *vcpu)
+{
+   unsigned long size = kvmppc_get_gpr(vcpu, 4);
+   unsigned long addr = kvmppc_get_gpr(vcpu, 5);
+   u64 buf;
+   int ret;
+
+   if (!is_power_of_2(size) || (size > sizeof(buf)))
+   return H_TOO_HARD;
+
+   ret = kvm_io_bus_read(vcpu->kvm, KVM_MMIO_BUS, addr, size, );
+   if (ret != 0)
+   return H_TOO_HARD;
+
+   switch (size) {
+   case 1:
+   kvmppc_set_gpr(vcpu, 4, *(u8 *));
+   break;
+
+   case 2:
+   kvmppc_set_gpr(vcpu, 4, be16_to_cpu(*(u16 *)));
+   break;
+
+   case 4:
+   kvmppc_set_gpr(vcpu, 4, be32_to_cpu(*(u32 *)));
+   break;
+
+   case 8:
+   kvmppc_set_gpr(vcpu, 4, be64_to_cpu(*(u64 *)));
+   break;
+
+   default:
+   BUG();
+   }
+
+   return H_SUCCESS;
+}
+EXPORT_SYMBOL_GPL(kvmppc_h_logical_ci_load); /* For use by the kvm-pr module */
+
+int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu)
+{
+   unsigned long size = kvmppc_get_gpr(vcpu, 4);
+   unsigned long addr = kvmppc_get_gpr(vcpu, 5);
+   unsigned long val = kvmppc_get_gpr(vcpu, 6);
+   u64 buf;
+   int ret;
+
+   switch (size) {
+   case 1:
+   *(u8 *) = val;
+   break;
+
+   case 2:
+   *(u16 *) = cpu_to_be16(val);
+   break;
+
+   case 4:
+   *(u32 *) = cpu_to_be32(val);
+   break;
+
+   case 8:
+   *(u64 *) = cpu_to_be64(val);
+   break;
+
+   default:
+   return H_TOO_HARD;
+   }
+
+   ret = kvm_io_bus_write(vcpu->kvm, KVM_MMIO_BUS, addr, size, );
+   if (ret != 0)
+   return H_TOO_HARD;
+
+   return H_SUCCESS;
+}
+EXPORT_SYMBOL_GPL(kvmppc_h_logical_ci_store); 

RE: [RFC] change non-atomic bitops method

[Wang, Yalin]

> -Original Message-
> From: Wang, Yalin
> Sent: Tuesday, February 03, 2015 10:13 AM
> To: 'Kirill A. Shutemov'; Andrew Morton
> Cc: 'a...@arndb.de'; 'linux-a...@vger.kernel.org'; 'linux-
> ker...@vger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: RE: [RFC] change non-atomic bitops method
> 
> > -Original Message-
> > From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> > Sent: Tuesday, February 03, 2015 9:18 AM
> > To: Andrew Morton
> > Cc: Wang, Yalin; 'a...@arndb.de'; 'linux-a...@vger.kernel.org'; 'linux-
> > ker...@vger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> > ker...@lists.infradead.org'
> > Subject: Re: [RFC] change non-atomic bitops method
> >
> > On Mon, Feb 02, 2015 at 03:29:09PM -0800, Andrew Morton wrote:
> > > On Mon, 2 Feb 2015 11:55:03 +0800 "Wang, Yalin"
> >  wrote:
> > >
> > > > This patch change non-atomic bitops,
> > > > add a if() condition to test it, before set/clear the bit.
> > > > so that we don't need dirty the cache line, if this bit
> > > > have been set or clear. On SMP system, dirty cache line will
> > > > need invalidate other processors cache line, this will have
> > > > some impact on SMP systems.
> > > >
> > > > --- a/include/asm-generic/bitops/non-atomic.h
> > > > +++ b/include/asm-generic/bitops/non-atomic.h
> > > > @@ -17,7 +17,9 @@ static inline void __set_bit(int nr, volatile
> > unsigned long *addr)
> > > > unsigned long mask = BIT_MASK(nr);
> > > > unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > > >
> > > > -   *p  |= mask;
> > > > +   if ((*p & mask) == 0)
> > > > +   *p  |= mask;
> > > > +
> > > >  }
> > >
> > > hm, maybe.
> > >
> > > It will speed up set_bit on an already-set bit.  But it will slow down
> > > set_bit on a not-set bit.  And the latter case is presumably much, much
> > > more common.
> > >
> > > How do we know the patch is a net performance gain?
> >
> > Let's try to measure. The micro benchmark:
> >
> > #include 
> > #include 
> > #include 
> >
> > #ifdef CACHE_HOT
> > #define SIZE (2UL << 20)
> > #define TIMES 1000
> > #else
> > #define SIZE (1UL << 30)
> > #define TIMES 1
> > #endif
> >
> > int main(int argc, char **argv)
> > {
> > struct timespec a, b, diff;
> > unsigned long i, *p, times = TIMES;
> >
> > p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
> > MAP_ANONYMOUS | MAP_PRIVATE | MAP_POPULATE, -1,
> > 0);
> >
> > clock_gettime(CLOCK_MONOTONIC, );
> > while (times--) {
> > for (i = 0; i < SIZE/64/sizeof(*p); i++) {
> > #ifdef CHECK_BEFORE_SET
> > if (p[i] != times)
> > #endif
> > p[i] = times;
> > }
> > }
> > clock_gettime(CLOCK_MONOTONIC, );
> >
> > diff.tv_sec = b.tv_sec - a.tv_sec;
> > if (a.tv_nsec > b.tv_nsec) {
> > diff.tv_sec--;
> > diff.tv_nsec = 10 + b.tv_nsec - a.tv_nsec;
> > } else
> > diff.tv_nsec = b.tv_nsec - a.tv_nsec;
> >
> > printf("%lu.%09lu\n", diff.tv_sec, diff.tv_nsec);
> > return 0;
> > }
> >
> > Results for 10 runs on my laptop -- i5-3427U (IvyBridge 1.8 Ghz, 2.8Ghz
> > Turbo
> > with 3MB LLC):
> >
> > Avg Stddev
> > baseline21.5351 0.5315
> > -DCHECK_BEFORE_SET  21.9834 0.0789
> > -DCACHE_HOT 14.9987 0.0365
> > -DCACHE_HOT -DCHECK_BEFORE_SET  29.9010 0.0204
> >
> > Difference between -DCACHE_HOT and -DCACHE_HOT -DCHECK_BEFORE_SET appears
> > huge, but if you recalculate it to CPU cycles per inner loop @ 2.8 Ghz,
> > it's 1.02530 and 2.04401 CPU cycles respectively.
> >
> > Basically, the check is free on decent CPU.
> >
> Awesome test, but you only test the one cpu which running this code,
> Have not consider the other CPUs, whose cache line will be invalidate if
> The cache is dirtied by writer CPU,
> So another test should be running 2 thread on two different CPUs(bind to
> CPU),
> One write , one read, to see the impact on the reader CPU.
I make a little change about your test progrom,
Add a new thread to test SMP cache impact.
---
#include 
#include 
#include 
#include 
#define _GNU_SOURCE
#define __USE_GNU
#include 
#include 

#ifdef CACHE_HOT
#define SIZE (2UL << 20)
#define TIMES 10
#else
#define SIZE (1UL << 20)
#define TIMES 1
#endif
static void *reader_thread(void *arg)
{

struct timespec a, b, diff;
unsigned long *p = arg;
volatile unsigned long temp;
unsigned long i, ret, times = TIMES;
cpu_set_t set;
CPU_ZERO();
CPU_SET(1, );
ret = sched_setaffinity(-1, sizeof(cpu_set_t), );
if 

[PATCH 5/5] powerpc: Remove unused st_le*() and ld_le* functions

[David Gibson]

The powerpc specific st_le*() and ld_le*() functions in
arch/powerpc/asm/swab.h no longer have any users.  They are also
misleadingly named, since they always byteswap, even on a little-endian
host.

This patch removes them.

Signed-off-by: David Gibson 
---
 arch/powerpc/include/asm/swab.h | 26 --
 1 file changed, 26 deletions(-)

diff --git a/arch/powerpc/include/asm/swab.h b/arch/powerpc/include/asm/swab.h
index 96f59de..487e090 100644
--- a/arch/powerpc/include/asm/swab.h
+++ b/arch/powerpc/include/asm/swab.h
@@ -9,30 +9,4 @@
 
 #include 
 
-static __inline__ __u16 ld_le16(const volatile __u16 *addr)
-{
-   __u16 val;
-
-   __asm__ __volatile__ ("lhbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" 
(*addr));
-   return val;
-}
-
-static __inline__ void st_le16(volatile __u16 *addr, const __u16 val)
-{
-   __asm__ __volatile__ ("sthbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" 
(addr));
-}
-
-static __inline__ __u32 ld_le32(const volatile __u32 *addr)
-{
-   __u32 val;
-
-   __asm__ __volatile__ ("lwbrx %0,0,%1" : "=r" (val) : "r" (addr), "m" 
(*addr));
-   return val;
-}
-
-static __inline__ void st_le32(volatile __u32 *addr, const __u32 val)
-{
-   __asm__ __volatile__ ("stwbrx %1,0,%2" : "=m" (*addr) : "r" (val), "r" 
(addr));
-}
-
 #endif /* _ASM_POWERPC_SWAB_H */
-- 
2.1.0

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

[PATCH 0/5] powerpc: Get rid of redundant arch specific swab functions

[David Gibson]

arch/powerpc/include/asm/swab.h includes some powerpc specific
byteswapping functions, which are implemented in terms of powerpc's
built in byte reversed load/store instructions.  There are two problems with 
this:

1) They're not necessary - gcc is perfectly capable of generating the
   byte-reversed load and store instructions when using the normal,
   generic byteswapping functions (tested with gcc (GCC) 4.8.3
   20140911 (Red Hat 4.8.3-9))

2) They've become poorly named.  The ld_le*() and st_le*() functions
   in fact *always* byteswap, even in a little-endian powerpc kernel
   build, in which case they'll actually be performing BE accesses.

This series removes the existing users of these arch-specific
functions, replacing them with calls to the generic byteswappers.  5/5
then removes the function definitions.

I've compile tested this series with pmac32_defconfig,
mpc512x_defconfig and ppc64_defconfig, and also those configs tweaked
to explicitly enable the BT8XX and MXC MMC drivers where possible.

I've tested the KVM patch (4/5) with both BE and LE guests, however I
don't have hardware to do any real testing of the drivers affected in
1..3/5.

David Gibson (5):
  powerpc: Move Power Macintosh drivers to generic byteswappers
  powerpc: Remove powerpc specific byteswap from bt8xx DVB driver
  powerpc: Remove arch specific byteswappers from the MXC MMC driver
  powerpc: Cleanup KVM emulated load/store endian handling
  powerpc: Remove unused st_le*() and ld_le* functions

 arch/powerpc/include/asm/dbdma.h| 12 
 arch/powerpc/include/asm/kvm_host.h |  2 +-
 arch/powerpc/include/asm/swab.h | 26 -
 arch/powerpc/include/asm/vga.h  |  4 +--
 arch/powerpc/kvm/powerpc.c  | 38 
 drivers/ata/pata_macio.c| 10 +++
 drivers/block/swim3.c   | 12 
 drivers/ide/pmac.c  | 10 +++
 drivers/macintosh/rack-meter.c  | 30 +--
 drivers/media/pci/bt8xx/bt878.h |  4 +--
 drivers/mmc/host/mxcmmc.c   |  2 +-
 drivers/net/ethernet/apple/bmac.c   | 30 +--
 drivers/net/ethernet/apple/mace.c   | 44 ++--
 drivers/scsi/mac53c94.c | 10 +++
 drivers/scsi/mesh.c | 14 -
 drivers/video/fbdev/controlfb.c |  2 +-
 drivers/video/fbdev/platinumfb.c|  2 +-
 sound/ppc/pmac.c| 58 ++---
 18 files changed, 141 insertions(+), 169 deletions(-)

-- 
2.1.0

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

[PATCH 1/5] powerpc: Move Power Macintosh drivers to generic byteswappers

[David Gibson]

ppc has special instruction forms to efficiently load and store values
in non-native endianness.  These can be accessed via the arch-specific
{ld,st}_le{16,32}() inlines in arch/powerpc/include/asm/swab.h.

However, gcc is perfectly capable of generating the byte-reversing
load/store instructions when using the normal, generic cpu_to_le*() and
le*_to_cpu() functions eaning the arch-specific functions don't have much
point.

Worse the "le" in the names of the arch specific functions is now
misleading, because they always generate byte-reversing forms, but some
ppc machines can now run a little-endian kernel.

To start getting rid of the arch-specific forms, this patch removes them
from all the old Power Macintosh drivers, replacing them with the
generic byteswappers.

Signed-off-by: David Gibson 
---
 arch/powerpc/include/asm/dbdma.h  | 12 
 arch/powerpc/include/asm/vga.h|  4 +--
 drivers/ata/pata_macio.c  | 10 +++
 drivers/block/swim3.c | 12 
 drivers/ide/pmac.c| 10 +++
 drivers/macintosh/rack-meter.c| 30 ++--
 drivers/net/ethernet/apple/bmac.c | 30 ++--
 drivers/net/ethernet/apple/mace.c | 44 ++---
 drivers/scsi/mac53c94.c   | 10 +++
 drivers/scsi/mesh.c   | 14 +-
 drivers/video/fbdev/controlfb.c   |  2 +-
 drivers/video/fbdev/platinumfb.c  |  2 +-
 sound/ppc/pmac.c  | 58 +++
 13 files changed, 119 insertions(+), 119 deletions(-)

diff --git a/arch/powerpc/include/asm/dbdma.h b/arch/powerpc/include/asm/dbdma.h
index e23f07e..6c69836 100644
--- a/arch/powerpc/include/asm/dbdma.h
+++ b/arch/powerpc/include/asm/dbdma.h
@@ -42,12 +42,12 @@ struct dbdma_regs {
  * DBDMA command structure.  These fields are all little-endian!
  */
 struct dbdma_cmd {
-unsigned short req_count;  /* requested byte transfer count */
-unsigned short command;/* command word (has bit-fields) */
-unsigned int   phy_addr;   /* physical data address */
-unsigned int   cmd_dep;/* command-dependent field */
-unsigned short res_count;  /* residual count after completion */
-unsigned short xfer_status;/* transfer status */
+   __le16 req_count;   /* requested byte transfer count */
+   __le16 command; /* command word (has bit-fields) */
+   __le32 phy_addr;/* physical data address */
+   __le32 cmd_dep; /* command-dependent field */
+   __le16 res_count;   /* residual count after completion */
+   __le16 xfer_status; /* transfer status */
 };
 
 /* DBDMA command values in command field */
diff --git a/arch/powerpc/include/asm/vga.h b/arch/powerpc/include/asm/vga.h
index e5f8dd3..ab3acd2 100644
--- a/arch/powerpc/include/asm/vga.h
+++ b/arch/powerpc/include/asm/vga.h
@@ -25,12 +25,12 @@
 
 static inline void scr_writew(u16 val, volatile u16 *addr)
 {
-st_le16(addr, val);
+   *addr = cpu_to_le16(val);
 }
 
 static inline u16 scr_readw(volatile const u16 *addr)
 {
-return ld_le16(addr);
+   return le16_to_cpu(*addr);
 }
 
 #define VT_BUF_HAVE_MEMCPYW
diff --git a/drivers/ata/pata_macio.c b/drivers/ata/pata_macio.c
index a02f76f..b002858 100644
--- a/drivers/ata/pata_macio.c
+++ b/drivers/ata/pata_macio.c
@@ -540,9 +540,9 @@ static void pata_macio_qc_prep(struct ata_queued_cmd *qc)
BUG_ON (pi++ >= MAX_DCMDS);
 
len = (sg_len < MAX_DBDMA_SEG) ? sg_len : MAX_DBDMA_SEG;
-   st_le16(>command, write ? OUTPUT_MORE: 
INPUT_MORE);
-   st_le16(>req_count, len);
-   st_le32(>phy_addr, addr);
+   table->command = cpu_to_le16(write ? OUTPUT_MORE: 
INPUT_MORE);
+   table->req_count = cpu_to_le16(len);
+   table->phy_addr = cpu_to_le32(addr);
table->cmd_dep = 0;
table->xfer_status = 0;
table->res_count = 0;
@@ -557,12 +557,12 @@ static void pata_macio_qc_prep(struct ata_queued_cmd *qc)
 
/* Convert the last command to an input/output */
table--;
-   st_le16(>command, write ? OUTPUT_LAST: INPUT_LAST);
+   table->command = cpu_to_le16(write ? OUTPUT_LAST: INPUT_LAST);
table++;
 
/* Add the stop command to the end of the list */
memset(table, 0, sizeof(struct dbdma_cmd));
-   st_le16(>command, DBDMA_STOP);
+   table->command = cpu_to_le16(DBDMA_STOP);
 
dev_dbgdma(priv->dev, "%s: %d DMA list entries\n", __func__, pi);
 }
diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
index 523ee8f..c264f2d 100644
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -440,9 +440,9 @@ static inline void seek_track(struct floppy_state *fs, int 
n)
 static inline void init_dma(struct dbdma_cmd *cp, int cmd,
void *buf, 

[PATCH 4/5] powerpc: Cleanup KVM emulated load/store endian handling

[David Gibson]

Sometimes the KVM code on powerpc needs to emulate load or store
instructions from the guest, which can include both normal and byte
reversed forms.

We currently (AFAICT) handle this correctly, but some variable names are
very misleading.  In particular we use "is_bigendian" in several places to
actually mean "is the IO the same endian as the host", but we now support
little-endian powerpc hosts.  This also ties into the misleadingly named
ld_le*() and st_le*() functions, which in fact always byteswap, even on
an LE host.

This patch cleans this up by renaming to more accurate "host_swabbed", and
uses the generic swab*() functions instead of the powerpc specific and
misleadingly named ld_le*() and st_le*() functions.

Signed-off-by: David Gibson 
---
 arch/powerpc/include/asm/kvm_host.h |  2 +-
 arch/powerpc/kvm/powerpc.c  | 38 ++---
 2 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 7efd666a..9b18149 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -584,7 +584,7 @@ struct kvm_vcpu_arch {
pgd_t *pgdir;
 
u8 io_gpr; /* GPR used as IO source/target */
-   u8 mmio_is_bigendian;
+   u8 mmio_host_swabbed;
u8 mmio_sign_extend;
u8 osi_needed;
u8 osi_enabled;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index c45eaab..e115793 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -721,7 +721,7 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu *vcpu,
return;
}
 
-   if (vcpu->arch.mmio_is_bigendian) {
+   if (!vcpu->arch.mmio_host_swabbed) {
switch (run->mmio.len) {
case 8: gpr = *(u64 *)run->mmio.data; break;
case 4: gpr = *(u32 *)run->mmio.data; break;
@@ -729,10 +729,10 @@ static void kvmppc_complete_mmio_load(struct kvm_vcpu 
*vcpu,
case 1: gpr = *(u8 *)run->mmio.data; break;
}
} else {
-   /* Convert BE data from userland back to LE. */
switch (run->mmio.len) {
-   case 4: gpr = ld_le32((u32 *)run->mmio.data); break;
-   case 2: gpr = ld_le16((u16 *)run->mmio.data); break;
+   case 8: gpr = swab64(*(u64 *)run->mmio.data); break;
+   case 4: gpr = swab32(*(u32 *)run->mmio.data); break;
+   case 2: gpr = swab16(*(u16 *)run->mmio.data); break;
case 1: gpr = *(u8 *)run->mmio.data; break;
}
}
@@ -781,14 +781,13 @@ int kvmppc_handle_load(struct kvm_run *run, struct 
kvm_vcpu *vcpu,
   int is_default_endian)
 {
int idx, ret;
-   int is_bigendian;
+   bool host_swabbed;
 
+   /* Pity C doesn't have a logical XOR operator */
if (kvmppc_need_byteswap(vcpu)) {
-   /* Default endianness is "little endian". */
-   is_bigendian = !is_default_endian;
+   host_swabbed = is_default_endian;
} else {
-   /* Default endianness is "big endian". */
-   is_bigendian = is_default_endian;
+   host_swabbed = !is_default_endian;
}
 
if (bytes > sizeof(run->mmio.data)) {
@@ -801,7 +800,7 @@ int kvmppc_handle_load(struct kvm_run *run, struct kvm_vcpu 
*vcpu,
run->mmio.is_write = 0;
 
vcpu->arch.io_gpr = rt;
-   vcpu->arch.mmio_is_bigendian = is_bigendian;
+   vcpu->arch.mmio_host_swabbed = host_swabbed;
vcpu->mmio_needed = 1;
vcpu->mmio_is_write = 0;
vcpu->arch.mmio_sign_extend = 0;
@@ -841,14 +840,13 @@ int kvmppc_handle_store(struct kvm_run *run, struct 
kvm_vcpu *vcpu,
 {
void *data = run->mmio.data;
int idx, ret;
-   int is_bigendian;
+   bool host_swabbed;
 
+   /* Pity C doesn't have a logical XOR operator */
if (kvmppc_need_byteswap(vcpu)) {
-   /* Default endianness is "little endian". */
-   is_bigendian = !is_default_endian;
+   host_swabbed = is_default_endian;
} else {
-   /* Default endianness is "big endian". */
-   is_bigendian = is_default_endian;
+   host_swabbed = !is_default_endian;
}
 
if (bytes > sizeof(run->mmio.data)) {
@@ -863,7 +861,7 @@ int kvmppc_handle_store(struct kvm_run *run, struct 
kvm_vcpu *vcpu,
vcpu->mmio_is_write = 1;
 
/* Store the value at the lowest bytes in 'data'. */
-   if (is_bigendian) {
+   if (!host_swabbed) {
switch (bytes) {
case 8: *(u64 *)data = val; break;
case 4: *(u32 *)data = val; break;
@@ -871,11 +869,11 @@ int kvmppc_handle_store(struct kvm_run *run, struct 
kvm_vcpu *vcpu,
case 1: *(u8  *)data = val; break;
}
} else {
-  

[PATCH 2/5] powerpc: Remove powerpc specific byteswap from bt8xx DVB driver

[David Gibson]

The bt8xx PCI DVB driver includes a powerpc specific hack, using one of
the powerpc specific byteswapping functions in an IO helper macro.

There's no reason to use the powerpc specific function instead of a
generic byteswap, so this patch removes it.  I'm not sure if the powerpc
specific memory barrier is required, so I'm leaving that in.

Cc: Mauro Carvalho Chehab 
Cc: Peter Hettkamp 

Signed-off-by: David Gibson 
---
 drivers/media/pci/bt8xx/bt878.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/bt8xx/bt878.h b/drivers/media/pci/bt8xx/bt878.h
index d19b592..bbb76bb 100644
--- a/drivers/media/pci/bt8xx/bt878.h
+++ b/drivers/media/pci/bt8xx/bt878.h
@@ -145,12 +145,12 @@ void bt878_stop(struct bt878 *bt);
 #if defined(__powerpc__)   /* big-endian */
 static inline void io_st_le32(volatile unsigned __iomem *addr, unsigned val)
 {
-   st_le32(addr, val);
+   *addr = cpu_to_le32(val);
eieio();
 }
 
 #define bmtwrite(dat,adr)  io_st_le32((adr),(dat))
-#define bmtread(adr)   ld_le32((adr))
+#define bmtread(adr)   le32_to_cpu(*((volatile __le32 *)(adr)))
 #else
 #define bmtwrite(dat,adr)  writel((dat), (adr))
 #define bmtread(adr)   readl(adr)
-- 
2.1.0

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

[PATCH 3/5] powerpc: Remove arch specific byteswappers from the MXC MMC driver

[David Gibson]

When the MXC MMUC driver is used on a Freescale MPC512x machine, it
contains some additional byteswapping code (I'm assuming this is a
workaround for a hardware defect).  This uses the ppc specific st_le32()
function, but there's no reason not to use the generic swab32() function
instead.  gcc is capable of generating the efficient ppc byte-reversing
load/store instructions without the arch-specific helper.

This patch, therefore, switches to the generic byteswap routine.

Cc: Shawn Guo 
Cc: Sascha Hauer 

Signed-off-by: David Gibson 
---
 drivers/mmc/host/mxcmmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
index 5316d9b..317d709 100644
--- a/drivers/mmc/host/mxcmmc.c
+++ b/drivers/mmc/host/mxcmmc.c
@@ -281,7 +281,7 @@ static inline void buffer_swap32(u32 *buf, int len)
int i;
 
for (i = 0; i < ((len + 3) / 4); i++) {
-   st_le32(buf, *buf);
+   *buf = swab32(*buf);
buf++;
}
 }
-- 
2.1.0

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

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

[Stephen Rothwell]

Hi Mike,

Today's linux-next merge of the clk tree got a conflict in
arch/arm/mach-omap2/cclock3xxx_data.c between commit ca662ee7b8a8
("ARM: OMAP2+: Remove unused ti81xx platform init code") from the
arm-soc tree and commit d6540b193719 ("ARM: OMAP3: remove legacy clock
data") from the clk tree.

I fixed it up (the latter removed the file, so I did that) and can
carry the fix as necessary (no action is required).

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


pgp6GzzYIwDV4.pgp
Description: OpenPGP digital signature

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

[Stephen Rothwell]

Hi Mike,

Today's linux-next merge of the clk tree got a conflict in
arch/arm/mach-omap2/io.c between commit c27964b5d2f3 ("ARM: OMAP2+: Fix
ti81xx class type") from the arm-soc tree and commit eded36fe29e1
("ARM: OMAP3: use clock data from TI clock driver for legacy boot")
from the clk tree.

I fixed it up (the former seems to have incorporated the conflicting
part of the latter) and can carry the fix as necessary (no action is
required).

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


pgpho88BUB5PC.pgp
Description: OpenPGP digital signature

[PATCH v2 4/6] power: max77843_battery: Add Max77843 fuel gauge device driver

[Jaewon Kim]

From: Beomho Seo 

This patch adds device driver of max77843 fuel gauge.
The driver support for battery fuel gauge in Maxim Max77843.
It is fuel-gauge systems for lithuum-ion batteries in handled and
portable devices.

Cc: Sebastian Reichel 
Signed-off-by: Beomho Seo 
---
 drivers/power/Kconfig|9 ++
 drivers/power/Makefile   |1 +
 drivers/power/max77843_battery.c |  286 ++
 3 files changed, 296 insertions(+)
 create mode 100644 drivers/power/max77843_battery.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index a054a28..cea0ea2 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -212,6 +212,15 @@ config BATTERY_MAX17042
  with MAX17042. This driver also supports max17047/50 chips which are
  improved version of max17042.
 
+config BATTERY_MAX77843
+   tristate "Maxim MAX77843 Fuel Gauge"
+   depends on MFD_MAX77843
+   help
+ This adds support for battery fuel gauge in Maxim MAX77843. It is
+ fuel-gauge for a lithium-ion batteries with a single cell and can be
+ found in portable devices. The MAX17040 is configured to operate with
+ a single lithium cell.
+
 config BATTERY_Z2
tristate "Z2 battery driver"
depends on I2C && MACH_ZIPIT2
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 212c6a2..ae0d795 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_BATTERY_DA9030)  += da9030_battery.o
 obj-$(CONFIG_BATTERY_DA9052)   += da9052-battery.o
 obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
 obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
+obj-$(CONFIG_BATTERY_MAX77843) += max77843_battery.o
 obj-$(CONFIG_BATTERY_Z2)   += z2_battery.o
 obj-$(CONFIG_BATTERY_S3C_ADC)  += s3c_adc_battery.o
 obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
diff --git a/drivers/power/max77843_battery.c b/drivers/power/max77843_battery.c
new file mode 100644
index 000..0c59a16
--- /dev/null
+++ b/drivers/power/max77843_battery.c
@@ -0,0 +1,286 @@
+/*
+ * Fuel gauge driver for Maxim MAX77843
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Author: 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 
+
+struct max77843_battery {
+   struct device   *dev;
+   struct max77843 *max77843;
+   struct i2c_client   *client;
+   struct regmap   *regmap;
+   struct power_supply psy;
+};
+
+static int max77843_battery_get_capacity(struct max77843_battery *battery)
+{
+   struct regmap *regmap = battery->regmap;
+   int ret, val;
+   unsigned int reg_data;
+
+   ret = regmap_read(regmap, MAX77843_FG_REG_SOCREP, _data);
+   if (ret) {
+   dev_err(battery->dev, "Failed to read fuelgauge register\n");
+   return ret;
+   }
+
+   val = reg_data >> 8;
+
+   return val;
+}
+
+static int max77843_battery_get_energy_prop(struct max77843_battery *battery,
+   enum power_supply_property psp)
+{
+   struct regmap *regmap = battery->regmap;
+   unsigned int reg;
+   int ret, val;
+   unsigned int reg_data;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_ENERGY_FULL:
+   reg = MAX77843_FG_REG_FULLCAP;
+   break;
+   case POWER_SUPPLY_PROP_ENERGY_NOW:
+   reg = MAX77843_FG_REG_REMCAP_REP;
+   break;
+   case POWER_SUPPLY_PROP_ENERGY_AVG:
+   reg = MAX77843_FG_REG_REMCAP_AV;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = regmap_read(regmap, reg, _data);
+   if (ret) {
+   dev_err(battery->dev, "Failed to read fuelgauge register\n");
+   return ret;
+   }
+
+   val = reg_data;
+
+   return val;
+}
+
+static int max77843_battery_get_current_prop(struct max77843_battery *battery,
+   enum power_supply_property psp)
+{
+   struct regmap *regmap = battery->regmap;
+   unsigned int reg;
+   int ret, val;
+   unsigned int reg_data;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_CURRENT_NOW:
+   reg = MAX77843_FG_REG_CURRENT;
+   break;
+   case POWER_SUPPLY_PROP_CURRENT_AVG:
+   reg = MAX77843_FG_REG_AVG_CURRENT;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = regmap_read(regmap, reg, _data);
+   if (ret) {
+   dev_err(battery->dev, "Failed to read fuelgauge register\n");
+   return ret;
+   }
+
+   val = reg_data;
+   if (val & 0x8000) {
+   /* Negative */
+   val = ~val & 0x;
+   val++;
+

[PATCH v2 2/6] extcon: max77843: Add max77843 MUIC driver

[Jaewon Kim]

This patch adds MAX77843 extcon driver to support for MUIC(Micro
USB Interface Controller) device by using EXTCON subsystem to handle
various external connectors.

Cc: Chanwoo Choi 
Signed-off-by: Jaewon Kim 
---
 drivers/extcon/Kconfig   |   10 +
 drivers/extcon/Makefile  |1 +
 drivers/extcon/extcon-max77843.c |  881 ++
 3 files changed, 892 insertions(+)
 create mode 100644 drivers/extcon/extcon-max77843.c

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..0b67538 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -55,6 +55,16 @@ config EXTCON_MAX77693
  Maxim MAX77693 PMIC. The MAX77693 MUIC is a USB port accessory
  detector and switch.
 
+config EXTCON_MAX77843
+   tristate "MAX77843 EXTCON Support"
+   depends on MFD_MAX77843
+   select IRQ_DOMAIN
+   select REGMAP_I2C
+   help
+ If you say yes here you get support for the MUIC device of
+ Maxim MAX77843. The MAX77843 MUIC is a USB port accessory
+ detector add switch.
+
 config EXTCON_MAX8997
tristate "MAX8997 EXTCON Support"
depends on MFD_MAX8997 && IRQ_DOMAIN
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..f21d5c4 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-arizona.o
 obj-$(CONFIG_EXTCON_GPIO)  += extcon-gpio.o
 obj-$(CONFIG_EXTCON_MAX14577)  += extcon-max14577.o
 obj-$(CONFIG_EXTCON_MAX77693)  += extcon-max77693.o
+obj-$(CONFIG_EXTCON_MAX77843)  += extcon-max77843.o
 obj-$(CONFIG_EXTCON_MAX8997)   += extcon-max8997.o
 obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
 obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
diff --git a/drivers/extcon/extcon-max77843.c b/drivers/extcon/extcon-max77843.c
new file mode 100644
index 000..598a017
--- /dev/null
+++ b/drivers/extcon/extcon-max77843.c
@@ -0,0 +1,881 @@
+/*
+ * extcon-max77843.c - Maxim MAX77843 extcon driver to support
+ * MUIC(Micro USB Interface Controller)
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Author: Jaewon Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DELAY_MS_DEFAULT   15000   /* unit: millisecond */
+
+enum max77843_muic_status {
+   MAX77843_MUIC_STATUS1 = 0,
+   MAX77843_MUIC_STATUS2,
+   MAX77843_MUIC_STATUS3,
+
+   MAX77843_MUIC_STATUS_NUM,
+};
+
+struct max77843_muic_info {
+   struct device *dev;
+   struct max77843 *max77843;
+   struct extcon_dev *edev;
+
+   struct mutex mutex;
+   struct work_struct irq_work;
+   struct delayed_work wq_detcable;
+
+   u8 status[MAX77843_MUIC_STATUS_NUM];
+   int prev_cable_type;
+   int prev_chg_type;
+   int prev_gnd_type;
+
+   bool irq_adc;
+   bool irq_chg;
+};
+
+enum max77843_muic_cable_group {
+   MAX77843_CABLE_GROUP_ADC = 0,
+   MAX77843_CABLE_GROUP_ADC_GND,
+   MAX77843_CABLE_GROUP_CHG,
+};
+
+enum max77843_muic_adc_debounce_time {
+   MAX77843_DEBOUNCE_TIME_5MS = 0,
+   MAX77843_DEBOUNCE_TIME_10MS,
+   MAX77843_DEBOUNCE_TIME_25MS,
+   MAX77843_DEBOUNCE_TIME_38_62MS,
+};
+
+/* Define accessory cable type */
+enum max77843_muic_accessory_type {
+   MAX77843_MUIC_ADC_GROUND = 0,
+   MAX77843_MUIC_ADC_SEND_END_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S1_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S2_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S3_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S4_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S5_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S6_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S7_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S8_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S9_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S10_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S11_BUTTON,
+   MAX77843_MUIC_ADC_REMOTE_S12_BUTTON,
+   MAX77843_MUIC_ADC_RESERVED_ACC_1,
+   MAX77843_MUIC_ADC_RESERVED_ACC_2,
+   MAX77843_MUIC_ADC_RESERVED_ACC_3,
+   MAX77843_MUIC_ADC_RESERVED_ACC_4,
+   MAX77843_MUIC_ADC_RESERVED_ACC_5,
+   MAX77843_MUIC_ADC_AUDIO_DEVICE_TYPE2,
+   MAX77843_MUIC_ADC_PHONE_POWERED_DEV,
+   MAX77843_MUIC_ADC_TTY_CONVERTER,
+   MAX77843_MUIC_ADC_UART_CABLE,
+   MAX77843_MUIC_ADC_CEA936A_TYPE1_CHG,
+   MAX77843_MUIC_ADC_FACTORY_MODE_USB_OFF,
+   MAX77843_MUIC_ADC_FACTORY_MODE_USB_ON,
+   MAX77843_MUIC_ADC_AV_CABLE_NOLOAD,
+   MAX77843_MUIC_ADC_CEA936A_TYPE2_CHG,
+   MAX77843_MUIC_ADC_FACTORY_MODE_UART_OFF,
+   MAX77843_MUIC_ADC_FACTORY_MODE_UART_ON,
+   MAX77843_MUIC_ADC_AUDIO_DEVICE_TYPE1,
+   

[PATCH v2 6/6] Documentation: Add device tree bindings document for max77843

[Jaewon Kim]

Add document describing device tree bindings for max77843 MFD.
Drivers: MFD core, regulator, extcon, charger and fuelgauge.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Lee Jones 
Cc: Chanwoo Choi 
Cc: Sebastian Reichel 
Cc: Mark Brown 
Signed-off-by: Jaewon Kim 
Signed-off-by: Beomho Seo 
---
 Documentation/devicetree/bindings/mfd/max77843.txt |   90 
 1 file changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/max77843.txt

diff --git a/Documentation/devicetree/bindings/mfd/max77843.txt 
b/Documentation/devicetree/bindings/mfd/max77843.txt
new file mode 100644
index 000..4341ab9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77843.txt
@@ -0,0 +1,90 @@
+Maxim MAX77843 multi-function device
+
+MAX77843 is a Multi-Function Device with the following submodules:
+- PMIC   : 2 SAFEOUT LDOs for USB device
+- CHARGER : Li+ battery charger with Fuel Gauge
+- MUIC   : Micro USB Interface Controller
+
+It is interfaced to host controller using I2C.
+
+Required properties:
+- compatible : Must be "maxim,max77843".
+- reg : I2C slave address of PMIC block.
+- interrupts : I2C line for main SoCs.
+- interrupt-parent : The parent of interrupt controller.
+
+Optional properties:
+- regulators : The regulators of max77843 have to be instantiated under subnode
+   named "regulators" using the following format.
+
+   [*]refer : Documentation/devicetree/bindings/regulator/regulator.txt
+
+   regulators {
+   SAFEOUT {
+   regulator-name = "SAFEOUT";
+   };
+   }
+
+   List of valid regulator names:
+   - SAFEOUT1, SAFEOUT2, CHARGER.
+
+- max77843-muic : This properties used by extcon consumers.
+   Required properties:
+   - compatible : Must be "maxim,max77842-muic".
+
+- max77843-charger : There battery charger of MAX77843 have to be instantiated
+   under sub-node named "max77843-charger" using the following format.
+   Required properties:
+   - compatible : Must be "maxim,max77842-charger".
+   - maxim,fast-charge-uamp : Fast charge current levels are
+   100 mA to 3150 mA programmed by I2C per 100 mA.
+   - maxim,top-off-uamp : Top off current threshold levels are
+   125 mA to 650 mA programmed by I2C per 75 mA.
+   - maxim,input-uamp-limit : Input current limit levels are
+   100 mA to 3533 mA programmed by I2C per 33 mA.
+- max77843-fuelgauge : There fuelgauge of MAX77843 have to be instantiated
+   under sub-node named "max77843-fuelgauge" using the following format.
+   Required properties:
+   - compatible : Must be "maxim,max77842-fuelgauge".
+
+Example:
+   max77843@66 {
+   compatible = "samsung,max77843";
+   reg = <0x66>;
+   interrupt-parent = <>;
+   interrupts = <5 2>;
+
+   regulators {
+   SAFEOUT1 {
+   regulator-name = "SAFEOUT1";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <495>;
+   };
+   SAFEOUT2 {
+   regulator-name = "SAFEOUT2";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <495>;
+   };
+   CHARGER {
+   regulator-name = "CHARGER";
+   regulator-min-microamp = <10>;
+   regulator-max-microamp = <315>;
+   };
+   };
+
+   max77843-muic {
+   compatible = "maxim,max77843-muic";
+   };
+
+   max77843-charger {
+   compatible = "maxim,max77843-charger";
+   maxim,fast-charge-uamp = <45>;
+   maxim,top-off-uamp = <125000>;
+   maxim,input-uamp-limit = <50>;
+   };
+
+   max77843-fuelgauge {
+   compatible = "maxim,max77843-fuelgauge";
+   };
+
+   };
-- 
1.7.9.5

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

[PATCH v2 0/6] Add new MFD driver for MAX77843

[Jaewon Kim]

This patch series adds MAX77843(Multi Function Device) driver.
The MAX77843 includes MUIC(Micro USB Interface Circuit), Li+ Charger
with Fuel Gauge and 2 safeout LDOs for USB device.
It is interfaced to host controller using I2C.

Changes in V2:
MFD Core
 - Fix charger regmap handle and typo.
MUIC
 - cleanup enum list.
 - set path before send excon event.
 - fix variable names and typos for readability.
Charger
 - Remove unnecessary header.
 - Chnage error message more readable.
 - Remove unnecessary lines.
Fuelgauge
 - Fix regmap_config and use regmap_read.
 - Add i2c_unregister_device function on *_remove function.
 - Fix typo in Kconfig.
Doc
 - Remove unnecessary lines.
 - Add example of charger regulator.

Beomho Seo (2):
  power: max77843_charger: Add Max77843 charger device driver
  power: max77843_battery: Add Max77843 fuel gauge device driver

Jaewon Kim (4):
  mfd: max77843: Add max77843 MFD driver core driver
  extcon: max77843: Add max77843 MUIC driver
  regulator: max77843: Add max77843 regulator driver
  Documentation: Add device tree bindings document for max77843

 Documentation/devicetree/bindings/mfd/max77843.txt |   90 ++
 drivers/extcon/Kconfig |   10 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-max77843.c   |  881 
 drivers/mfd/Kconfig|   14 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/max77843.c |  247 ++
 drivers/power/Kconfig  |   16 +
 drivers/power/Makefile |2 +
 drivers/power/max77843_battery.c   |  286 +++
 drivers/power/max77843_charger.c   |  508 +++
 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/max77843.c   |  229 +
 include/linux/mfd/max77843-private.h   |  422 ++
 15 files changed, 2716 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/max77843.txt
 create mode 100644 drivers/extcon/extcon-max77843.c
 create mode 100644 drivers/mfd/max77843.c
 create mode 100644 drivers/power/max77843_battery.c
 create mode 100644 drivers/power/max77843_charger.c
 create mode 100644 drivers/regulator/max77843.c
 create mode 100644 include/linux/mfd/max77843-private.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 3/6] power: max77843_charger: Add Max77843 charger device driver

[Jaewon Kim]

From: Beomho Seo 

This patch adds device driver of max77843 charger. This driver provide
initialize each charging mode(e.g. fast charge, top-off mode and constant
charging mode so on.). Additionally, control charging paramters to use
i2c interface.

Cc: Sebastian Reichel 
Signed-off-by: Beomho Seo 
---
 drivers/power/Kconfig|7 +
 drivers/power/Makefile   |1 +
 drivers/power/max77843_charger.c |  508 ++
 3 files changed, 516 insertions(+)
 create mode 100644 drivers/power/max77843_charger.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 0108c2a..a054a28 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -332,6 +332,13 @@ config CHARGER_MAX14577
  Say Y to enable support for the battery charger control sysfs and
  platform data of MAX14577/77836 MUICs.
 
+config CHARGER_MAX77843
+   tristate "Maxim MAX77843 battery charger driver"
+   depends on MFD_MAX77843
+   help
+ Say Y to enable support for the battery charger control sysfs and
+ platform data of MAX77843
+
 config CHARGER_MAX8997
tristate "Maxim MAX8997/MAX8966 PMIC battery charger driver"
depends on MFD_MAX8997 && REGULATOR_MAX8997
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dfa8942..212c6a2 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_LP8788)  += lp8788-charger.o
 obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o
 obj-$(CONFIG_CHARGER_MANAGER)  += charger-manager.o
 obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
+obj-$(CONFIG_CHARGER_MAX77843) += max77843_charger.o
 obj-$(CONFIG_CHARGER_MAX8997)  += max8997_charger.o
 obj-$(CONFIG_CHARGER_MAX8998)  += max8998_charger.o
 obj-$(CONFIG_CHARGER_BQ2415X)  += bq2415x_charger.o
diff --git a/drivers/power/max77843_charger.c b/drivers/power/max77843_charger.c
new file mode 100644
index 000..392eebc1a
--- /dev/null
+++ b/drivers/power/max77843_charger.c
@@ -0,0 +1,508 @@
+/*
+ * Charger driver for Maxim MAX77843
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Author: 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 
+
+struct max77843_charger_info {
+   u32 fast_charge_uamp;
+   u32 top_off_uamp;
+   u32 input_uamp_limit;
+};
+
+struct max77843_charger {
+   struct device   *dev;
+   struct max77843 *max77843;
+   struct i2c_client   *client;
+   struct regmap   *regmap;
+   struct power_supply psy;
+
+   struct max77843_charger_info*info;
+};
+
+static int max77843_charger_get_max_current(struct max77843_charger *charger)
+{
+   struct regmap *regmap = charger->regmap;
+   int ret, val = 0;
+   unsigned int reg_data;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_09, _data);
+   if (ret) {
+   dev_err(charger->dev,
+   "Failed to read max current register: %d\n", ret);
+   return ret;
+   }
+
+   if (reg_data <= 0x03) {
+   val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MIN;
+   } else if (reg_data >= 0x78) {
+   val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MAX;
+   } else {
+   val = reg_data / 3;
+   if (reg_data % 3 == 0)
+   val *= 10;
+   else if (reg_data % 3 == 1)
+   val = val * 10 + 33000;
+   else
+   val = val * 10 + 67000;
+   }
+
+   return val;
+}
+
+static int max77843_charger_get_now_current(struct max77843_charger *charger)
+{
+   struct regmap *regmap = charger->regmap;
+   int ret, val = 0;
+   unsigned int reg_data;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, _data);
+   if (ret) {
+   dev_err(charger->dev,
+   "Failed to read charge current register: %d\n", ret);
+   return ret;
+   }
+
+   reg_data &= MAX77843_CHG_FAST_CHG_CURRENT_MASK;
+
+   if (reg_data <= 0x02)
+   val = MAX77843_CHG_FAST_CHG_CURRENT_MIN;
+   else if (reg_data >= 0x3f)
+   val = MAX77843_CHG_FAST_CHG_CURRENT_MAX;
+   else
+   val = reg_data * MAX77843_CHG_FAST_CHG_CURRENT_STEP;
+
+   return val;
+}
+
+static int max77843_charger_get_online(struct max77843_charger *charger)
+{
+   struct regmap *regmap = charger->regmap;
+   int ret, val = 0;
+   unsigned int reg_data;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_INT_OK, _data);
+   if (ret) {
+   dev_err(charger->dev,
+   "Failed to read charger status: %d\n", ret);
+   return ret;
+   }

[PATCH v2 5/6] regulator: max77843: Add max77843 regulator driver

[Jaewon Kim]

This patch adds new regulator driver to support max77843
MFD(Multi Function Device) chip`s regulators.
The Max77843 has two voltage regulators for USB safeout.

Cc: Mark Brown 
Signed-off-by: Jaewon Kim 
Signed-off-by: Beomho Seo 
---
 drivers/regulator/Kconfig|8 ++
 drivers/regulator/Makefile   |1 +
 drivers/regulator/max77843.c |  229 ++
 3 files changed, 238 insertions(+)
 create mode 100644 drivers/regulator/max77843.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c3a60b5..c1f9c33 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -414,6 +414,14 @@ config REGULATOR_MAX77802
  Exynos5420/Exynos5800 SoCs to control various voltages.
  It includes support for control of voltage and ramp speed.
 
+config REGULATOR_MAX77843
+   tristate "Maxim 77843 regulator"
+   depends on MFD_MAX77843
+   help
+ This driver controls a Maxim 77843 regulator.
+ The regulator include two 'SAFEOUT' for USB(Universal Serial Bus)
+ This is suitable for Exynos5433 SoC chips.
+
 config REGULATOR_MC13XXX_CORE
tristate
 
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 1f28ebf..12408d6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
 obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
 obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
 obj-$(CONFIG_REGULATOR_MAX77802) += max77802.o
+obj-$(CONFIG_REGULATOR_MAX77843) += max77843.o
 obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
diff --git a/drivers/regulator/max77843.c b/drivers/regulator/max77843.c
new file mode 100644
index 000..d7ae66b
--- /dev/null
+++ b/drivers/regulator/max77843.c
@@ -0,0 +1,229 @@
+/*
+ * max77843.c - Regulator driver for the Maxim MAX77843
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Author: Jaewon Kim 
+ * Author: Beomho Seo 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX77843_SUPPORTED_VOLTAGE_NUM 4
+
+enum max77843_regulator_type {
+   MAX77843_SAFEOUT1 = 0,
+   MAX77843_SAFEOUT2,
+   MAX77843_CHARGER,
+
+   MAX77843_NUM,
+};
+
+static const unsigned int max77843_regulator_table[] = {
+   485,
+   490,
+   495,
+   330,
+};
+
+static int max77843_reg_is_enabled(struct regulator_dev *rdev)
+{
+   struct regmap *regmap = rdev->regmap;
+   int ret;
+   unsigned int reg;
+
+   ret = regmap_read(regmap, rdev->desc->enable_reg, );
+   if (ret) {
+   dev_err(>dev, "Fialed to read charger register\n");
+   return ret;
+   }
+
+   return (reg & rdev->desc->enable_mask) == rdev->desc->enable_mask;
+}
+
+static int max77843_reg_get_current_limit(struct regulator_dev *rdev)
+{
+   struct regmap *regmap = rdev->regmap;
+   unsigned int chg_min_uA = rdev->constraints->min_uA;
+   unsigned int chg_max_uA = rdev->constraints->max_uA;
+   unsigned int val;
+   int ret;
+   unsigned int reg, sel;
+
+   ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, );
+   if (ret) {
+   dev_err(>dev, "Failed to read charger register\n");
+   return ret;
+   }
+
+   sel = reg & MAX77843_CHG_FAST_CHG_CURRENT_MASK;
+
+   if (sel < 0x03)
+   sel = 0;
+   else
+   sel -= 2;
+
+   val = chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel;
+   if (val > chg_max_uA)
+   return -EINVAL;
+
+   return val;
+}
+
+static int max77843_reg_set_current_limit(struct regulator_dev *rdev,
+   int min_uA, int max_uA)
+{
+   struct regmap *regmap = rdev->regmap;
+   unsigned int chg_min_uA = rdev->constraints->min_uA;
+   int sel = 0;
+
+   while (chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel < min_uA)
+   sel++;
+
+   if (chg_min_uA + MAX77843_CHG_FAST_CHG_CURRENT_STEP * sel > max_uA)
+   return -EINVAL;
+
+   sel += 2;
+
+   return regmap_write(regmap, MAX77843_CHG_REG_CHG_CNFG_02, sel);
+}
+
+static struct regulator_ops max77843_charger_ops = {
+   .is_enabled = max77843_reg_is_enabled,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .get_current_limit  = max77843_reg_get_current_limit,
+   .set_current_limit  = max77843_reg_set_current_limit,
+};
+
+static struct regulator_ops max77843_regulator_ops = {
+  

[PATCH v2 1/6] mfd: max77843: Add max77843 MFD driver core driver

[Jaewon Kim]

This patch adds MAX77843 core/irq driver to support PMIC,
MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
LED and Haptic device.

Cc: Lee Jones 
Signed-off-by: Jaewon Kim 
Signed-off-by: Beomho Seo 
---
 drivers/mfd/Kconfig  |   14 ++
 drivers/mfd/Makefile |1 +
 drivers/mfd/max77843.c   |  247 
 include/linux/mfd/max77843-private.h |  422 ++
 4 files changed, 684 insertions(+)
 create mode 100644 drivers/mfd/max77843.c
 create mode 100644 include/linux/mfd/max77843-private.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..0c67c79 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -442,6 +442,20 @@ config MFD_MAX77693
  additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_MAX77843
+   bool "Maxim Semiconductor MAX77843 PMIC Support"
+   depends on I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ Say yes here to add support for Maxim Semiconductor MAX77843.
+ This is companion Power Management IC with LEDs, Haptic, Charger,
+ Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
+ This driver provides common support for accessing the device;
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
 config MFD_MAX8907
tristate "Maxim Semiconductor MAX8907 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..fe4f75c 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9063)+= da9063.o
 obj-$(CONFIG_MFD_MAX14577) += max14577.o
 obj-$(CONFIG_MFD_MAX77686) += max77686.o
 obj-$(CONFIG_MFD_MAX77693) += max77693.o
+obj-$(CONFIG_MFD_MAX77843) += max77843.o
 obj-$(CONFIG_MFD_MAX8907)  += max8907.o
 max8925-objs   := max8925-core.o max8925-i2c.o
 obj-$(CONFIG_MFD_MAX8925)  += max8925.o
diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
new file mode 100644
index 000..b47fdbc
--- /dev/null
+++ b/drivers/mfd/max77843.c
@@ -0,0 +1,247 @@
+/*
+ * max77843.c - MFD core driver for the Maxim MAX77843
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Author: Jaewon Kim 
+ * Author: Beomho Seo 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct mfd_cell max77843_devs[] = {
+   {
+   .name = "max77843-muic",
+   .of_compatible = "maxim,max77843-muic",
+   }, {
+   .name = "max77843-regulator",
+   .of_compatible = "maxim,max77843-regulator",
+   }, {
+   .name = "max77843-charger",
+   .of_compatible = "maxim,max77843-charger"
+   }, {
+   .name = "max77843-fuelgauge",
+   .of_compatible = "maxim,max77843-fuelgauge",
+   },
+};
+
+static const struct regmap_config max77843_charger_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .max_register   = MAX77843_CHG_REG_END,
+};
+
+static const struct regmap_config max77843_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .max_register   = MAX77843_SYS_REG_END,
+};
+
+static const struct regmap_irq max77843_irqs[] = {
+   /* TOPSYS interrupts */
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
+   { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
+};
+
+static const struct regmap_irq_chip max77843_irq_chip = {
+   .name   = "max77843",
+   .status_base= MAX77843_SYS_REG_SYSINTSRC,
+   .mask_base  = MAX77843_SYS_REG_SYSINTMASK,
+   .mask_invert= false,
+   .num_regs   = 1,
+   .irqs   = max77843_irqs,
+   .num_irqs   = ARRAY_SIZE(max77843_irqs),
+};
+
+/* Charger and Charger regulator use same regmap. */
+static int max77843_chg_init(struct max77843 *max77843)
+{
+   int ret;
+
+   max77843->i2c_chg = i2c_new_dummy(max77843->i2c->adapter, I2C_ADDR_CHG);
+   if (!max77843->i2c_chg) {
+   dev_err(>i2c->dev,
+   "Cannot allocate I2C device for Charger\n");
+   return PTR_ERR(max77843->i2c_chg);
+   }
+   i2c_set_clientdata(max77843->i2c_chg, max77843);
+
+   max77843->regmap_chg = devm_regmap_init_i2c(max77843->i2c_chg,
+   

linux-next: manual merge of the target-updates tree with Linus' tree

[Stephen Rothwell]

Hi Nicholas,

Today's linux-next merge of the target-updates tree got a conflict in
drivers/vhost/scsi.c between commit 46243860806b ("vhost-scsi: Add
missing virtio-scsi -> TCM attribute conversion") from Linus' tree and
commit 2936f1d4f3e8 ("vhost/scsi: Global tcm_vhost -> vhost_scsi
rename") from the target-updates 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/vhost/scsi.c
index d695b1673ae5,57a6f0ac4c55..
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@@ -911,28 -938,11 +938,28 @@@ vhost_scsi_mapal(struct vhost_scsi_cmd 
return 0;
  }
  
 +static int vhost_scsi_to_tcm_attr(int attr)
 +{
 +  switch (attr) {
 +  case VIRTIO_SCSI_S_SIMPLE:
 +  return TCM_SIMPLE_TAG;
 +  case VIRTIO_SCSI_S_ORDERED:
 +  return TCM_ORDERED_TAG;
 +  case VIRTIO_SCSI_S_HEAD:
 +  return TCM_HEAD_TAG;
 +  case VIRTIO_SCSI_S_ACA:
 +  return TCM_ACA_TAG;
 +  default:
 +  break;
 +  }
 +  return TCM_SIMPLE_TAG;
 +}
 +
- static void tcm_vhost_submission_work(struct work_struct *work)
+ static void vhost_scsi_submission_work(struct work_struct *work)
  {
-   struct tcm_vhost_cmd *cmd =
-   container_of(work, struct tcm_vhost_cmd, work);
-   struct tcm_vhost_nexus *tv_nexus;
+   struct vhost_scsi_cmd *cmd =
+   container_of(work, struct vhost_scsi_cmd, work);
+   struct vhost_scsi_nexus *tv_nexus;
struct se_cmd *se_cmd = >tvc_se_cmd;
struct scatterlist *sg_ptr, *sg_prot_ptr = NULL;
int rc;


pgpnSsWsT6Q6M.pgp
Description: OpenPGP digital signature

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

[Davidlohr Bueso]

On Mon, 2015-02-02 at 20:41 -0800, Davidlohr Bueso wrote:
> On Mon, 2015-02-02 at 11:13 -0800, Linus Torvalds wrote:
> > IOW, instead of
> > 
> >   m = 1UL << (BITS_PER_LONG - 2);
> > 
> > perhaps something like
> > 
> >m = 1UL << (BITS_PER_LONG/2- 2);
> >if (m < x)
> >m <<= BITS_PER_LONG/2;

Assuming small values mostly, we could also try more aggressive
estimators for BITS_PER_LONG == 64. But then again, it probably doesn't
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/

Re: [PATCH] zram: check bd_openers instead bd_holders

[Sergey Senozhatsky]

On (02/03/15 13:50), Minchan Kim wrote:
> Signed-off-by: Minchan Kim 

Acked-by: Sergey Senozhatsky 

> ---
>  drivers/block/zram/zram_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index a32069f98afa..cc0e6a3ddb4f 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -811,7 +811,7 @@ static ssize_t reset_store(struct device *dev,
>  
>   mutex_lock(>bd_mutex);
>   /* Do not reset an active device! */
> - if (bdev->bd_holders) {
> + if (bdev->bd_openers) {
>   ret = -EBUSY;
>   goto out;
>   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] zram: check bd_openers instead bd_holders

[Minchan Kim]

On Tue, Feb 03, 2015 at 12:56:28PM +0900, Sergey Senozhatsky wrote:
> On (02/03/15 12:02), Minchan Kim wrote:
> > On Tue, Feb 03, 2015 at 10:54:33AM +0900, Sergey Senozhatsky wrote:
> > > On (02/02/15 16:06), Sergey Senozhatsky wrote:
> > > > So, guys, how about doing it differently, in less lines of code,
> > > > hopefully. Don't move reset_store()'s work to zram_reset_device().
> > > > Instead, move
> > > > 
> > > > set_capacity(zram->disk, 0);
> > > > revalidate_disk(zram->disk);
> > > > 
> > > > out from zram_reset_device() to reset_store(). this two function are
> > > > executed only when called from reset_store() anyway. this also will let
> > > > us drop `bool reset capacity' param from zram_reset_device().
> > > > 
> > > > 
> > > > so we will do in reset_store()
> > > > 
> > > > mutex_lock(bdev->bd_mutex);
> > > > 
> > > > fsync_bdev(bdev);
> > > > zram_reset_device(zram);
> > > > set_capacity(zram->disk, 0);
> > > > 
> > > > mutex_unlock(>bd_mutex);
> > > > 
> > > > revalidate_disk(zram->disk);
> > > > bdput(bdev);
> > > > 
> > > > 
> > > > 
> > > > and change zram_reset_device(zram, false) call to simply 
> > > > zram_reset_device(zram)
> > > > in __exit zram_exit(void).
> > > > 
> > > 
> > > Hello,
> > > 
> > > Minchan, Ganesh, I sent a patch last night, with the above solution.
> > > looks ok to you?
> > 
> > Just I sent a feedback.
> > 
> 
> thanks.
> yeah, !FMODE_EXCL mode.
> 
> how do you want to handle it -- you want to send a separate patch or
> you want me to send incremental one-liner and ask Andrew to squash them?

Send a new patch based on yours.
Thanks.


>From 9da15eb638ba74d8072a1e2451c5036e8473f03a Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Tue, 3 Feb 2015 13:42:35 +0900
Subject: [PATCH] zram: check bd_openers instead bd_holders

The bd_holders is increased only when user open the device file
as FMODE_EXCL so if something opens zram0 as !FMODE_EXCL
and request I/O while another user reset zram0, we can see
following warning.

[   30.683449] zram0: detected capacity change from 0 to 64424509440
[   33.736869] Buffer I/O error on dev zram0, logical block 180823, lost async 
page write
[   33.738814] Buffer I/O error on dev zram0, logical block 180824, lost async 
page write
[   33.740654] Buffer I/O error on dev zram0, logical block 180825, lost async 
page write
[   33.742551] Buffer I/O error on dev zram0, logical block 180826, lost async 
page write
[   33.744153] Buffer I/O error on dev zram0, logical block 180827, lost async 
page write
[   33.745807] Buffer I/O error on dev zram0, logical block 180828, lost async 
page write
[   33.747419] Buffer I/O error on dev zram0, logical block 180829, lost async 
page write
[   33.749060] Buffer I/O error on dev zram0, logical block 180830, lost async 
page write
[   33.750687] Buffer I/O error on dev zram0, logical block 180831, lost async 
page write
[   33.752286] Buffer I/O error on dev zram0, logical block 180832, lost async 
page write
[   33.811590] [ cut here ]
[   33.812038] WARNING: CPU: 11 PID: 1996 at fs/block_dev.c:57 
__blkdev_put+0x1d7/0x210()
[   33.812817] Modules linked in:
[   33.813142] CPU: 11 PID: 1996 Comm: dd Not tainted 3.19.0-rc6-next-20150202+ 
#1125
[   33.813837] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Bochs 01/01/2011
[   33.814525]  81801a2d 880061e77db8 815b848e 
0001
[   33.815196]   880061e77df8 8104de2a 

[   33.815867]  88005da287f0 88005da28680 88005da28770 
88005da28698
[   33.816536] Call Trace:
[   33.816817]  [] dump_stack+0x45/0x57
[   33.817304]  [] warn_slowpath_common+0x8a/0xc0
[   33.817829]  [] warn_slowpath_null+0x1a/0x20
[   33.818331]  [] __blkdev_put+0x1d7/0x210
[   33.818797]  [] blkdev_put+0x50/0x130
[   33.819244]  [] blkdev_close+0x25/0x30
[   33.819723]  [] __fput+0xdf/0x1e0
[   33.820140]  [] fput+0xe/0x10
[   33.820576]  [] task_work_run+0xa7/0xe0
[   33.821151]  [] do_notify_resume+0x49/0x60
[   33.821721]  [] int_signal+0x12/0x17
[   33.88] ---[ end trace 274fbbc5664827d2 ]---

The warning comes from bdev_write_node in blkdev_put path.

tatic void bdev_write_inode(struct inode *inode)
{
spin_lock(>i_lock);
while (inode->i_state & I_DIRTY) {
spin_unlock(>i_lock);
WARN_ON_ONCE(write_inode_now(inode, true)); <

Re: [PATCH] lib/int_sqrt.c: Optimize square root function

[Davidlohr Bueso]

On Mon, 2015-02-02 at 11:00 -0800, Linus Torvalds wrote:
> Hmm. I don't disagree, but would like some more feedback.
> 
> Davidlohr - you were the person to touch this function last (commit
> 30493cc9dddb: "lib/int_sqrt.c: optimize square root algorithm"), and
> you did so for performance reasons. And in fact, when you did that,
> you removed that initial loop:
> 
> -   one = 1UL << (BITS_PER_LONG - 2);
> -   while (one > op)
> -   one >>= 2;
> 
> but I'm not sure that was actually all that conscious, I think the
> real optimization was the changes inside the loop to make the final
> real loop faster and simpler.

I missed that. And yes, the real optimization should be in the loop.

> 
> Also, you had performance numbers, so presumably a test harness for it
> all. It probably depends a lot on the actual distribution of argument
> values, of course, but it would be good to accompany the patch with
> actual real numbers like lasty time.

Aha. In my case I recall I ran a usersapce program using each function
from 1 to a million, and throwing perf at it for 10 times.

> (I'm also not entirely sure what uses int_sqrt() that ends up being so
> performance-critical, so it would be good to document that too, since
> that probably also matters for the "what's the normal argument range"
> question..)

It's not a big deal afaik.

Thanks,
Davidlohr

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

Re: [PATCH] Add ARCH_MIGHT_HAVE_VGA_CONSOLE

[Yoshinori Sato]

At Mon, 2 Feb 2015 22:07:50 +0100,
Geert Uytterhoeven wrote:
> 
> Hi Sato-san,
> 
> Your second version looks fine to me, except for this part:
> 
> On Mon, Feb 2, 2015 at 4:48 PM, Yoshinori Sato
>  wrote:
> > --- a/arch/um/Kconfig.common
> > +++ b/arch/um/Kconfig.common
> > @@ -9,6 +9,7 @@ config UML
> > select GENERIC_IO
> > select GENERIC_CLOCKEVENTS
> > select TTY # Needed for line.c
> > +   select ARCH_MIGHT_HAVE_VGA_CONSOLE
> >
> >  config MMU
> > bool
> 
> UML definitely doesn't have VGA support.

Ouch.
I will send v3.
Thanks.

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

-- 
Yoshinori Sato

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lib/int_sqrt.c: Optimize square root function

[Davidlohr Bueso]

On Mon, 2015-02-02 at 11:13 -0800, Linus Torvalds wrote:
> IOW, instead of
> 
>   m = 1UL << (BITS_PER_LONG - 2);
> 
> perhaps something like
> 
>m = 1UL << (BITS_PER_LONG/2- 2);
>if (m < x)
>m <<= BITS_PER_LONG/2;
> 
> (assuming gcc can change that code into a "cmov") might cut down the
> "lots of empty loops" case in half for small values of 'x'.

Makes a lot of sense.

> There's probably some other better cheap initial guess value estimator.

Just to get a feeling for the normal arg range in the non-driver parts
that use this thing:

fs/ceph/super.h:congestion_kb = (16*int_sqrt(totalram_pages)) << 
(PAGE_SHIFT-10);
fs/nfs/write.c: nfs_congestion_kb = (16*int_sqrt(totalram_pages)) << 
(PAGE_SHIFT-10);
fs/nfsd/nfscache.c: limit = (16 * int_sqrt(low_pages)) << (PAGE_SHIFT-10);
kernel/rcu/tree_plugin.h:   ls = int_sqrt(nr_cpu_ids);
mm/memcontrol.c:inactive_ratio = int_sqrt(10 * gb);
mm/page_alloc.c:ratio = int_sqrt(10 * gb);
mm/page_alloc.c:new_min_free_kbytes = int_sqrt(lowmem_kbytes * 16);

So mostly values that scale according to mem or cpu.



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

Re: [PATCH] Add ARCH_MIGHT_HAVE_VGA_CONSOLE

[Yoshinori Sato]

At Mon, 02 Feb 2015 21:11:50 +0100,
Arnd Bergmann wrote:
> 
> On Tuesday 03 February 2015 00:48:20 Yoshinori Sato wrote:
> > At Mon, 2 Feb 2015 09:10:06 +0100,
> > Geert Uytterhoeven wrote:
> > > 
> > > Hi Sato-san,
> > > 
> > > 
> > > On Mon, Feb 2, 2015 at 8:24 AM, Yoshinori Sato
> > >  wrote:
> > > > The dependence of VGA_CONSOLE is complicated.
> > > > We need clean up.
> > > 
> > > Thanks!
> > > 
> > > > Signed-off-by: Yoshinori Sato 
> > > >
> > > > ---
> > > >  arch/alpha/Kconfig| 1 +
> > > >  arch/arc/Kconfig  | 1 +
> > > >  arch/arm/Kconfig  | 1 +
> > > >  arch/c6x/Kconfig  | 1 +
> > > >  arch/hexagon/Kconfig  | 1 +
> > > >  arch/ia64/Kconfig | 1 +
> > > >  arch/m32r/Kconfig | 1 +
> > > >  arch/metag/Kconfig| 1 +
> > > >  arch/microblaze/Kconfig   | 1 +
> > > >  arch/mips/Kconfig | 1 +
> > > >  arch/nios2/Kconfig| 1 +
> > > >  arch/openrisc/Kconfig | 1 +
> > > >  arch/powerpc/Kconfig  | 1 +
> > > >  arch/s390/Kconfig | 1 +
> > > >  arch/score/Kconfig| 1 +
> > > >  arch/tile/Kconfig | 1 +
> > > >  arch/um/Kconfig.common| 1 +
> > > >  arch/unicore32/Kconfig| 1 +
> > > >  arch/x86/Kconfig  | 1 +
> > > >  arch/xtensa/Kconfig   | 1 +
> > > 
> > > While I know you just kept the existing logic from
> > > drivers/video/console/kconfig,
> > > I doubt all of the architectures listed above do support VGA.
> > > I guest most of them were just too lazy to update the dependency list.
> > > 
> > > I think only alpha, arm, ia64, mips, powerpc, and x86 can have VGA.
> 
> The list looks right to me too. We could be more specific in case of ARM,
> MIPS and PowerPC and move the symbols into the individual platforms that
> do support it, but it's fine to leave this up to the architecture
> maintainers.
> 
> > Hmm...
> > If require, Add this flag.
> > 
> > Signed-off-by: Yoshinori Sato 
> 
> Reviewed-by: Arnd Bergmann 
> 
> Please add this patch to your series with my Reviewed-by line added.

OK.

> except for one thing:
> 
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -76,6 +76,7 @@ config ARM
> >select PERF_USE_VMALLOC
> >select RTC_LIB
> >select SYS_SUPPORTS_APM_EMULATION
> >+   select ARCH_MIGHT_HAVE_VGA_CONSOLE if ARCH_FOOTBRIDGE || 
> >ARCH_INTEGRATOR || ARCH_NETWINDER
> ># Above selects are sorted alphabetically; please add new ones
> ># according to that.  Thanks.
> >help
> 
> You did not read the comment in the patch context: This list of selects is
> sorted alphabetically in order to avoid merge conflicts. Please keep it this
> way.

Ouch.
I will fix v3.

> Thanks,
> 
>   Arnd

-- 
Yoshinori Sato

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

Re: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place

[Jason Wang]

On Mon, Feb 2, 2015 at 12:35 PM, Dexuan Cui  wrote:
Before the line vmbus_open() returns, srv->util_cb can be already 
running
and the variables, like util_fw_version, are needed by the 
srv->util_cb.


So we have to make sure the variables are initialized before the 
vmbus_open().


CC: "K. Y. Srinivasan" 
Reviewed-by: Vitaly Kuznetsov 
Signed-off-by: Dexuan Cui 
---

v2:
This is a RESEND.
I just added Vitaly's Reviewed-by.

 drivers/hv/hv_util.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 3b9c9ef..c5be773 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -340,12 +340,8 @@ static int util_probe(struct hv_device *dev,
 
 	set_channel_read_state(dev->channel, false);
 
-	ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 
0,

-   srv->util_cb, dev->channel);
-   if (ret)
-   goto error;
-
hv_set_drvdata(dev, srv);
+
/*
 * Based on the host; initialize the framework and
 * service version numbers we will negotiate.
@@ -365,6 +361,11 @@ static int util_probe(struct hv_device *dev,
hb_srv_version = HB_VERSION;
}
 
+	ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 
0,

+   srv->util_cb, dev->channel);
+   if (ret)
+   goto error;
+
return 0;
 
 error:

--
1.9.1


Reviewed-by: Jason Wang 

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

RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place

[Jason Wang]

On Tue, Feb 3, 2015 at 11:40 AM, KY Srinivasan  
wrote:




 -Original Message-
 From: Jason Wang [mailto:jasow...@redhat.com]
 Sent: Monday, February 2, 2015 7:38 PM
 To: KY Srinivasan
 Cc: Dexuan Cui; gre...@linuxfoundation.org; 
linux-kernel@vger.kernel.org;

 driverdev-de...@linuxdriverproject.org; o...@aepfle.de;
 a...@canonical.com; vkuzn...@redhat.com; Haiyang Zhang
 Subject: RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a 
later place
 
 
 
 On Tue, Feb 3, 2015 at 11:30 AM, KY Srinivasan 

 wrote:
 >
 >
 >>  -Original Message-
 >>  From: Jason Wang [mailto:jasow...@redhat.com]
 >>  Sent: Monday, February 2, 2015 7:09 PM
 >>  To: Dexuan Cui
 >>  Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
 >> driverdev-
 >>  de...@linuxdriverproject.org; o...@aepfle.de; 
a...@canonical.com; KY

 >> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
 >>  Subject: RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a
 >> later place
 >>
 >>
 >>
 >>  On Mon, Feb 2, 2015 at 6:09 PM, Dexuan Cui 
 >> wrote:
 >>  >>  -Original Message-
 >>  >>  From: Jason Wang [mailto:jasow...@redhat.com]  >>  Sent: 
Monday,

 >> February 2, 2015 17:36 PM  >>  To: Dexuan Cui  >>  Cc:
 >> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;  >>
 >> driverdev-  >>  de...@linuxdriverproject.org; o...@aepfle.de;
 >> a...@canonical.com; KY  >> Srinivasan; vkuzn...@redhat.com; 
Haiyang
 >> Zhang  >>  Subject: Re: [PATCH v2 1/3] hv: hv_util: move 
vmbus_open()
 >> to a  >> later place  >>  >>  >>  >>  On Mon, Feb 2, 2015 at 
12:35

 >> PM, Dexuan Cui   >> wrote:
 >>  >>  > Before the line vmbus_open() returns, srv->util_cb can be
 >> already  >> > running  > and the variables, like 
util_fw_version, are

 >> needed by  >> the  > srv->util_cb.
 >>  >>
 >>  >>  A questions is why we do this for util only? Can callbacks 
of

 >> other  >> devices be called before vmbus_open() returns?
 >>  > The variables are used in vmbus_prep_negotiate_resp(), which 
is

 >> only  > for the util devices.
 >>  >
 >>  > I think the other devices should already handle the similar 
issue

 >> > properly.
 >>  > If this is not the case, we need to fix them too.
 >>
 >>  Better to check all the others, e.g in balloon_probe(), it call
 >>  hv_set_drvdata() after vmbus_open() and dose several datas 
setups in
 >> the  middle. If balloon_onchannelcallback() could be called 
before

 >> hv_set_drvdata(), the code looks wrong.
 >
 > Jason,
 >
 > For all other device types, the guest initiates the communication 
with
 > the host and potentially negotiates appropriate (supported) 
version
 > with the host. For the services packaged in the util driver, the 
flow
 > is a little different - the host pushes the version information 
into
 > the guest. So, the fix Dexuan made is only needed in the util 
driver.

 >
 > Regards,
 >
 > K. Y
 
 Thanks, so you mean for other device, it won't get any interrupt 
before guest

 negotiate the version with host?


Yes, the guest initiates the version negotiation. Are you seeing 
something different?


K. Y


No, 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: [alsa-devel] [PATCH v4 3/3] ARM: dts: Add sound nodes for exynos4412-trats2

[Kukjin Kim]

Sylwester Nawrocki wrote:
> 
> On 23/01/15 06:03, Inha Song wrote:
> > This patch add WM1811 audio codec, I2S interface and the sound
> > machine nodes to enable audio on exynos4412-trats2 board.
> >
> > Signed-off-by: Inha Song 
> 
> Reviewed-by: Sylwester Nawrocki 
> 
Applied, thanks.

- Kukjin

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

Re: [PATCH v2] i7core_edac: release resources on error in i7core_create_sysfs_devices

[Guenter Roeck]

On Tue, Feb 03, 2015 at 10:40:14AM +0800, Junjie Mao wrote:
> v2: do not call kfree on allocated devs after device_initialize is called
> 
> Signed-off-by: Junjie Mao 
> ---
>  drivers/edac/i7core_edac.c | 37 +
>  1 file changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
> index 9cd0b301f81b..f6a7b676d69c 100644
> --- a/drivers/edac/i7core_edac.c
> +++ b/drivers/edac/i7core_edac.c
> @@ -1167,17 +1167,17 @@ static int i7core_create_sysfs_devices(struct 
> mem_ctl_info *mci)
>   return rc;
>   rc = device_create_file(>dev, _attr_inject_type);
>   if (rc < 0)
> - return rc;
> + goto fail_remove_inject_section;
>   rc = device_create_file(>dev, _attr_inject_eccmask);
>   if (rc < 0)
> - return rc;
> + goto fail_remove_inject_type;
>   rc = device_create_file(>dev, _attr_inject_enable);
>   if (rc < 0)
> - return rc;
> + goto fail_remove_inject_eccmask;
> 
>   pvt->addrmatch_dev = kzalloc(sizeof(*pvt->addrmatch_dev), GFP_KERNEL);
>   if (!pvt->addrmatch_dev)
> - return rc;
> + goto fail_remove_inject_enable;
> 
>   pvt->addrmatch_dev->type = _type;
>   pvt->addrmatch_dev->bus = mci->dev.bus;
> @@ -1190,16 +1190,13 @@ static int i7core_create_sysfs_devices(struct 
> mem_ctl_info *mci)
> 
>   rc = device_add(pvt->addrmatch_dev);
>   if (rc < 0)
> - return rc;
> + goto fail_free_addrmatch_dev;
> 
>   if (!pvt->is_registered) {
>   pvt->chancounts_dev = kzalloc(sizeof(*pvt->chancounts_dev),
> GFP_KERNEL);
> - if (!pvt->chancounts_dev) {
> - put_device(pvt->addrmatch_dev);
> - device_del(pvt->addrmatch_dev);
> - return rc;
> - }
> + if (!pvt->chancounts_dev)
> + goto fail_del_addrmatch_dev;
> 
>   pvt->chancounts_dev->type = _channel_counts_type;
>   pvt->chancounts_dev->bus = mci->dev.bus;
> @@ -1211,10 +1208,26 @@ static int i7core_create_sysfs_devices(struct 
> mem_ctl_info *mci)
>   edac_dbg(1, "creating %s\n", dev_name(pvt->chancounts_dev));
> 
>   rc = device_add(pvt->chancounts_dev);
> - if (rc < 0)
> - return rc;
> + if (rc < 0) {
> + put_device(pvt->chancounts_dev);
> + goto fail_del_addrmatch_dev;
> + }
>   }
>   return 0;
> +
> +fail_del_addrmatch_dev:
> + device_del(pvt->addrmatch_dev);
> +fail_free_addrmatch_dev:
> + put_device(pvt->addrmatch_dev);
> +fail_remove_inject_enable:
> + device_create_file(>dev, _attr_inject_enable);
> +fail_remove_inject_eccmask:
> + device_create_file(>dev, _attr_inject_eccmask);
> +fail_remove_inject_type:
> + device_create_file(>dev, _attr_inject_type);
> +fail_remove_inject_section:
> + device_create_file(>dev, _attr_inject_section);

I don't know the code, but calling device_create_file() on failures
is quite unusual. Are you sure this is correct ?

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

RE: [RESEND PATCH] ARM: EXYNOS: Add missing static to file-scope declarations

[Kukjin Kim]

Krzysztof Kozlowski wrote:
> 
> The 'pm_data', 'exynos_release_ret_regs' and
> 'exynos5420_release_ret_regs' are not exported nor used outside of
> suspend.c file. Make them static.
> 
> This fixes following sparse warnings:
> arch/arm/mach-exynos/suspend.c:83:23: warning: symbol 'pm_data' was not 
> declared. Should it be static?
> arch/arm/mach-exynos/suspend.c:106:14: warning: symbol 
> 'exynos_release_ret_regs' was not declared.
> Should it be static?
> arch/arm/mach-exynos/suspend.c:117:14: warning: symbol 
> 'exynos5420_release_ret_regs' was not declared.
> Should it be static?
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/mach-exynos/suspend.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index 342797b9bf3b..fef091f8e59f 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -75,7 +75,7 @@ struct exynos_pm_data {
>   int (*cpu_suspend)(unsigned long);
>  };
> 
> -struct exynos_pm_data *pm_data;
> +static struct exynos_pm_data *pm_data;
> 
>  static int exynos5420_cpu_state;
>  static unsigned int exynos_pmu_spare3;
> @@ -98,7 +98,7 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] = 
> {
>   { /* sentinel */ },
>  };
> 
> -unsigned int exynos_release_ret_regs[] = {
> +static unsigned int exynos_release_ret_regs[] = {
>   S5P_PAD_RET_MAUDIO_OPTION,
>   S5P_PAD_RET_GPIO_OPTION,
>   S5P_PAD_RET_UART_OPTION,
> @@ -109,7 +109,7 @@ unsigned int exynos_release_ret_regs[] = {
>   REG_TABLE_END,
>  };
> 
> -unsigned int exynos5420_release_ret_regs[] = {
> +static unsigned int exynos5420_release_ret_regs[] = {
>   EXYNOS_PAD_RET_DRAM_OPTION,
>   EXYNOS_PAD_RET_MAUDIO_OPTION,
>   EXYNOS_PAD_RET_JTAG_OPTION,
> --

Looks ok to me, how about re-spin this patch including following?

...
+static unsigned int exynos3250_release_ret_regs[] = {
...

Thanks,
Kukjin

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

Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request

[Sergey Senozhatsky]

On (02/03/15 12:02), Minchan Kim wrote:
> On Tue, Feb 03, 2015 at 10:54:33AM +0900, Sergey Senozhatsky wrote:
> > On (02/02/15 16:06), Sergey Senozhatsky wrote:
> > > So, guys, how about doing it differently, in less lines of code,
> > > hopefully. Don't move reset_store()'s work to zram_reset_device().
> > > Instead, move
> > > 
> > >   set_capacity(zram->disk, 0);
> > >   revalidate_disk(zram->disk);
> > > 
> > > out from zram_reset_device() to reset_store(). this two function are
> > > executed only when called from reset_store() anyway. this also will let
> > > us drop `bool reset capacity' param from zram_reset_device().
> > > 
> > > 
> > > so we will do in reset_store()
> > > 
> > >   mutex_lock(bdev->bd_mutex);
> > > 
> > >   fsync_bdev(bdev);
> > >   zram_reset_device(zram);
> > >   set_capacity(zram->disk, 0);
> > > 
> > >   mutex_unlock(>bd_mutex);
> > > 
> > >   revalidate_disk(zram->disk);
> > >   bdput(bdev);
> > > 
> > > 
> > > 
> > > and change zram_reset_device(zram, false) call to simply 
> > > zram_reset_device(zram)
> > > in __exit zram_exit(void).
> > > 
> > 
> > Hello,
> > 
> > Minchan, Ganesh, I sent a patch last night, with the above solution.
> > looks ok to you?
> 
> Just I sent a feedback.
> 

thanks.
yeah, !FMODE_EXCL mode.

how do you want to handle it -- you want to send a separate patch or
you want me to send incremental one-liner and ask Andrew to squash them?

-ss

> > 
> > Minchan, I think I'll send my small struct zram clean-up patch after
> > your init_lock patch. what's your opinion?
> 
> Good for me.
> 
> Thanks.
> -- 
> Kind regards,
> Minchan Kim
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] selftests/exec: Check if the syscall exists and bail if not

[Michael Ellerman]

On systems which don't implement sys_execveat(), this test produces a
lot of output.

Add a check at the beginning to see if the syscall is present, and if
not just note one error and return.

When we run on a system that doesn't implement the syscall we will get
ENOSYS back from the kernel, so change the logic that handles
__NR_execveat not being defined to also use ENOSYS rather than -ENOSYS.

Signed-off-by: Michael Ellerman 
---

v2: Switch to positive ENOSYS. Confirmed this works as expected in the
case where the syscall is defined, but then is not present at runtime.


 tools/testing/selftests/exec/execveat.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/exec/execveat.c 
b/tools/testing/selftests/exec/execveat.c
index e238c9559caf..8d5d1d2ee7c1 100644
--- a/tools/testing/selftests/exec/execveat.c
+++ b/tools/testing/selftests/exec/execveat.c
@@ -30,7 +30,7 @@ static int execveat_(int fd, const char *path, char **argv, 
char **envp,
 #ifdef __NR_execveat
return syscall(__NR_execveat, fd, path, argv, envp, flags);
 #else
-   errno = -ENOSYS;
+   errno = ENOSYS;
return -1;
 #endif
 }
@@ -234,6 +234,14 @@ static int run_tests(void)
int fd_cloexec = open_or_die("execveat", O_RDONLY|O_CLOEXEC);
int fd_script_cloexec = open_or_die("script", O_RDONLY|O_CLOEXEC);
 
+   /* Check if we have execveat at all, and bail early if not */
+   errno = 0;
+   execveat_(-1, NULL, NULL, NULL, 0);
+   if (errno == ENOSYS) {
+   printf("[FAIL] ENOSYS calling execveat - no kernel support?\n");
+   return 1;
+   }
+
/* Change file position to confirm it doesn't affect anything */
lseek(fd, 10, SEEK_SET);
 
-- 
2.1.0

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

Re: [PATCH v3 0/2][request for stable inclusion] several pstore related bugfixs

[Greg KH]

On Wed, Jan 28, 2015 at 04:06:24PM +0800, HuKeping wrote:
> Hi greg,
> We want to use pstore on linux 3.10. But we found several bugfixs have not
> been merged yet. Most of them are obvious and can be cherry-picked cleanly.
> Would you please apply them to stable 3.10?
> 
> v1 -> v2:
>  - remove d4bf205da618bbd0b038e404d646f14e76915718 which has already been 
> merged
>  - adjust 0405a5cec3406f19e69da07c8111a6bf1088ac29
> 
> v2 -> v3:
>  - attach commit to pstore/ram: avoid atomic accesses for ioremapped regions
> 
> PART 1: patches that can be cleanly applied:
> 
>  bf2883339a33b7544b92ea465b90c3de55082032
>  pstore: Fail to unlink if a driver has not defined pstore_erase
>  
>  c39524e6744284452ef45480d3153bec28960c32
>  pstore: d_alloc_name() doesn't return an ERR_PTR
>  
>  57fd835385a043577457a385f28c08be693991bf
>  pstore: clarify clearing of _read_cnt in ramoops_context
>  
>  aa9a4a1edfbd3d223af01db833da2f07850bc655
>  pstore: skip zero size persistent ram buffer in traverse
>  
>  b0aa931fb84431394d995472d0af2a6c2b61064d
>  pstore: Fix NULL pointer fault if get NULL prz in ramoops_get_next_prz
>  
> PART 2: pathes that should be adjusted:
> 
>  Rob Herring (1):
>   pstore/ram: avoid atomic accesses for ioremapped regions
> 
>  fs/pstore/ram_core.c | 54 
> ++--
>  1 file changed, 52 insertions(+), 2 deletions(-)
> 
>  Madper Xie (1):
>   efi-pstore: Make efi-pstore return a unique id
> 
>  drivers/firmware/efi/efi-pstore.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)

All now applied, along with some of these for 3.14, 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 v2 1/3] hv: hv_util: move vmbus_open() to a later place

[KY Srinivasan]

> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, February 2, 2015 7:09 PM
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
> Subject: RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place
> 
> 
> 
> On Mon, Feb 2, 2015 at 6:09 PM, Dexuan Cui  wrote:
> >>  -Original Message-
> >>  From: Jason Wang [mailto:jasow...@redhat.com]
> >>  Sent: Monday, February 2, 2015 17:36 PM
> >>  To: Dexuan Cui
> >>  Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> >> driverdev-
> >>  de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
> >> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
> >>  Subject: Re: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a
> >> later place
> >>
> >>
> >>
> >>  On Mon, Feb 2, 2015 at 12:35 PM, Dexuan Cui 
> >> wrote:
> >>  > Before the line vmbus_open() returns, srv->util_cb can be already
> >> > running  > and the variables, like util_fw_version, are needed by
> >> the  > srv->util_cb.
> >>
> >>  A questions is why we do this for util only? Can callbacks of other
> >> devices be called before vmbus_open() returns?
> > The variables are used in vmbus_prep_negotiate_resp(), which is only
> > for the util devices.
> >
> > I think the other devices should already handle the similar issue
> > properly.
> > If this is not the case, we need to fix them too.
> 
> Better to check all the others, e.g in balloon_probe(), it call
> hv_set_drvdata() after vmbus_open() and dose several datas setups in the
> middle. If balloon_onchannelcallback() could be called before
> hv_set_drvdata(), the code looks wrong.

Jason,

For all other device types, the guest initiates the communication with the host 
and potentially
negotiates appropriate (supported) version with the host. For the services 
packaged in the util
driver, the flow is a little different - the host pushes the version 
information into the guest. So,
the fix Dexuan made is only needed in the util driver.

Regards,

K. Y 
> 
> Thanks
> 
> 

RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place

[KY Srinivasan]

> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, February 2, 2015 7:38 PM
> To: KY Srinivasan
> Cc: Dexuan Cui; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> driverdev-de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; vkuzn...@redhat.com; Haiyang Zhang
> Subject: RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place
> 
> 
> 
> On Tue, Feb 3, 2015 at 11:30 AM, KY Srinivasan 
> wrote:
> >
> >
> >>  -Original Message-
> >>  From: Jason Wang [mailto:jasow...@redhat.com]
> >>  Sent: Monday, February 2, 2015 7:09 PM
> >>  To: Dexuan Cui
> >>  Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> >> driverdev-
> >>  de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
> >> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
> >>  Subject: RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a
> >> later place
> >>
> >>
> >>
> >>  On Mon, Feb 2, 2015 at 6:09 PM, Dexuan Cui 
> >> wrote:
> >>  >>  -Original Message-
> >>  >>  From: Jason Wang [mailto:jasow...@redhat.com]  >>  Sent: Monday,
> >> February 2, 2015 17:36 PM  >>  To: Dexuan Cui  >>  Cc:
> >> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;  >>
> >> driverdev-  >>  de...@linuxdriverproject.org; o...@aepfle.de;
> >> a...@canonical.com; KY  >> Srinivasan; vkuzn...@redhat.com; Haiyang
> >> Zhang  >>  Subject: Re: [PATCH v2 1/3] hv: hv_util: move vmbus_open()
> >> to a  >> later place  >>  >>  >>  >>  On Mon, Feb 2, 2015 at 12:35
> >> PM, Dexuan Cui   >> wrote:
> >>  >>  > Before the line vmbus_open() returns, srv->util_cb can be
> >> already  >> > running  > and the variables, like util_fw_version, are
> >> needed by  >> the  > srv->util_cb.
> >>  >>
> >>  >>  A questions is why we do this for util only? Can callbacks of
> >> other  >> devices be called before vmbus_open() returns?
> >>  > The variables are used in vmbus_prep_negotiate_resp(), which is
> >> only  > for the util devices.
> >>  >
> >>  > I think the other devices should already handle the similar issue
> >> > properly.
> >>  > If this is not the case, we need to fix them too.
> >>
> >>  Better to check all the others, e.g in balloon_probe(), it call
> >>  hv_set_drvdata() after vmbus_open() and dose several datas setups in
> >> the  middle. If balloon_onchannelcallback() could be called before
> >> hv_set_drvdata(), the code looks wrong.
> >
> > Jason,
> >
> > For all other device types, the guest initiates the communication with
> > the host and potentially negotiates appropriate (supported) version
> > with the host. For the services packaged in the util driver, the flow
> > is a little different - the host pushes the version information into
> > the guest. So, the fix Dexuan made is only needed in the util driver.
> >
> > Regards,
> >
> > K. Y
> 
> Thanks, so you mean for other device, it won't get any interrupt before guest
> negotiate the version with host?

Yes, the guest initiates the version negotiation. Are you seeing something 
different?

K. Y
> >
> >>
> >>  Thanks
> >>
> >>
> >

RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place

[Jason Wang]

On Tue, Feb 3, 2015 at 11:30 AM, KY Srinivasan  
wrote:




 -Original Message-
 From: Jason Wang [mailto:jasow...@redhat.com]
 Sent: Monday, February 2, 2015 7:09 PM
 To: Dexuan Cui
 Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
driverdev-

 de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
 Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
 Subject: RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a 
later place
 
 
 
 On Mon, Feb 2, 2015 at 6:09 PM, Dexuan Cui  
wrote:

 >>  -Original Message-
 >>  From: Jason Wang [mailto:jasow...@redhat.com]
 >>  Sent: Monday, February 2, 2015 17:36 PM
 >>  To: Dexuan Cui
 >>  Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
 >> driverdev-
 >>  de...@linuxdriverproject.org; o...@aepfle.de; 
a...@canonical.com; KY

 >> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
 >>  Subject: Re: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a
 >> later place
 >>
 >>
 >>
 >>  On Mon, Feb 2, 2015 at 12:35 PM, Dexuan Cui 


 >> wrote:
 >>  > Before the line vmbus_open() returns, srv->util_cb can be 
already
 >> > running  > and the variables, like util_fw_version, are needed 
by

 >> the  > srv->util_cb.
 >>
 >>  A questions is why we do this for util only? Can callbacks of 
other

 >> devices be called before vmbus_open() returns?
 > The variables are used in vmbus_prep_negotiate_resp(), which is 
only

 > for the util devices.
 >
 > I think the other devices should already handle the similar issue
 > properly.
 > If this is not the case, we need to fix them too.
 
 Better to check all the others, e.g in balloon_probe(), it call
 hv_set_drvdata() after vmbus_open() and dose several datas setups 
in the

 middle. If balloon_onchannelcallback() could be called before
 hv_set_drvdata(), the code looks wrong.


Jason,

For all other device types, the guest initiates the communication 
with the host and potentially
negotiates appropriate (supported) version with the host. For the 
services packaged in the util
driver, the flow is a little different - the host pushes the version 
information into the guest. So,

the fix Dexuan made is only needed in the util driver.

Regards,

K. Y 


Thanks, so you mean for other device, it won't get any interrupt before 
guest negotiate the version with host?


 
 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/

[PATCH v1] spi: imx: use pio mode for i.mx6dl

[Robin Gong]

For TKT238285 hardware issue which may cause txfifo store data twice can only
be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.

Signed-off-by: Robin Gong 
---
 drivers/spi/spi-imx.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 961b97d..fe1b769 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -823,6 +823,10 @@ static int spi_imx_sdma_init(struct device *dev, struct 
spi_imx_data *spi_imx,
struct dma_slave_config slave_config = {};
int ret;
 
+   /* use pio mode for i.mx6dl chip TKT238285 */
+   if (of_machine_is_compatible("fsl,imx6dl"))
+   return 0;
+
/* Prepare for TX DMA: */
master->dma_tx = dma_request_slave_channel(dev, "tx");
if (!master->dma_tx) {
-- 
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/

[RFC PATCH] ASoC: wm8731: let codec to manage clock by itself

[Bo Shen]

Let the wm8731 codec to manage clock by itself.

As all at91 related boards have been switch to CCF framework. So, on
the at91 related boards which use wm8731 will let it manage the clock,
or else the board use wm8731 is broken.

However, at the same time the wm8731 codec is used on other boards,
I am sure this change will broken some boards.

For example: poodle and corgi based on PXA SoC (in default configuration
file, no one use it). DB1200 board which is a mips based board. So I have
no idea how to fix them.

So, my suggestion is to add CCF check based on the following patch? Any
idea or suggestions?

Signed-off-by: Bo Shen 
---

 sound/soc/codecs/wm8731.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index b9211b4..83f75d66 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -13,6 +13,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -45,6 +46,7 @@ static const char *wm8731_supply_names[WM8731_NUM_SUPPLIES] = 
{
 /* codec private data */
 struct wm8731_priv {
struct regmap *regmap;
+   struct clk *mclk;
struct regulator_bulk_data supplies[WM8731_NUM_SUPPLIES];
const struct snd_pcm_hw_constraint_list *constraints;
unsigned int sysclk;
@@ -389,6 +391,8 @@ static int wm8731_set_dai_sysclk(struct snd_soc_dai 
*codec_dai,
switch (clk_id) {
case WM8731_SYSCLK_XTAL:
case WM8731_SYSCLK_MCLK:
+   if (clk_set_rate(wm8731->mclk, freq))
+   return -EINVAL;
wm8731->sysclk_type = clk_id;
break;
default:
@@ -490,6 +494,7 @@ static int wm8731_set_bias_level(struct snd_soc_codec 
*codec,
 
switch (level) {
case SND_SOC_BIAS_ON:
+   clk_prepare_enable(wm8731->mclk);
break;
case SND_SOC_BIAS_PREPARE:
break;
@@ -508,6 +513,7 @@ static int wm8731_set_bias_level(struct snd_soc_codec 
*codec,
snd_soc_write(codec, WM8731_PWR, reg | 0x0040);
break;
case SND_SOC_BIAS_OFF:
+   clk_disable_unprepare(wm8731->mclk);
snd_soc_write(codec, WM8731_PWR, 0x);
regulator_bulk_disable(ARRAY_SIZE(wm8731->supplies),
   wm8731->supplies);
@@ -666,6 +672,13 @@ static int wm8731_spi_probe(struct spi_device *spi)
if (wm8731 == NULL)
return -ENOMEM;
 
+   wm8731->mclk = devm_clk_get(>dev, "mclk");
+   if (IS_ERR(wm8731->mclk)) {
+   ret = PTR_ERR(wm8731->mclk);
+   dev_err(>dev, "Failed to get MCLK\n");
+   return ret;
+   }
+
mutex_init(>lock);
 
wm8731->regmap = devm_regmap_init_spi(spi, _regmap);
@@ -717,6 +730,13 @@ static int wm8731_i2c_probe(struct i2c_client *i2c,
if (wm8731 == NULL)
return -ENOMEM;
 
+   wm8731->mclk = devm_clk_get(>dev, "mclk");
+   if (IS_ERR(wm8731->mclk)) {
+   ret = PTR_ERR(wm8731->mclk);
+   dev_err(>dev, "Failed to get MCLK\n");
+   return ret;
+   }
+
wm8731->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(wm8731->regmap)) {
ret = PTR_ERR(wm8731->regmap);
-- 
2.3.0.rc0

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

Re: [PATCH v4 6/6] KVM: nVMX: Enable nested posted interrupt processing

[Wincy Van]

On Tue, Feb 3, 2015 at 9:21 AM, Zhang, Yang Z  wrote:
> Paolo Bonzini wrote on 2015-02-03:
>>
>>
>> On 02/02/2015 16:33, Wincy Van wrote:
>>> static void vmx_accomp_nested_posted_intr(struct kvm_vcpu *vcpu) {
>>> struct vcpu_vmx *vmx = to_vmx(vcpu);
>>>
>>> if (is_guest_mode(vcpu) &&
>>> vmx->nested.posted_intr_nv != -1 &&
>>> pi_test_on(vmx->nested.pi_desc))
>>> kvm_apic_set_irr(vcpu,
>>> vmx->nested.posted_intr_nv); }
>>> Then we will get an nested-vmexit in vmx_check_nested_events, that
>>> posted intr will be handled by L1 immediately.
>>> This mechanism will also emulate the hardware's behavior: If a
>>> posted intr was not accomplished by hardware, we will get an
>
> Actually, we cannot say "not accomplished by hardware". It more like we don't 
> do the job well. See my below answer.
>

Yes, exactly.

>>> interrupt with POSTED_INTR_NV.
>>
>> Yes.
>
> This is not enough. From L1's point, L2 is in vmx non-root mode. So we should 
> emulate the posted interrupt in L0 correctly, say:
> 1. clear ON bit
> 2. ack interrupt
> 3, syn pir to virr
> 4. update RVI.
> Then let the hardware(virtual interrupt delivery) to accomplish interrupt 
> injection.
>
> Force a vmexit more like a trick. It's better to follow the hardware's 
> behavior unless we cannot do it.
>

Yes, I will try again to do this.


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

Re: [PATCH] net: sctp: Deletion of an unnecessary check before the function call "kfree"

[David Miller]

From: SF Markus Elfring 
Date: Sat, 31 Jan 2015 18:15:59 +0100

> From: Markus Elfring 
> Date: Sat, 31 Jan 2015 18:10:03 +0100
> 
> The kfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

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

RE: [PATCH] ARM: dts: exynos4412-trats2: Add max77693 charger node

[Kukjin Kim]

Krzysztof Kozlowski wrote:
> 
> Add to Trats2 DTS new node for configuring the max77693 charger driver.
> Only the maxim,constant-microvolt differs from default value but set all
> of the optional properties anyway.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/exynos4412-trats2.dts | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 29231b452643..496a05faca37 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -549,6 +549,16 @@
>   haptic-supply = <_reg>;
>   pwms = < 0 38022 0>;
>   };
> +
> + charger {
> + compatible = "maxim,max77693-charger";
> +
> + maxim,constant-microvolt = <435>;
> + maxim,min-system-microvolt = <360>;
> + maxim,thermal-regulation-celsius = <100>;
> + maxim,battery-overcurrent-microamp = <350>;
> + maxim,charge-input-threshold-microvolt = 
> <430>;
> + };
>   };
>   };
> 
> --

OK, applied.

Thanks,
Kukjin

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

RE: [PATCH 0/3] ARM: dts: Regulator changes and fuel gauge for exynos4412-trats2

[Kukjin Kim]

Krzysztof Kozlowski wrote:
> 
> Hi Kukjin,
> 
Hi,

> 
> I grouped into one patchset already posted patches for Trats2 board:
> 1. Fuel gauge:
>https://lkml.org/lkml/2015/1/7/167
> 2. Suspend configuration for max77686 regulators:
>https://lkml.org/lkml/2014/10/29/262
> 3. GPIO control for max77686 regulators:
>https://lkml.org/lkml/2015/1/5/230
> 
> 
> The necessary changes in max77686 regulator driver were already
> applied by Mark Brown.
> 
Sounds good.

> Best regards,
> Krzysztof
> 
> 
> Krzysztof Kozlowski (3):
>   ARM: dts: exynos4412-trats2: Add Maxim 77693 fuel gauge node
>   ARM: dts: exynos4412-trats2: Add suspend configuration for max77686
> regulators
>   ARM: dts: exynos4412-trats: Switch max77686 regulators to GPIO control
> 
>  arch/arm/boot/dts/exynos4412-trats2.dts | 115 
> ++--
>  1 file changed, 65 insertions(+), 50 deletions(-)
> 
> --

OK, looks good to me, applied this series.

Thanks,
Kukjin

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

Re: [PATCH v2 2/2] task_mmu: Add user-space support for resetting mm->hiwater_rss (peak RSS)

[Petr Cermak]

On Mon, Jan 26, 2015 at 04:00:20PM -0800, David Rientjes wrote:
> [...]
> This is a result of allowing something external (process B) be able to
> clear hwm so that you never knew the value went to 100MB.  That's the
> definition of a race, I don't know how to explain it any better and making
> any connection between clearing PG_referenced and mm->hiwater_rss is a
> stretch.  This approach just makes mm->hiwater_rss meaningless.

I understand your concern, but I hope you agree that the functionality we
are proposing would be very useful for profiling. Therefore, I suggest
adding an extra resettable field to /proc/pid/status (e.g.
resettable_hiwater_rss) instead. What is your view on this approach?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: nvram and generic_nvram modules are problematic, was Re: [PATCH] arch: m68k: mac: misc.c: Remove some unused functions

[Finn Thain]

On Sun, 1 Feb 2015, Geert Uytterhoeven wrote:

> On Sun, Feb 1, 2015 at 4:39 AM, Finn Thain wrote:
> > On Sun, 4 Jan 2015, Geert Uytterhoeven wrote:
> > > On Sun, Jan 4, 2015 at 8:21 AM, Finn Thain wrote:
> > > > On Thu, 1 Jan 2015, Rickard Strandqvist wrote:
> > > > > Removes some functions that are not used anywhere: 
> > > > > mac_pram_write() mac_pram_read()
> > > >
> > > > ... I'd rather not remove all of this code. Better to finish the 
> > > > implementation.
> > >
> > > Indeed.
> > >
> > > > Would it be acceptable to utilize drivers/char/generic_nvram.c and 
> > > > CONFIG_GENERIC_NVRAM? This is the PowerMac PRAM driver but looks 
> > > > generic enough that it may not need any modification for 68k Macs.
> > >
> > > Yes, that would be great.
> > >
> >
> > Unfortunately, it seems to be unworkable.
> 
> An alternative could be to just provide an nvram attribute file in 
> sysfs, like many RTC drivers do.
> 

Are attribute files seekable? Even if userspace could use "/dev/nvram" and 
"/sys/whatever/nvram" interchangably, wouldn't it be better if PPC Macs 
and 68k Macs offered a consistent API to userspace?

And your suggestion doesn't solve the problem, that is, to be able to 
build a multi-platform kernel binary in which drivers can access NVRAM.

The __nvram_read_byte(), nvram_read_byte() etc functions defined in 
drivers/char/nvram.c, if allowed to proliferate because random 
architectures might like to use a generic /dev/nvram API, would further 
uglify that file.

If the m68k Mac kernel doesn't define the nvram_read_byte() routine then 
valkyriefb can't use it. (fbdev drivers are apparently the reason why 
powerpc defines them.)

drivers/char/nvram.c has two sets of these routines for PC RTC NVRAM; one 
for m68k (Atari) and one for arm/x86. We don't want to introduce more code 
into drivers/char/nvram.c to support all four configurations:
1) arm/x86
2) atari
3) atari + mac
4) mac

So we'd end up having to move m68k-specific code out of 
drivers/char/nvram.c, to make it generic. And that then begs all of the 
questions in my previous message.

BTW, my experimental patches replaced all of those __nvram_* and nvram_* 
functions with an ops struct. E.g.

$ cat include/linux/nvram.h 
#ifndef _LINUX_NVRAM_H
#define _LINUX_NVRAM_H

#include 

struct nvram_ops {
ssize_t (*read)(char *, size_t, loff_t *);
ssize_t (*write)(char *, size_t, loff_t *);
unsigned char   (*read_byte)(int);
void(*write_byte)(unsigned char, int);
ssize_t (*get_size)(void);
#ifdef CONFIG_PPC
void(*sync)(void);
#else
long(*set_checksum)(void);
long(*initialize)(void);
#endif
};

extern const struct nvram_ops arch_nvram_ops;

extern const struct nvram_ops rtc_nvram_ops;

#endif  /* _LINUX_NVRAM_H */


This experiment has m68k implement arch_nvram_ops that dispatch to Atari 
or Mac methods (at compile-time for a single-platform kernel, or at 
run-time for a multi-platform kernel binary).

But this implies modifications to fbdev drivers, PPC32 and PPC64, nvram 
and generic_nvram modules. And any work at all done on generic_nvram seems 
to be misguided, unless it is removal.

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: EXYNOS: Handle of of_iomap() failure

[Kukjin Kim]

Krzysztof Kozlowski wrote:
> 
> Prevent possible NULL pointer dereference if of_iomap() fails. Handle
> the error by skipping such power domain.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/mach-exynos/pm_domains.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/pm_domains.c 
> b/arch/arm/mach-exynos/pm_domains.c
> index 20f267121b3e..fd7640a6b503 100644
> --- a/arch/arm/mach-exynos/pm_domains.c
> +++ b/arch/arm/mach-exynos/pm_domains.c
> @@ -128,6 +128,13 @@ static __init int exynos4_pm_init_power_domain(void)
>   pd->pd.name = kstrdup(np->name, GFP_KERNEL);
>   pd->name = pd->pd.name;
>   pd->base = of_iomap(np, 0);
> + if (!pd->base) {
> + dev_warn(>dev, "Failed to map memory\n");
> + kfree(pd);
> + of_node_put(np);
> + continue;
> + }
> +
>   pd->pd.power_off = exynos_pd_power_off;
>   pd->pd.power_on = exynos_pd_power_on;
> 
> --

Looks good and applied. BTW if we need more error handling like this, how about
error handling for failing of of_find_device_by_node() something like following?

diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index 20f2671..234f967 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -116,6 +116,10 @@ static __init int exynos4_pm_init_power_domain(void)
struct device *dev;

pdev = of_find_device_by_node(np);
+   if (!pdev) {
+   /* error handling */
+   }
+
dev = >dev;

pd = kzalloc(sizeof(*pd), GFP_KERNEL);

I mean I'm not sure how many error/exception handling is required...

Note you can see your patch in Samsung tree tonight in my time.

Thanks, Kukjin

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

RE: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place

[Jason Wang]

On Mon, Feb 2, 2015 at 6:09 PM, Dexuan Cui  wrote:

 -Original Message-
 From: Jason Wang [mailto:jasow...@redhat.com]
 Sent: Monday, February 2, 2015 17:36 PM
 To: Dexuan Cui
 Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
driverdev-

 de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
 Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
 Subject: Re: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a 
later place
 
 
 
 On Mon, Feb 2, 2015 at 12:35 PM, Dexuan Cui  
wrote:

 > Before the line vmbus_open() returns, srv->util_cb can be already
 > running
 > and the variables, like util_fw_version, are needed by the
 > srv->util_cb.
 
 A questions is why we do this for util only? Can callbacks of other

 devices be called before vmbus_open() returns?
The variables are used in vmbus_prep_negotiate_resp(), which is only 
for

the util devices.

I think the other devices should already handle the similar issue 
properly.

If this is not the case, we need to fix them too.


Better to check all the others, e.g in balloon_probe(), it call 
hv_set_drvdata() after vmbus_open() and dose several datas setups in 
the middle. If balloon_onchannelcallback() could be called before 
hv_set_drvdata(), the code looks wrong.


Thanks



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

Re: [PATCH v2 08/12] drm: bridge/dw_hdmi: add audio config interfaces

[Yang Kuankuan]

On 02/02/2015 08:09 AM, Russell King - ARM Linux wrote:

On Mon, Feb 02, 2015 at 07:32:05AM -0500, Yang Kuankuan wrote:

On 02/02/2015 06:53 AM, Russell King - ARM Linux wrote:

On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote:

Hi ykk,

On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan  wrote:

On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote:

+void hdmi_audio_clk_enable(struct dw_hdmi *hdmi)
+{
+   if (hdmi->audio_enable)
+   return;
+
+   mutex_lock(>audio_mutex);
+   hdmi->audio_enable = true;
+   hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
HDMI_MC_CLKDIS);
+   mutex_unlock(>audio_mutex);

This is racy.  The test needs to be within the mutex-protected region.

This function will be called by other driver (dw-hdmi-audio), both modify
the variable "hdmi->audio_enable", so i add the mutex-protected.

>From your comment it isn't clear whether you understand what Russell meant.
He is say you should do the following:

{
mutex_lock(>audio_mutex);

if (hdmi->audio_enable) {
   mutex_unlock(>audio_mutex);
   return;
}
hdmi->audio_enable = true;
hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);

mutex_unlock(>audio_mutex);
}

Yes, however, I prefer this kind of layout:

mutex_lock(>audio_mutex);
if (!hdmi->audio_enable) {
hdmi->audio_enable = true;
hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE,
  HDMI_MC_CLKDIS);
}

mutex_unlock(>audio_mutex);

but that's a matter of personal opinion.  The important thing is that the
testing and setting of the flag are both within the protected region.

However, there are other bugs here: what if the audio driver is calling
the sample rate setting function at the same time that a mode switch is
occuring.  We actually need a mutex to protect more than just the
audio_enable flag.

Okay, got it.

Thanks.  : )

I've been moving my code closer to what you have posted.  I've split up
your patches into smaller steps so each change can be evaluated on iMX6.
So far:


Thank you very much.  : )



drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and 
hdmi_regenerate_cts()

   This patch _just_ combines the two functions without any other changes.

drm: bridge/dw_hdmi: protect n/cts setting with a mutex

   This patch _just_ adds a mutex to protect the calls to
   hdmi_set_clk_regenerator(), since we will need to call that from both
   the DRM and audio drivers.

drm: bridge/dw_hdmi: adjust n/cts setting order

   This patch changes the order to:
   - write CTS3 CTS_manual = 0
   - write CTS3 N_shift = 0
   - write CTS3 CTS value
   - write CTS2 CTS value
   - write CTS1 CTS value
   - write N3 N value
   - write N2 N value
   - write N1 N value
   which is broadly what you're doing, but without the initial N3 write
   and without CTS_manual=1.  I've asked Freescale whether they can
   clarify what effect adding those would have on their SoCs.

Note: the mutex in my second patch needs to be a spinlock - as it seems
my new workaround for iMX6 ERR005174 needs to call the CTS/N setting
functions in an irqs-off region (from the ALSA ->trigger callback.)
That will need further rework of the CTS/N code to reduce the size of
the spinlock protected region.

Incidentally, your Synopsis IP indicates that it is the same revision
as the iMX6's IP revision which suffers from this ERR005174 errata.
I think you need to check whether this errata applies on your SoC too.
Seach for "iMX6 ERR005174" in google.



By the way, it doesn't matter that the function is called from another driver.
What matters is that this function can be called concurrently on
multiple different threads of execution to change the hdmi audio
enable state.
>From DRM land, it is called with DRM lock held when enabling/disabling
hdmi audio (mode_set / DPMS).
It is also called from audio land, when enabling/disabling audio in
response to some audio events (userspace ioctls?).  I'm not sure
exactly how the audio side works, or what locks are involved, but this
mutex synchronizes calls from these two worlds to ensure that
"hdmi->audio_enable" field always matches the current (intended)
status of the hdmi audio clock.  This would be useful, for example, if
you needed to temporarily disable all HDMI clocks during a mode set,
and then restore the audio clock to its pre-mode_set state:

There's some rather quirky comments in the driver right now which make
me uneasy about changing things too much.

My initial idea would be that audio should remain disabled until the
audio driver wants it enabled, and the CTS/N values should either be
left alone, or set to a value which disables them (there is an iMX6
errata which says to set N=0 initially, but as seems common with iMX6
errata, I see no code implementing the method specified in the
documentation - I have found code implementing something similar

Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request

[Minchan Kim]

On Tue, Feb 03, 2015 at 10:54:33AM +0900, Sergey Senozhatsky wrote:
> On (02/02/15 16:06), Sergey Senozhatsky wrote:
> > So, guys, how about doing it differently, in less lines of code,
> > hopefully. Don't move reset_store()'s work to zram_reset_device().
> > Instead, move
> > 
> > set_capacity(zram->disk, 0);
> > revalidate_disk(zram->disk);
> > 
> > out from zram_reset_device() to reset_store(). this two function are
> > executed only when called from reset_store() anyway. this also will let
> > us drop `bool reset capacity' param from zram_reset_device().
> > 
> > 
> > so we will do in reset_store()
> > 
> > mutex_lock(bdev->bd_mutex);
> > 
> > fsync_bdev(bdev);
> > zram_reset_device(zram);
> > set_capacity(zram->disk, 0);
> > 
> > mutex_unlock(>bd_mutex);
> > 
> > revalidate_disk(zram->disk);
> > bdput(bdev);
> > 
> > 
> > 
> > and change zram_reset_device(zram, false) call to simply 
> > zram_reset_device(zram)
> > in __exit zram_exit(void).
> > 
> 
> Hello,
> 
> Minchan, Ganesh, I sent a patch last night, with the above solution.
> looks ok to you?

Just I sent a feedback.

> 
> Minchan, I think I'll send my small struct zram clean-up patch after
> your init_lock patch. what's your opinion?

Good for me.

Thanks.
-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] zram: fix umount-reset_store-mount race condition

[Minchan Kim]

Hello Sergey,

On Mon, Feb 02, 2015 at 11:08:40PM +0900, Sergey Senozhatsky wrote:
> Ganesh Mahendran was the first one who proposed to use bdev->bd_mutex
> to avoid ->bd_holders race condition:
> 
> CPU0CPU1
> umount /* zram->init_done is true */
> reset_store()
> bdev->bd_holders == 0   mount
> ... zram_make_request()
> zram_reset_device()
> 
> However, his solution required some considerable amount of code movement,
> which we can avoid.
> 
> Apart from using bdev->bd_mutex in reset_store(), this patch also
> simplifies zram_reset_device().
> 
> zram_reset_device() has a bool parameter reset_capacity which tells
> it whether disk capacity and itself disk should be reset. There are
> two zram_reset_device() callers:
> -- zram_exit() passes reset_capacity=false
> -- reset_store() passes reset_capacity=true
> 
> So we can move reset_capacity-sensitive work out of zram_reset_device()
> and perform it unconditionally in reset_store(). This also lets us drop
> reset_capacity parameter from zram_reset_device() and pass zram pointer
> only.
> 
> Reported-by: Ganesh Mahendran 
> Signed-off-by: Sergey Senozhatsky 

Looks good to me but as I told you, we need to check processes open
the block device as !FMODE_EXCL.
I can make following warning with below simple script.
In addition, I added msleep(2000) below set_capacity(zram->disk, 0)
after applying your patch to make window huge(Kudos to Ganesh!)

#!/bin/bash

echo $((60<<30)) > /sys/block/zram0/disksize
# Check your kernel turns on CONFIG_SCHED_AUTOGROUP=y
# I have no idea why it doesn't happen without setsid and 
CONFIG_SCHED_AUTOGROUP=y
# Please let me know it if someone can know the reason.
setsid dd if=/dev/zero of=/dev/zram0 &
sleep 1
setsid echo 1 > /sys/block/zram0/reset

[   30.683449] zram0: detected capacity change from 0 to 64424509440
[   33.736869] Buffer I/O error on dev zram0, logical block 180823, lost async 
page write
[   33.738814] Buffer I/O error on dev zram0, logical block 180824, lost async 
page write
[   33.740654] Buffer I/O error on dev zram0, logical block 180825, lost async 
page write
[   33.742551] Buffer I/O error on dev zram0, logical block 180826, lost async 
page write
[   33.744153] Buffer I/O error on dev zram0, logical block 180827, lost async 
page write
[   33.745807] Buffer I/O error on dev zram0, logical block 180828, lost async 
page write
[   33.747419] Buffer I/O error on dev zram0, logical block 180829, lost async 
page write
[   33.749060] Buffer I/O error on dev zram0, logical block 180830, lost async 
page write
[   33.750687] Buffer I/O error on dev zram0, logical block 180831, lost async 
page write
[   33.752286] Buffer I/O error on dev zram0, logical block 180832, lost async 
page write
[   33.811590] [ cut here ]
[   33.812038] WARNING: CPU: 11 PID: 1996 at fs/block_dev.c:57 
__blkdev_put+0x1d7/0x210()
[   33.812817] Modules linked in: 
[   33.813142] CPU: 11 PID: 1996 Comm: dd Not tainted 3.19.0-rc6-next-20150202+ 
#1125
[   33.813837] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Bochs 01/01/2011
[   33.814525]  81801a2d 880061e77db8 815b848e 
0001
[   33.815196]   880061e77df8 8104de2a 

[   33.815867]  88005da287f0 88005da28680 88005da28770 
88005da28698
[   33.816536] Call Trace:
[   33.816817]  [] dump_stack+0x45/0x57
[   33.817304]  [] warn_slowpath_common+0x8a/0xc0
[   33.817829]  [] warn_slowpath_null+0x1a/0x20
[   33.818331]  [] __blkdev_put+0x1d7/0x210
[   33.818797]  [] blkdev_put+0x50/0x130
[   33.819244]  [] blkdev_close+0x25/0x30
[   33.819723]  [] __fput+0xdf/0x1e0
[   33.820140]  [] fput+0xe/0x10
[   33.820576]  [] task_work_run+0xa7/0xe0
[   33.821151]  [] do_notify_resume+0x49/0x60
[   33.821721]  [] int_signal+0x12/0x17
[   33.88] ---[ end trace 274fbbc5664827d2 ]---

The warning comes from bdev_write_node in blkdev_put path.

tatic void bdev_write_inode(struct inode *inode)
{
spin_lock(>i_lock);
while (inode->i_state & I_DIRTY) {
spin_unlock(>i_lock);
WARN_ON_ONCE(write_inode_now(inode, true)); <= here.
spin_lock(>i_lock);
}
spin_unlock(>i_lock);
}

The reason is dd process encounters I/O fails due to sudden block device
disappear so in filemap_check_errors in __writeback_single_inode returns
-EIO.

If we checks bd_openners instead of bd_holders, we could address the
problem. When I see the brd, it already have used it rather than
bd_holders so although I'm not a expert of block layer, it seems
to be better.

> ---
>  drivers/block/zram/zram_drv.c | 23 +--
>  1 file changed, 9 insertions(+), 14 deletions(

Re: [PATCH] net/tulip: don't warn about unknown ARM architecture

[David Miller]

From: Arnd Bergmann 
Date: Fri, 30 Jan 2015 22:58:19 +0100

> ARM has 32-byte cache lines, which according to the comment in
> the init registers function seems to work best with the default
> value of 0x4800 that is also used on sparc and parisc.
> 
> This adds ARM to the same list, to use that default but no
> longer warn about it.
> 
> Signed-off-by: Arnd Bergmann 

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

Re: [PATCH v3 24/24] vfio: powerpc/spapr: Support Dynamic DMA windows

[Alex Williamson]

On Thu, 2015-01-29 at 20:22 +1100, Alexey Kardashevskiy wrote:
> This adds create/remove window ioctls to create and remove DMA windows.
> 
> This changes VFIO_IOMMU_SPAPR_TCE_GET_INFO handler to return additional
> information such as a number of supported windows and maximum number
> levels of TCE tables.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
>  arch/powerpc/include/asm/iommu.h|   2 +-
>  drivers/vfio/vfio_iommu_spapr_tce.c | 137 
> +++-
>  include/uapi/linux/vfio.h   |  24 ++-
>  3 files changed, 160 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/iommu.h 
> b/arch/powerpc/include/asm/iommu.h
> index 33009f9..7ca1c8c 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -133,7 +133,7 @@ extern void iommu_free_table(struct iommu_table *tbl, 
> const char *node_name);
>  extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
>   int nid);
>  
> -#define POWERPC_IOMMU_MAX_TABLES 1
> +#define POWERPC_IOMMU_MAX_TABLES 2
>  
>  #define POWERPC_IOMMU_DEFAULT_LEVELS 1
>  
> diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c 
> b/drivers/vfio/vfio_iommu_spapr_tce.c
> index 8bcafb7..d3a1cc9 100644
> --- a/drivers/vfio/vfio_iommu_spapr_tce.c
> +++ b/drivers/vfio/vfio_iommu_spapr_tce.c
> @@ -300,6 +300,20 @@ static struct iommu_table *spapr_tce_find_table(
>   return ret;
>  }
>  
> +static int spapr_tce_find_free_table(struct tce_container *container)
> +{
> + int i;
> +
> + for (i = 0; i < POWERPC_IOMMU_MAX_TABLES; ++i) {
> + struct iommu_table *tbl = >tables[i];
> +
> + if (!tbl->it_size)
> + return i;
> + }
> +
> + return -1;
> +}
> +
>  static unsigned long tce_default_winsize(struct tce_container *container)
>  {
>   struct tce_iommu_group *tcegrp;
> @@ -594,7 +608,7 @@ static long tce_iommu_ioctl(void *iommu_data,
>unsigned int cmd, unsigned long arg)
>  {
>   struct tce_container *container = iommu_data;
> - unsigned long minsz;
> + unsigned long minsz, ddwsz;
>   long ret;
>  
>   switch (cmd) {
> @@ -636,6 +650,15 @@ static long tce_iommu_ioctl(void *iommu_data,
>  
>   info.dma32_window_start = iommu->tce32_start;
>   info.dma32_window_size = iommu->tce32_size;
> + info.windows_supported = iommu->windows_supported;
> + info.levels = iommu->levels;
> + info.flags = iommu->flags;
> +
> + ddwsz = offsetofend(struct vfio_iommu_spapr_tce_info,
> + levels);
> +
> + if (info.argsz == ddwsz)
> + minsz = ddwsz;
>  
>   if (copy_to_user((void __user *)arg, , minsz))
>   return -EFAULT;
> @@ -800,6 +823,118 @@ static long tce_iommu_ioctl(void *iommu_data,
>   return ret;
>   }
>  
> + case VFIO_IOMMU_SPAPR_TCE_CREATE: {
> + struct vfio_iommu_spapr_tce_create create;
> + struct powerpc_iommu *iommu;
> + struct tce_iommu_group *tcegrp;
> + int num;
> +
> + if (!tce_preregistered(container))
> + return -ENXIO;
> +
> + minsz = offsetofend(struct vfio_iommu_spapr_tce_create,
> + start_addr);
> +
> + if (copy_from_user(, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + if (create.argsz < minsz)
> + return -EINVAL;
> +
> + if (create.flags)
> + return -EINVAL;
> +
> + num = spapr_tce_find_free_table(container);
> + if (num < 0)
> + return -ENOSYS;
> +
> + tcegrp = list_first_entry(>group_list,
> + struct tce_iommu_group, next);
> + iommu = iommu_group_get_iommudata(tcegrp->grp);
> +
> + ret = iommu->ops->create_table(iommu, num,
> + create.page_shift, create.window_shift,
> + create.levels,
> + >tables[num]);
> + if (ret)
> + return ret;
> +
> + list_for_each_entry(tcegrp, >group_list, next) {
> + struct powerpc_iommu *iommutmp =
> + iommu_group_get_iommudata(tcegrp->grp);
> +
> + if (WARN_ON_ONCE(iommutmp->ops != iommu->ops))
> + return -EFAULT;
> +
> + ret = iommu->ops->set_window(iommutmp, num,
> + >tables[num]);
> + if (ret)
> + return ret;
> + }
> +
> + create.start_addr =
> + container->tables[num].it_offset <<
> +  

Re: [Patch Part2 v4 00/33] Clean up obsoleted x86 interrupt manangement code and interfaces

[Jiang Liu]

Ping)

On 2015/1/20 13:51, Jiang Liu wrote:
> This is a following-on patch of "[Patch Part1 v7 00/38] Convert x86 to
> hierarchy irqdomain and stacked irqchip" at
> https://lkml.org/lkml/2015/1/19/685
> 
> The precedent patch has convert x86 interrupt management subsystem to
> hierarchy irqdomain and stacked irqchip, so this patch set cleans up
> code and interfaces obsoleted by the precedent patch set.
> 
> Main changes since last version:
> 1) rebased onto v3.19-rc5
> 2) add patch 33 to avoid memory allocation/free when assigning CPU vector 
> 
> Regards,
> Gerry
> 
> Jiang Liu (29):
>   x86/irq: Kill unused old IOAPIC irqdomain interfaces
>   x86/irq: Kill unused struct mp_pin_info
>   x86/irq: Kill x86_io_apic_ops.print_entries and related interfaces
>   x86/irq: Kill x86_io_apic_ops.setup_entry and related interfaces
>   x86/irq: Kill x86_io_apic_ops.set_affinity and related interfaces
>   x86/irq: Kill x86_io_apic_ops.eoi_ioapic_pin and related interfaces
>   x86/irq: Kill GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
>   x86/irq: Clean up unused forward declarations in x86_init.h
>   irq_remapping: Clean up unsued code to support IOAPIC
>   irq_remapping/vt-d: Clean up unsued code
>   irq_remapping/amd: Clean up unsued code
>   irq_remapping: Clean up unused interfaces
>   x86/irq: Kill irq_cfg.irq_remapped
>   irq_remapping/vt-d: Move struct irq_2_iommu into
> intel_irq_remapping.c
>   irq_remapping/amd: Move struct irq_2_irte into amd_iommu.c
>   x86/irq: Move irq_cfg.irq_2_pin into io_apic.c
>   x86/irq: Kill struct io_apic_irq_attr
>   x86/irq: Kill x86_io_apic_ops.write and x86_io_apic_ops.modify
>   x86/irq: Clean up io_apic.h
>   x86/irq: Use cached IOAPIC entry instead of reading from hardware
>   x86/irq: Kill unused alloc_irq_and_cfg_at()
>   x86/irq: Change functions only used in vector.c as static
>   x86/irq: Kill function apic_set_affinity()
>   x86/irq: Move check of cfg->move_in_progress into
> send_cleanup_vector()
>   x86/irq: Move private data in struct irq_cfg into dedicated data
> structure
>   x86/irq: Refine the way to calculate NR_IRQS
>   x86/irq, ACPI: Kill private function mp_register_gsi()/
> mp_unregister_gsi()
>   x86/irq: Move irqdomain specific code into asm/irqdomain.h
>   x86/irq: Avoid memory allocation in __assign_irq_vector()
> 
> Thomas Gleixner (4):
>   x86/irq: Remove sis apic bug workaround
>   x86, ioapic: Use proper defines for the entry fields
>   x86,ioapic: Cleanup irq_trigger/polarity()
>   x86: Cleanup irq_domain ops
> 
>  arch/x86/Kconfig |1 -
>  arch/x86/include/asm/hw_irq.h|   63 ---
>  arch/x86/include/asm/io_apic.h   |  108 +
>  arch/x86/include/asm/irq_remapping.h |   38 +-
>  arch/x86/include/asm/irq_vectors.h   |   18 +-
>  arch/x86/include/asm/irqdomain.h |   63 +++
>  arch/x86/include/asm/x86_init.h  |   16 -
>  arch/x86/kernel/acpi/boot.c  |   70 +--
>  arch/x86/kernel/apic/htirq.c |2 +-
>  arch/x86/kernel/apic/io_apic.c   |  868 
> +-
>  arch/x86/kernel/apic/msi.c   |2 +-
>  arch/x86/kernel/apic/vector.c|  342 ++
>  arch/x86/kernel/devicetree.c |   12 +-
>  arch/x86/kernel/hpet.c   |2 +-
>  arch/x86/kernel/mpparse.c|9 +-
>  arch/x86/kernel/x86_init.c   |6 -
>  arch/x86/platform/sfi/sfi.c  |   10 +-
>  arch/x86/platform/uv/uv_irq.c|5 +-
>  drivers/iommu/amd_iommu.c|  153 +-
>  drivers/iommu/intel_irq_remapping.c  |  206 +---
>  drivers/iommu/irq_remapping.c|   80 
>  drivers/iommu/irq_remapping.h|   16 -
>  drivers/pci/quirks.c |7 -
>  23 files changed, 490 insertions(+), 1607 deletions(-)
>  create mode 100644 arch/x86/include/asm/irqdomain.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 v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()

[Chen Gang S]

On 2/3/15 10:32, Chen Gang S wrote:
> On 2/3/15 05:20, Joe Perches wrote:
>> On Tue, 2015-02-03 at 05:14 +0800, Chen Gang S wrote:
>>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
>>> be constant, or may cause build warning. The related warning (with
>>> allmodconfig under xtensa):
>> []
>>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
>> []
>>> @@ -46,7 +46,7 @@ struct hci_pinfo {
>>> unsigned shortchannel;
>>>  };
>>>  
>>> -static inline int hci_test_bit(int nr, void *addr)
>>> +static inline int hci_test_bit(int nr, const void *addr)
>>>  {
>>> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
>>>  }
>>
>> It's probably better to use const __u32 * here too, but the
>> real thing I wonder is whether or not there's an issue with
>> one of the 2 uses of this function.
>>
>> One of them passes a unsigned long *, the other a u32 *.
>>
>> $ git grep -w hci_test_bit
>> net/bluetooth/hci_sock.c:static inline int hci_test_bit(int nr, void *addr)
>> net/bluetooth/hci_sock.c:   if (!hci_test_bit(flt_event, 
>> >event_mask))
>> net/bluetooth/hci_sock.c:!hci_test_bit(ocf & 
>> HCI_FLT_OCF_BITS,
>> net/bluetooth/hci_sock.c-  
>> _sec_filter.ocf_mask[ogf])) &&
>>
>> hci_sec_filter.ocf_mask is __u32
>> but flt->event_mask is unsigned long.
>>
>> Any possible issue here on 64-bit systems?
>>
> 
> For me, it can not cause issue on 64-bit systems. hci_test_bit() treats
> 'addr' as "__u32 *", and has to use the pointer to do something.
> 

'event_mask' is intended to type cast to "__u32 *" within 'hci_sock.c'.
So for me, "const __u32 *" is better than "const void *" for 2nd
parameter of hci_test_bit().

If what I said above is correct, and also if necessary, I shall patch v3
for it.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Part1 v7 00/38] Convert x86 to hierarchy irqdomain and stacked irqchip

[Jiang Liu]

Ping:)

On 2015/1/20 11:08, Jiang Liu wrote:
> Hi all,
>   The generic hierarchy irqdomain and stacked irqchip implementation
> has been merged into v3.19, so this patch set converts x86 interupt
> management to hierarchy irqdomain and stacked irqchip. I will send out
> another following-on patch set to clean up code and interfaces obseleted
> by this patch set.
> 
>   This patch set has been reviewed several times and it missed v3.19
> merging because several got fixed just before the merging window.
>   The main changes since last review are:
> 1) Rebased the patch set onto v3.19-rc5.
> 2) Merged bugfixes into the patch introducing the bug so it won't break
>bisecting.
> 
> Hi Thomas,
>   Rafael needs more time to review the patch set to refine ACPI
> resource paring interface, and we are nearing to v3.19-rc6. So it would
> be helpful to move onto the x86 hierarchy irqdomain patch set first, so
> we may catch up with v3.20 merging window.
> Thanks!
> Gerry
> 
> Jiang Liu (36):
>   x86/irq: Save destination CPU ID in irq_cfg
>   x86/irq: Use hierarchy irqdomain to manage CPU interrupt vectors
>   x86/hpet: Use new irqdomain interfaces to allocate/free IRQ
>   x86/MSI: Use new irqdomain interfaces to allocate/free IRQ
>   x86/uv: Use new irqdomain interfaces to allocate/free IRQ
>   x86/htirq: Use new irqdomain interfaces to allocate/free IRQ
>   x86/dmar: Use new irqdomain interfaces to allocate/free IRQ
>   irq_remapping: Introduce new interfaces to support hierarchy
> irqdomain
>   irq_remapping/vt-d: Change prototypes to prepare for enabling
> hierarchy irqdomain
>   irq_remapping/vt-d: Enhance Intel IR driver to suppport hierarchy
> irqdomain
>   irq_remapping/amd: Enhance AMD IR driver to suppport hierarchy
> irqdomain
>   x86/hpet: Enhance HPET IRQ to support hierarchy irqdomain
>   x86/MSI: Use hierarchy irqdomain to manage MSI interrupts
>   x86/irq: Directly call native_compose_msi_msg() for DMAR IRQ
>   irq_remapping/vt-d: Clean up unused MSI related code
>   irq_remapping/amd: Clean up unused MSI related code
>   irq_remapping: Clean up unused MSI related code
>   x86/MSI: Clean up unused MSI related code and interfaces
>   iommu/vt-d: Refine the interfaces to create IRQ for DMAR unit
>   x86/irq: Use hierarchy irqdomain to manage DMAR interrupts
>   x86/htirq: Use hierarchy irqdomain to manage Hypertransport
> interrupts
>   x86/uv: Use hierarchy irqdomain to manage UV interrupts
>   x86/irq: Normalize x86 irq_chip name
>   x86/MSI: Simplify the way to deal with remapped MSI interrupts
>   x86/MSI: Replace msi_update_msg() with irq_chip_compose_msi_msg()
>   x86/irq: Implement irq_chip.irq_write_msi_msg for MSI/DMAR/HPET
> irq_chips
>   x86/irq: Simplify MSI/DMAR/HPET implementation by using common code
>   irq_remapping: Kill unused function irq_remapping_print_chip()
>   x86/intel-mid, trivial: Refine code syntax for sfi_parse_mtmr()
>   x86/irq: Kill unused pre_init_apic_IRQ0()
>   x86/irq: Prepare IOAPIC interfaces to support hierarchy irqdomain
>   x86/irq: Implement callbacks to enable hierarchy irqdomain on IOAPICs
>   x86/irq: Refine the way to allocate irq_cfg for legacy IRQs
>   x86/irq: Simplify the way to print IOAPIC entry
>   x86/irq: Introduce helper functions to support hierarchy irqdomain
> for IOAPIC
>   x86/irq: Convert IOAPIC to use hierarchy irqdomain interfaces
> 
> Rickard Strandqvist (1):
>   x86/apb_timer: Remove unused function is_apbt_capable()
> 
> Thomas Gleixner (1):
>   x86/intel-mid: Delay initialization of APB timer
> 
>  arch/ia64/include/asm/irq_remapping.h  |2 -
>  arch/ia64/kernel/msi_ia64.c|   30 +-
>  arch/x86/Kconfig   |4 +-
>  arch/x86/include/asm/hpet.h|   16 +-
>  arch/x86/include/asm/hw_irq.h  |   91 +++
>  arch/x86/include/asm/io_apic.h |   25 +-
>  arch/x86/include/asm/irq_remapping.h   |   45 +-
>  arch/x86/include/asm/msi.h |7 +
>  arch/x86/include/asm/pci.h |5 -
>  arch/x86/include/asm/x86_init.h|4 -
>  arch/x86/kernel/acpi/boot.c|   20 +-
>  arch/x86/kernel/apb_timer.c|   12 -
>  arch/x86/kernel/apic/htirq.c   |  173 --
>  arch/x86/kernel/apic/io_apic.c |  600 
> +++-
>  arch/x86/kernel/apic/msi.c |  416 --
>  arch/x86/kernel/apic/vector.c  |  205 ++-
>  arch/x86/kernel/devicetree.c   |   37 +-
>  arch/x86/kernel/hpet.c |   57 +-
>  arch/x86/kernel/mpparse.c  |6 +-
>  arch/x86/kernel/x86_init.c |2 -
>  arch/x86/pci/intel_mid_pci.c   |6 +-
>  

Re: [f2fs-dev] [PATCH 5/5 v2] f2fs: introduce a batched trim

[Changman Lee]

Hi Jaegeuk,

IMHO, it looks better user could decide the size of trim considering latency of 
trim.
Otherwise, additional checkpoints user doesn't want will occur.

Regards,
Changman

On Mon, Feb 02, 2015 at 03:29:25PM -0800, Jaegeuk Kim wrote:
> Change long from v1:
>  o add description
>  o change the # of batched segments suggested by Chao
>  o make consistent for # of batched segments
> 
> This patch introduces a batched trimming feature, which submits split discard
> commands.
> 
> This patch introduces a batched trimming feature, which submits split discard
> commands.
> 
> This is to avoid long latency due to huge trim commands.
> If fstrim was triggered ranging from 0 to the end of device, we should lock
> all the checkpoint-related mutexes, resulting in very long latency.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h|  2 ++
>  fs/f2fs/segment.c | 16 +++-
>  2 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 8231a59..ec5e66f 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -105,6 +105,8 @@ enum {
>   CP_DISCARD,
>  };
>  
> +#define BATCHED_TRIM_SEGMENTS(sbi)   (((sbi)->segs_per_sec) << 5)
> +
>  struct cp_control {
>   int reason;
>   __u64 trim_start;
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 5ea57ec..b85bb97 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1066,14 +1066,20 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct 
> fstrim_range *range)
>   end_segno = (end >= MAX_BLKADDR(sbi)) ? MAIN_SEGS(sbi) - 1 :
>   GET_SEGNO(sbi, end);
>   cpc.reason = CP_DISCARD;
> - cpc.trim_start = start_segno;
> - cpc.trim_end = end_segno;
>   cpc.trim_minlen = range->minlen >> sbi->log_blocksize;
>  
>   /* do checkpoint to issue discard commands safely */
> - mutex_lock(>gc_mutex);
> - write_checkpoint(sbi, );
> - mutex_unlock(>gc_mutex);
> + for (; start_segno <= end_segno;
> + start_segno += BATCHED_TRIM_SEGMENTS(sbi)) {
> + cpc.trim_start = start_segno;
> + cpc.trim_end = min_t(unsigned int,
> + start_segno + BATCHED_TRIM_SEGMENTS (sbi) - 1,
> + end_segno);
> +
> + mutex_lock(>gc_mutex);
> + write_checkpoint(sbi, );
> + mutex_unlock(>gc_mutex);
> + }
>  out:
>   range->len = cpc.trimmed << sbi->log_blocksize;
>   return 0;
> -- 
> 2.1.1
> 
> 
> --
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> ___
> 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] Documentation: Update netlink_mmap.txt

[David Miller]

From: Richard Weinberger 
Date: Fri, 30 Jan 2015 20:50:44 +0100

> Update netlink_mmap.txt wrt. commit 4682a0358639b29cf
> ("netlink: Always copy on mmap TX.").
> 
> Signed-off-by: Richard Weinberger 

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

[PATCH v2] i7core_edac: release resources on error in i7core_create_sysfs_devices

[Junjie Mao]

v2: do not call kfree on allocated devs after device_initialize is called

Signed-off-by: Junjie Mao 
---
 drivers/edac/i7core_edac.c | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 9cd0b301f81b..f6a7b676d69c 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1167,17 +1167,17 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)
return rc;
rc = device_create_file(>dev, _attr_inject_type);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_section;
rc = device_create_file(>dev, _attr_inject_eccmask);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_type;
rc = device_create_file(>dev, _attr_inject_enable);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_eccmask;

pvt->addrmatch_dev = kzalloc(sizeof(*pvt->addrmatch_dev), GFP_KERNEL);
if (!pvt->addrmatch_dev)
-   return rc;
+   goto fail_remove_inject_enable;

pvt->addrmatch_dev->type = _type;
pvt->addrmatch_dev->bus = mci->dev.bus;
@@ -1190,16 +1190,13 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)

rc = device_add(pvt->addrmatch_dev);
if (rc < 0)
-   return rc;
+   goto fail_free_addrmatch_dev;

if (!pvt->is_registered) {
pvt->chancounts_dev = kzalloc(sizeof(*pvt->chancounts_dev),
  GFP_KERNEL);
-   if (!pvt->chancounts_dev) {
-   put_device(pvt->addrmatch_dev);
-   device_del(pvt->addrmatch_dev);
-   return rc;
-   }
+   if (!pvt->chancounts_dev)
+   goto fail_del_addrmatch_dev;

pvt->chancounts_dev->type = _channel_counts_type;
pvt->chancounts_dev->bus = mci->dev.bus;
@@ -1211,10 +1208,26 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)
edac_dbg(1, "creating %s\n", dev_name(pvt->chancounts_dev));

rc = device_add(pvt->chancounts_dev);
-   if (rc < 0)
-   return rc;
+   if (rc < 0) {
+   put_device(pvt->chancounts_dev);
+   goto fail_del_addrmatch_dev;
+   }
}
return 0;
+
+fail_del_addrmatch_dev:
+   device_del(pvt->addrmatch_dev);
+fail_free_addrmatch_dev:
+   put_device(pvt->addrmatch_dev);
+fail_remove_inject_enable:
+   device_create_file(>dev, _attr_inject_enable);
+fail_remove_inject_eccmask:
+   device_create_file(>dev, _attr_inject_eccmask);
+fail_remove_inject_type:
+   device_create_file(>dev, _attr_inject_type);
+fail_remove_inject_section:
+   device_create_file(>dev, _attr_inject_section);
+   return rc;
 }

 static void i7core_delete_sysfs_devices(struct mem_ctl_info *mci)
--
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] i7core_edac: release resources on error in i7core_create_sysfs_devices

[Junjie Mao]

Signed-off-by: Junjie Mao 
---
 drivers/edac/i7core_edac.c | 39 +++
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
index 9cd0b301f81b..98911150411b 100644
--- a/drivers/edac/i7core_edac.c
+++ b/drivers/edac/i7core_edac.c
@@ -1167,17 +1167,17 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)
return rc;
rc = device_create_file(>dev, _attr_inject_type);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_section;
rc = device_create_file(>dev, _attr_inject_eccmask);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_type;
rc = device_create_file(>dev, _attr_inject_enable);
if (rc < 0)
-   return rc;
+   goto fail_remove_inject_eccmask;
 
pvt->addrmatch_dev = kzalloc(sizeof(*pvt->addrmatch_dev), GFP_KERNEL);
if (!pvt->addrmatch_dev)
-   return rc;
+   goto fail_remove_inject_enable;
 
pvt->addrmatch_dev->type = _type;
pvt->addrmatch_dev->bus = mci->dev.bus;
@@ -1190,16 +1190,13 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)
 
rc = device_add(pvt->addrmatch_dev);
if (rc < 0)
-   return rc;
+   goto fail_free_addrmatch_dev;
 
if (!pvt->is_registered) {
pvt->chancounts_dev = kzalloc(sizeof(*pvt->chancounts_dev),
  GFP_KERNEL);
-   if (!pvt->chancounts_dev) {
-   put_device(pvt->addrmatch_dev);
-   device_del(pvt->addrmatch_dev);
-   return rc;
-   }
+   if (!pvt->chancounts_dev)
+   goto fail_del_addrmatch_dev;
 
pvt->chancounts_dev->type = _channel_counts_type;
pvt->chancounts_dev->bus = mci->dev.bus;
@@ -1211,10 +1208,28 @@ static int i7core_create_sysfs_devices(struct 
mem_ctl_info *mci)
edac_dbg(1, "creating %s\n", dev_name(pvt->chancounts_dev));
 
rc = device_add(pvt->chancounts_dev);
-   if (rc < 0)
-   return rc;
+   if (rc < 0) {
+   put_device(pvt->chancounts_dev);
+   kfree(pvt->chancounts_dev);
+   goto fail_del_addrmatch_dev;
+   }
}
return 0;
+
+fail_del_addrmatch_dev:
+   device_del(pvt->addrmatch_dev);
+fail_free_addrmatch_dev:
+   put_device(pvt->addrmatch_dev);
+   kfree(pvt->addrmatch_dev);
+fail_remove_inject_enable:
+   device_create_file(>dev, _attr_inject_enable);
+fail_remove_inject_eccmask:
+   device_create_file(>dev, _attr_inject_eccmask);
+fail_remove_inject_type:
+   device_create_file(>dev, _attr_inject_type);
+fail_remove_inject_section:
+   device_create_file(>dev, _attr_inject_section);
+   return rc;
 }
 
 static void i7core_delete_sysfs_devices(struct mem_ctl_info *mci)
-- 
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 v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()

[Chen Gang S]

On 2/3/15 05:20, Joe Perches wrote:
> On Tue, 2015-02-03 at 05:14 +0800, Chen Gang S wrote:
>> hci_test_bit() does not modify 2nd parameter, so it is better to let it
>> be constant, or may cause build warning. The related warning (with
>> allmodconfig under xtensa):
> []
>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> []
>> @@ -46,7 +46,7 @@ struct hci_pinfo {
>>  unsigned shortchannel;
>>  };
>>  
>> -static inline int hci_test_bit(int nr, void *addr)
>> +static inline int hci_test_bit(int nr, const void *addr)
>>  {
>>  return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
>>  }
> 
> It's probably better to use const __u32 * here too, but the
> real thing I wonder is whether or not there's an issue with
> one of the 2 uses of this function.
> 
> One of them passes a unsigned long *, the other a u32 *.
> 
> $ git grep -w hci_test_bit
> net/bluetooth/hci_sock.c:static inline int hci_test_bit(int nr, void *addr)
> net/bluetooth/hci_sock.c:   if (!hci_test_bit(flt_event, 
> >event_mask))
> net/bluetooth/hci_sock.c:!hci_test_bit(ocf & 
> HCI_FLT_OCF_BITS,
> net/bluetooth/hci_sock.c-  
> _sec_filter.ocf_mask[ogf])) &&
> 
> hci_sec_filter.ocf_mask is __u32
> but flt->event_mask is unsigned long.
> 
> Any possible issue here on 64-bit systems?
> 

For me, it can not cause issue on 64-bit systems. hci_test_bit() treats
'addr' as "__u32 *", and has to use the pointer to do something.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] change non-atomic bitops method

[Wang, Yalin]

> -Original Message-
> From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> Sent: Tuesday, February 03, 2015 9:18 AM
> To: Andrew Morton
> Cc: Wang, Yalin; 'a...@arndb.de'; 'linux-a...@vger.kernel.org'; 'linux-
> ker...@vger.kernel.org'; 'li...@arm.linux.org.uk'; 'linux-arm-
> ker...@lists.infradead.org'
> Subject: Re: [RFC] change non-atomic bitops method
> 
> On Mon, Feb 02, 2015 at 03:29:09PM -0800, Andrew Morton wrote:
> > On Mon, 2 Feb 2015 11:55:03 +0800 "Wang, Yalin"
>  wrote:
> >
> > > This patch change non-atomic bitops,
> > > add a if() condition to test it, before set/clear the bit.
> > > so that we don't need dirty the cache line, if this bit
> > > have been set or clear. On SMP system, dirty cache line will
> > > need invalidate other processors cache line, this will have
> > > some impact on SMP systems.
> > >
> > > --- a/include/asm-generic/bitops/non-atomic.h
> > > +++ b/include/asm-generic/bitops/non-atomic.h
> > > @@ -17,7 +17,9 @@ static inline void __set_bit(int nr, volatile
> unsigned long *addr)
> > >   unsigned long mask = BIT_MASK(nr);
> > >   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
> > >
> > > - *p  |= mask;
> > > + if ((*p & mask) == 0)
> > > + *p  |= mask;
> > > +
> > >  }
> >
> > hm, maybe.
> >
> > It will speed up set_bit on an already-set bit.  But it will slow down
> > set_bit on a not-set bit.  And the latter case is presumably much, much
> > more common.
> >
> > How do we know the patch is a net performance gain?
> 
> Let's try to measure. The micro benchmark:
> 
>   #include 
>   #include 
>   #include 
> 
>   #ifdef CACHE_HOT
>   #define SIZE (2UL << 20)
>   #define TIMES 1000
>   #else
>   #define SIZE (1UL << 30)
>   #define TIMES 1
>   #endif
> 
>   int main(int argc, char **argv)
>   {
>   struct timespec a, b, diff;
>   unsigned long i, *p, times = TIMES;
> 
>   p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
>   MAP_ANONYMOUS | MAP_PRIVATE | MAP_POPULATE, -1,
> 0);
> 
>   clock_gettime(CLOCK_MONOTONIC, );
>   while (times--) {
>   for (i = 0; i < SIZE/64/sizeof(*p); i++) {
>   #ifdef CHECK_BEFORE_SET
>   if (p[i] != times)
>   #endif
>   p[i] = times;
>   }
>   }
>   clock_gettime(CLOCK_MONOTONIC, );
> 
>   diff.tv_sec = b.tv_sec - a.tv_sec;
>   if (a.tv_nsec > b.tv_nsec) {
>   diff.tv_sec--;
>   diff.tv_nsec = 10 + b.tv_nsec - a.tv_nsec;
>   } else
>   diff.tv_nsec = b.tv_nsec - a.tv_nsec;
> 
>   printf("%lu.%09lu\n", diff.tv_sec, diff.tv_nsec);
>   return 0;
>   }
> 
> Results for 10 runs on my laptop -- i5-3427U (IvyBridge 1.8 Ghz, 2.8Ghz
> Turbo
> with 3MB LLC):
> 
>   Avg Stddev
> baseline  21.5351 0.5315
> -DCHECK_BEFORE_SET21.9834 0.0789
> -DCACHE_HOT   14.9987 0.0365
> -DCACHE_HOT -DCHECK_BEFORE_SET29.9010 0.0204
> 
> Difference between -DCACHE_HOT and -DCACHE_HOT -DCHECK_BEFORE_SET appears
> huge, but if you recalculate it to CPU cycles per inner loop @ 2.8 Ghz,
> it's 1.02530 and 2.04401 CPU cycles respectively.
> 
> Basically, the check is free on decent CPU.
> 
Awesome test, but you only test the one cpu which running this code,
Have not consider the other CPUs, whose cache line will be invalidate if
The cache is dirtied by writer CPU,
So another test should be running 2 thread on two different CPUs(bind to CPU),
One write , one read, to see the impact on the reader CPU.

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

[PATCH V3] acpi:apd:add AMD ACPI2Platform device support for x86 system.

[Ken Xue]

This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART found on AMD CZ and later chipsets. It
based on example intel LPSS. Now, it can support AMD I2C & UART.

Signed-off-by: Ken Xue 
---
 arch/x86/Kconfig|  11 +++
 drivers/acpi/Makefile   |   2 +-
 drivers/acpi/acpi_apd.c | 201 
 drivers/acpi/internal.h |   2 +
 drivers/acpi/scan.c |   1 +
 5 files changed, 216 insertions(+), 1 deletion(-)
 create mode 100644 drivers/acpi/acpi_apd.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0dc9d01..ddf8d42 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -496,6 +496,17 @@ config X86_INTEL_LPSS
  things like clock tree (common clock framework) and pincontrol
  which are needed by the LPSS peripheral drivers.
 
+config X86_AMD_PLATFORM_DEVICE
+   bool "AMD ACPI2Platform devices support"
+   depends on ACPI
+   select COMMON_CLK
+   select PINCTRL
+   ---help---
+ Select to interpret AMD specific ACPI device to platform device
+ such as I2C, UART found on AMD Carrizo and later chipsets. Selecting
+ this option enables things like clock tree (common clock framework)
+ and pinctrl.
+
 config IOSF_MBI
tristate "Intel SoC IOSF Sideband support for SoC platforms"
depends on PCI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index f74317c..0071141 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -40,7 +40,7 @@ acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
 acpi-y += ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-y += acpi_lpss.o
+acpi-y += acpi_lpss.o acpi_apd.o
 acpi-y += acpi_platform.o
 acpi-y += acpi_pnp.o
 acpi-y += int340x_thermal.o
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
new file mode 100644
index 000..b27bc1c
--- /dev/null
+++ b/drivers/acpi/acpi_apd.c
@@ -0,0 +1,201 @@
+/*
+ * AMD ACPI support for ACPI2platform device.
+ *
+ * Copyright (c) 2014,2015 AMD Corporation.
+ * Authors: Ken Xue 
+ * Wu, Jeff 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "internal.h"
+
+ACPI_MODULE_NAME("acpi_apd");
+struct apd_private_data;
+
+/**
+ * device flags of acpi_apd_dev_desc.
+ * ACPI_APD_SYSFS : add device attributes in sysfs
+ * ACPI_APD_PM : attach power domain to device
+ * ACPI_APD_PM_ON : power on device when attach power domain
+ */
+#define ACPI_APD_SYSFS BIT(0)
+#define ACPI_APD_PMBIT(1)
+#define ACPI_APD_PM_ON BIT(2)
+
+/**
+ * struct apd_device_desc - a descriptor for apd device
+ * @flags: device flags like ACPI_APD_SYSFS ACPI_APD_PM ACPI_APD_PM_ON
+ * @fixed_clk_rate: fixed rate input clock source for acpi device;
+ * 0 means no fixed rate input clock source
+ * @setup: a hook routine to set device resource during create platform device
+ *
+ * device description defined as acpi_device_id.driver_data
+ */
+struct apd_device_desc {
+   unsigned int flags;
+   unsigned int fixed_clk_rate;
+   int (*setup)(struct apd_private_data *pdata);
+};
+
+struct apd_private_data {
+   struct clk *clk;
+   struct acpi_device *adev;
+   const struct apd_device_desc *dev_desc;
+};
+
+#ifdef CONFIG_X86_AMD_PLATFORM_DEVICE
+#define APD_ADDR(desc) ((unsigned long))
+
+static int acpi_apd_setup(struct apd_private_data *pdata)
+{
+   const struct apd_device_desc *dev_desc = pdata->dev_desc;
+   struct clk *clk = ERR_PTR(-ENODEV);
+
+   if (dev_desc->fixed_clk_rate) {
+   clk = clk_register_fixed_rate(>adev->dev,
+   dev_name(>adev->dev),
+   NULL, CLK_IS_ROOT,
+   dev_desc->fixed_clk_rate);
+   clk_register_clkdev(clk, NULL, dev_name(>adev->dev));
+   pdata->clk = clk;
+   }
+
+   return 0;
+}
+
+static struct apd_device_desc cz_i2c_desc = {
+   .setup = acpi_apd_setup,
+   .fixed_clk_rate = 13300,
+};
+
+static struct apd_device_desc cz_uart_desc = {
+   .setup = acpi_apd_setup,
+   .fixed_clk_rate = 4800,
+};
+
+#else
+
+#define APD_ADDR(desc) (0UL)
+
+#endif /* CONFIG_X86_AMD_PLATFORM_DEVICE */
+
+static int acpi_apd_create_device(struct acpi_device *adev,
+  const struct acpi_device_id *id)
+{
+   const struct apd_device_desc *dev_desc;
+   struct apd_private_data *pdata;
+   struct platform_device *pdev;
+   int ret;
+
+  

Re: [Patch v2 1/6] soc: qcom: gsbi: Add support for ADM CRCI muxing

[Stephen Boyd]

On 01/30/15 13:48, Kumar Gala wrote:
> On Jan 30, 2015, at 3:37 PM, Stephen Boyd  wrote:
>
>> On 01/30/15 08:32, Kumar Gala wrote:
>>> On Jan 30, 2015, at 12:25 AM, Andy Gross  wrote:
>>>
 Required properties if child node exists:
 - #address-cells: Must be 1
 - #size-cells: Must be 1
 - ranges: Must be present

 +Note: Each GSBI should have an alias correctly numbered in "aliases" node.
 +
 Properties for children:

 A GSBI controller node can contain 0 or more child nodes representing 
 serial
 @@ -37,6 +41,10 @@ Example for APQ8064:

 #include 

 +  aliases {
 +  gsbi4 = <>;
 +  };
>>> You appear to be using the alias name to determine a index number for the 
>>> gsbi, if that is the case, than you should probably just add a cell-index 
>>> node to the gsbi’s for this purpose.
>>>
>> I thought cell-index was "deprecated" and referred more to things like
>> enumerating all the devices on a bus by assigning them a unique ID.
>> Aliases, on the other hand, allow us to enumerate a subset of devices
>> that share the same bus with other devices of different types. For
>> example, how would I know that a device is gsbi1 vs serial1 if they both
>> used cell-index and they both had the same parent node?
> I think the problem was cell-index was never well understood and abused.  For 
> the example you are giving you wouldn’t use cell-index because you are 
> talking about things that would have different compatibles.  For what it 
> appears we really are enumerating the GSBI hardware to match some programming 
> interface convention.  If that is the case than I think cell-index is proper.

Can you please explain when cell-index should be used and when aliases
should be used? I'm confused because I recall this message from Rob
Herring[1] where it's indicated that cell-index is pretty much
deprecated. I'm also interested to find out what cell means in
cell-index. Does it have any relation to *-cells properties?

[1] https://lkml.org/lkml/2012/11/10/102

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[for-next][PATCH 3/5] trace: Use 64-bit timekeeping

[Steven Rostedt]

From: Tina Ruchandani 

The ring_buffer_producer uses 'struct timeval' to measure
its start and end times. 'struct timeval' on 32-bit systems
will have its tv_sec value overflow in year 2038 and beyond.
This patch replaces struct timeval with 'ktime_t' which uses
64-bit representation for nanoseconds.

Link: http://lkml.kernel.org/r/20150128141611.GA2701@tinar

Suggested-by: Arnd Bergmann 
Suggested-by: Steven Rostedt 
Signed-off-by: Tina Ruchandani 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/ring_buffer_benchmark.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/kernel/trace/ring_buffer_benchmark.c 
b/kernel/trace/ring_buffer_benchmark.c
index 3f9e328c30b5..13d945c0d03f 100644
--- a/kernel/trace/ring_buffer_benchmark.c
+++ b/kernel/trace/ring_buffer_benchmark.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 struct rb_page {
@@ -17,7 +17,7 @@ struct rb_page {
 };
 
 /* run time and sleep time in seconds */
-#define RUN_TIME   10
+#define RUN_TIME   10ULL
 #define SLEEP_TIME 10
 
 /* number of events for writer to wake up the reader */
@@ -212,8 +212,7 @@ static void ring_buffer_consumer(void)
 
 static void ring_buffer_producer(void)
 {
-   struct timeval start_tv;
-   struct timeval end_tv;
+   ktime_t start_time, end_time, timeout;
unsigned long long time;
unsigned long long entries;
unsigned long long overruns;
@@ -227,7 +226,8 @@ static void ring_buffer_producer(void)
 * make the system stall)
 */
trace_printk("Starting ring buffer hammer\n");
-   do_gettimeofday(_tv);
+   start_time = ktime_get();
+   timeout = ktime_add_ns(start_time, RUN_TIME * NSEC_PER_SEC);
do {
struct ring_buffer_event *event;
int *entry;
@@ -244,7 +244,7 @@ static void ring_buffer_producer(void)
ring_buffer_unlock_commit(buffer, event);
}
}
-   do_gettimeofday(_tv);
+   end_time = ktime_get();
 
cnt++;
if (consumer && !(cnt % wakeup_interval))
@@ -264,7 +264,7 @@ static void ring_buffer_producer(void)
cond_resched();
 #endif
 
-   } while (end_tv.tv_sec < (start_tv.tv_sec + RUN_TIME) && !kill_test);
+   } while (ktime_before(end_time, timeout) && !kill_test);
trace_printk("End ring buffer hammer\n");
 
if (consumer) {
@@ -280,9 +280,7 @@ static void ring_buffer_producer(void)
wait_for_completion(_done);
}
 
-   time = end_tv.tv_sec - start_tv.tv_sec;
-   time *= USEC_PER_SEC;
-   time += (long long)((long)end_tv.tv_usec - (long)start_tv.tv_usec);
+   time = ktime_us_delta(end_time, start_time);
 
entries = ring_buffer_entries(buffer);
overruns = ring_buffer_overruns(buffer);
-- 
2.1.4


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

[for-next][PATCH 1/5] tracing: Remove newline from trace_printk warning banner

[Steven Rostedt]

From: Borislav Petkov 

Remove the output-confusing newline below:

[0.191328]
**
[0.191493] **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
[0.191586] **  **
...

Link: http://lkml.kernel.org/r/1422375440-31970-1-git-send-email...@alien8.de

Signed-off-by: Borislav Petkov 
[ added an extra '\n' by itself, to keep what it was suppose to do ]
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index acd27555dc5b..f82e53b0e5a7 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2036,7 +2036,8 @@ void trace_printk_init_buffers(void)
 
/* trace_printk() is for debug use only. Don't use it in production. */
 
-   
pr_warning("\n**\n");
+   pr_warning("\n");
+   
pr_warning("**\n");
pr_warning("**   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   
**\n");
pr_warning("**  
**\n");
pr_warning("** trace_printk() being used. Allocating extra memory.  
**\n");
-- 
2.1.4


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

[for-next][PATCH 2/5] tracing: Add array printing helper

[Steven Rostedt]

From: Dave Martin 

If a trace event contains an array, there is currently no standard
way to format this for text output.  Drivers are currently hacking
around this by a) local hacks that use the trace_seq functionailty
directly, or b) just not printing that information.  For fixed size
arrays, formatting of the elements can be open-coded, but this gets
cumbersome for arrays of non-trivial size.

These approaches result in non-standard content of the event format
description delivered to userspace, so userland tools needs to be
taught to understand and parse each array printing method
individually.

This patch implements a __print_array() helper that tracepoint
implementations can use instead of reinventing it.  A simple C-style
syntax is used to delimit the array and its elements {like,this}.

So that the helpers can be used with large static arrays as well as
dynamic arrays, they take a pointer and element count: they can be
used with __get_dynamic_array() for use with dynamic arrays.
Link: 
http://lkml.kernel.org/r/1422449335-8289-2-git-send-email-javi.mer...@arm.com

Cc: Ingo Molnar 
Signed-off-by: Dave Martin 
Signed-off-by: Javi Merino 
Signed-off-by: Steven Rostedt 
---
 include/linux/ftrace_event.h |  4 
 include/trace/ftrace.h   |  9 +
 kernel/trace/trace_output.c  | 44 
 3 files changed, 57 insertions(+)

diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index 0bebb5c348b8..5aa4a9269547 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -44,6 +44,10 @@ const char *ftrace_print_bitmask_seq(struct trace_seq *p, 
void *bitmask_ptr,
 const char *ftrace_print_hex_seq(struct trace_seq *p,
 const unsigned char *buf, int len);
 
+const char *ftrace_print_array_seq(struct trace_seq *p,
+  const void *buf, int buf_len,
+  size_t el_size);
+
 struct trace_iterator;
 struct trace_event;
 
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index 139b5067345b..304901fc5f34 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -263,6 +263,14 @@
 #undef __print_hex
 #define __print_hex(buf, buf_len) ftrace_print_hex_seq(p, buf, buf_len)
 
+#undef __print_array
+#define __print_array(array, count, el_size)   \
+   ({  \
+   BUILD_BUG_ON(el_size != 1 && el_size != 2 &&\
+el_size != 4 && el_size != 8); \
+   ftrace_print_array_seq(p, array, count, el_size);   \
+   })
+
 #undef DECLARE_EVENT_CLASS
 #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print) \
 static notrace enum print_line_t   \
@@ -674,6 +682,7 @@ static inline void ftrace_test_probe_##call(void)   
\
 #undef __get_dynamic_array_len
 #undef __get_str
 #undef __get_bitmask
+#undef __print_array
 
 #undef TP_printk
 #define TP_printk(fmt, args...) "\"" fmt "\", "  __stringify(args)
diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index b77b9a697619..692bf7184c8c 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -177,6 +177,50 @@ ftrace_print_hex_seq(struct trace_seq *p, const unsigned 
char *buf, int buf_len)
 }
 EXPORT_SYMBOL(ftrace_print_hex_seq);
 
+const char *
+ftrace_print_array_seq(struct trace_seq *p, const void *buf, int buf_len,
+  size_t el_size)
+{
+   const char *ret = trace_seq_buffer_ptr(p);
+   const char *prefix = "";
+   void *ptr = (void *)buf;
+
+   trace_seq_putc(p, '{');
+
+   while (ptr < buf + buf_len) {
+   switch (el_size) {
+   case 1:
+   trace_seq_printf(p, "%s0x%x", prefix,
+*(u8 *)ptr);
+   break;
+   case 2:
+   trace_seq_printf(p, "%s0x%x", prefix,
+*(u16 *)ptr);
+   break;
+   case 4:
+   trace_seq_printf(p, "%s0x%x", prefix,
+*(u32 *)ptr);
+   break;
+   case 8:
+   trace_seq_printf(p, "%s0x%llx", prefix,
+*(u64 *)ptr);
+   break;
+   default:
+   trace_seq_printf(p, "BAD SIZE:%zu 0x%x", el_size,
+*(u8 *)ptr);
+   el_size = 1;
+   }
+   prefix = ",";
+   ptr += el_size;
+   }
+
+   trace_seq_putc(p, '}');
+   trace_seq_putc(p, 0);
+
+   return ret;
+}
+EXPORT_SYMBOL(ftrace_print_array_seq);
+
 int ftrace_raw_output_prep(struct trace_iterator *iter,

[for-next][PATCH 0/5] tracing: Updates for 3.20

[Steven Rostedt]

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next

Head SHA1: 7eeafbcab47fe9860e5106286db83d60e3f35644


Borislav Petkov (1):
  tracing: Remove newline from trace_printk warning banner

Dave Martin (1):
  tracing: Add array printing helper

Steven Rostedt (Red Hat) (2):
  tracing: Make tracing_init_dentry_tr() static
  tracing: Separate out initializing top level dir from instances

Tina Ruchandani (1):
  trace: Use 64-bit timekeeping


 include/linux/ftrace_event.h |  4 +++
 include/trace/ftrace.h   |  9 ++
 kernel/trace/ring_buffer_benchmark.c | 18 ++--
 kernel/trace/trace.c | 54 +---
 kernel/trace/trace.h |  1 -
 kernel/trace/trace_output.c  | 44 +
 6 files changed, 97 insertions(+), 33 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 v3 2/4] pinctrl: Broadcom Cygnus pinctrl device tree binding

[Ray Jui]

Device tree binding documentation for Broadcom Cygnus IOMUX driver

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../bindings/pinctrl/brcm,cygnus-pinmux.txt|  159 
 1 file changed, 159 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt 
b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt
new file mode 100644
index 000..1082b8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt
@@ -0,0 +1,159 @@
+Broadcom Cygnus IOMUX Controller
+
+The Cygnus IOMUX controller supports group based mux configuration. In
+addition, certain pins can be muxed to GPIO function individually.
+
+Required properties:
+
+- compatible:
+Must be "brcm,cygnus-pinmux"
+
+- reg:
+Define the base and range of the I/O address space that contains the Cygnus
+IOMUX registers
+
+Required properties in child nodes:
+
+- function:
+The mux function to select
+
+- groups:
+The list of groups to select with a given function
+
+Each child node represents a configuration. Client devices reference the child
+node to enable a mux configuration
+
+For more details, refer to
+Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+For example:
+
+   pinmux: pinmux@0x0301d0c8 {
+   compatible = "brcm,cygnus-pinmux";
+   reg = <0x0301d0c8 0x1b0>;
+
+   i2s_0: i2s_0 {
+   function = "i2s0";
+   groups = "i2s0_0_grp", "i2s0_1_grp";
+   };
+
+   i2s_1: i2s_1 {
+   function = "i2s1";
+   groups = "i2s1_0_grp", "i2s1_1_grp";
+   };
+
+   i2s_2: i2s_2 {
+   function = "i2s2";
+   groups = "i2s2_0_grp", "i2s2_1_grp", "i2s2_2_grp",
+"i2s2_3_grp", "i2s2_4_grp";
+   };
+
+   spi_0: spi_0 {
+   function = "spi0";
+   groups = "spi0_grp";
+   };
+   }
+
+   spi0@18028000 {
+   compatible = "arm,pl022", "arm,primecell";
+   reg = <0x18028000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   interrupts = ;
+   pinctrl-0 = <_0>;
+   clocks = <_clk>;
+   clock-names = "apb_pclk";
+   };
+
+List of supported functions and groups in Cygnus:
+
+"gpio": N/A (to be removed for A0)
+
+"i2s0": "i2s0_0_grp", "i2s0_1_grp"
+
+"i2s1": "i2s1_0_grp", "i2s1_1_grp"
+
+"i2s2": "i2s2_0_grp", "i2s2_1_grp", "i2s2_2_grp", "i2s2_3_grp", "i2s2_4_grp"
+
+"spdif": "spdif_grp"
+
+"pwm0": "pwm0_grp"
+
+"pwm1": "pwm1_grp"
+
+"pwm2": "pwm2_grp"
+
+"pwm3": "pwm3_grp"
+
+"pwm4": "pwm4_grp"
+
+"pwm5": "pwm5_grp"
+
+"key": "key0_grp", "key1_grp", "key2_grp", "key3_grp", "key4_grp", "key5_grp",
+"key6_grp", "key7_grp", "key8_grp", "key9_grp", "key10_grp", "key11_grp",
+"key12_grp", "key13_grp", "key14_grp", "key15_grp"
+
+"audio_dte": "audio_dte0_grp", "audio_dte1_grp", "audio_dte2_grp", 
"audio_dte3_grp"
+
+"smart_card0": "smart_card0_grp", "smart_card0_fcb_grp"
+
+"smart_card1": "smart_card1_grp", "smart_card1_fcb_grp"
+
+"spi0": "spi0_grp"
+
+"spi1": "spi1_grp"
+
+"spi2": "spi2_grp"
+
+"spi3": "spi3_grp"
+
+"spi4": "spi4_0_grp", "spi4_1_grp"
+
+"spi5": "spi5_grp"
+
+"sw_led0": "sw_led0_0_grp", "sw_led0_1_grp"
+
+"sw_led1": "sw_led1_grp"
+
+"sw_led2": "sw_led2_0_grp", "sw_led2_1_grp"
+
+"d1w": "d1w_grp"
+
+"lcd": "lcd_grp"
+
+"sram": "sram_0_grp", "sram_1_grp"
+
+"uart0": "uart0_grp"
+
+"uart1": "uart1_grp", "uart1_dte_grp"
+
+"uart2": "uart2_grp"
+
+"uart3": "uart3_grp"
+
+"uart4": "uart4_grp"
+
+"qspi": "qspi_0_grp", "qspi_1_grp"
+
+"nand": "nand_grp"
+
+"sdio0": "sdio0_grp", "sdio0_cd_grp", "sdio0_mmc_grp"
+
+"sdio1": "sdio1_data_0_grp", "sdio1_data_1_grp", "sdio1_cd_grp",
+"sdio1_led_grp", "sdio1_mmc_grp"
+
+"can0": "can0_grp"
+
+"can1": "can1_grp"
+
+"cam": "cam_led_grp", "cam_0_grp", "cam_1_grp"
+
+"bsc1": "bsc1_grp"
+
+"pcie_clkreq": "pcie_clkreq_grp"
+
+"usb0_oc": "usb0_oc_grp"
+
+"usb1_oc": "usb1_oc_grp"
+
+"usb2_oc": "usb2_oc_grp"
-- 
1.7.9.5

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

[PATCH v3 3/4] pinctrl: cygnus: add initial IOMUX driver support

[Ray Jui]

This adds the initial driver support for the Broadcom Cygnus IOMUX
controller. The Cygnus IOMUX controller supports group based mux
configuration but allows certain pins to be muxed to GPIO individually

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/pinctrl/bcm/Kconfig  |   13 +
 drivers/pinctrl/bcm/Makefile |5 +-
 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c | 1087 ++
 3 files changed, 1103 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c

diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index bc6d048..eb13201 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -19,3 +19,16 @@ config PINCTRL_BCM2835
bool
select PINMUX
select PINCONF
+
+config PINCTRL_CYGNUS_MUX
+   bool "Broadcom Cygnus IOMUX driver"
+   depends on (ARCH_BCM_CYGNUS || COMPILE_TEST)
+   select PINMUX
+   select GENERIC_PINCONF
+   default ARCH_BCM_CYGNUS
+   help
+ Say yes here to enable the Broadcom Cygnus IOMUX driver.
+
+ The Broadcom Cygnus IOMUX driver supports group based IOMUX
+ configuration, with the exception that certain individual pins
+ can be overrided to GPIO function
diff --git a/drivers/pinctrl/bcm/Makefile b/drivers/pinctrl/bcm/Makefile
index 7ba80a3..bb6beb6 100644
--- a/drivers/pinctrl/bcm/Makefile
+++ b/drivers/pinctrl/bcm/Makefile
@@ -1,4 +1,5 @@
 # Broadcom pinctrl support
 
-obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
-obj-$(CONFIG_PINCTRL_BCM2835)  += pinctrl-bcm2835.o
+obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
+obj-$(CONFIG_PINCTRL_BCM2835)  += pinctrl-bcm2835.o
+obj-$(CONFIG_PINCTRL_CYGNUS_MUX)   += pinctrl-cygnus-mux.o
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c 
b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
new file mode 100644
index 000..33565b4
--- /dev/null
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
@@ -0,0 +1,1087 @@
+/* Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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.
+ *
+ * This file contains the Cygnus IOMUX driver that supports group based PINMUX
+ * configuration. Although PINMUX configuration is mainly group based, the
+ * Cygnus IOMUX controller allows certain pins to be individually muxed to GPIO
+ * function, and therefore be controlled by the Cygnus ASIU GPIO controller
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../core.h"
+#include "../pinctrl-utils.h"
+
+#define CYGNUS_NUM_IOMUX_REGS 8
+#define CYGNUS_NUM_MUX_PER_REG8
+#define CYGNUS_NUM_IOMUX  (CYGNUS_NUM_IOMUX_REGS * \
+  CYGNUS_NUM_MUX_PER_REG)
+
+/*
+ * Cygnus IOMUX register description
+ *
+ * @offset: register offset for mux configuration of a group
+ * @shift: bit shift for mux configuration of a group
+ * @alt: alternate function to set to
+ */
+struct cygnus_mux {
+   unsigned int offset;
+   unsigned int shift;
+   unsigned int alt;
+};
+
+/*
+ * Keep track of Cygnus IOMUX configuration and prevent double configuration
+ *
+ * @cygnus_mux: Cygnus IOMUX register description
+ * @is_configured: flag to indicate whether a mux setting has already been
+ * configured
+ */
+struct cygnus_mux_log {
+   struct cygnus_mux mux;
+   bool is_configured;
+};
+
+/*
+ * Group based IOMUX configuration
+ *
+ * @name: name of the group
+ * @pins: array of pins used by this group
+ * @num_pins: total number of pins used by this group
+ * @mux: Cygnus group based IOMUX configuration
+ */
+struct cygnus_pin_group {
+   const char *name;
+   const unsigned *pins;
+   const unsigned num_pins;
+   const struct cygnus_mux mux;
+};
+
+/*
+ * Cygnus mux function and supported pin groups
+ *
+ * @name: name of the function
+ * @groups: array of groups that can be supported by this function
+ * @num_groups: total number of groups that can be supported by this function
+ */
+struct cygnus_pin_function {
+   const char *name;
+   const char * const *groups;
+   const unsigned num_groups;
+};
+
+/*
+ * Cygnus IOMUX pinctrl core
+ *
+ * @pctl: pointer to pinctrl_dev
+ * @dev: pointer to device
+ * @base0: first I/O register base of the Cygnus IOMUX controller
+ * @base1: second I/O register base
+ * @groups: pointer to array of groups
+ * @num_groups: total number of groups
+ * @functions: pointer to array of functions
+ * @num_functions: total number of