Re: [PATCH] clk: prevent __of_clk_get_hw_from_provider() from returning NULL

[Masahiro Yamada]

Hi.

(+CC Russell, perhaps he may have some comments on this topic.)

2016-08-11 8:23 GMT+09:00 Stephen Boyd :
> On 08/10, Masahiro Yamada wrote:
>> 2016-08-05 5:57 GMT+09:00 Stephen Boyd :
>> > On 07/19, Masahiro Yamada wrote:
>> >> The .get(_hw) callback of an OF clock provider can return a NULL
>> >> pointer in some cases.
>> >>
>> >> For example, of_clk_src_onecell_get() returns NULL for index 1 of a
>> >> sparse array of clocks like follows:
>> >>
>> >>   clk_num == 3
>> >>   idx 0: UART clk
>> >>   idx 1: NULL (no clk is allocated)
>> >>   idx 2: I2C clk
>> >>
>> >> In such cases, clk_get() successfully returns NULL.
>> >>
>> >> A problem is that most drivers only check IS_ERR(), like follows:
>> >>
>> >>   clk = devm_clk_get(dev, NULL);
>> >>   if (IS_ERR(clk))
>> >>   return PTR_ERR(clk);
>> >>
>> >> It carries on moving forward and will probably be hit by a different
>> >> error check with a different error message.
>> >
>> > NULL is a valid clk pointer, so we can't really do anything here
>> > besides rely on driver authors to do the right thing.
>>
>>
>> I still do not understand this.
>>
>>
>> I think clk_get() should return > 0 pointer on success,
>> error-pointer on failure.
>
> Russell King has repeatedly stated that NULL is a valid return
> value from clk_get(). I'm sure we can find numerous such
> statements on the arm mailing list.
>
>>
>> I have no idea when NULL is useful as a return value of clk_get().
>>
>
> Perhaps the provider wants to avoid allocating anything for some
> clk id and have the clk consumer API do nothing in this case?

Hmm.

I was thinking in which case we want to do this.
Perhaps, when we add the "clocks" property to DT first,
but clock driver is not implemented yet.  So clk provider
just want to return NULL to make the consumer to skip the clk set-up ??


Another possibility:
I noticed we have a stub in include/linux/clk.h,
which just returns NULL if CONFIG_HAVE_CLK is not defined.



> Consumers can be unaware of this fact by having the provider
> return NULL so things like clk_prepare/enable become nops. Of
> course, we can't make things like clk_get_rate() useful in this
> case, but at least we can have on/off simplified.

At least, this seems useful for architectures without CONFIG_HAVE_CLK.


Another case where it might be useful is,
if "clocks" property is missing in DT,
clk_get() can return NULL to make the clock optional.
Then, clk consumer can skip clk_prepare_enable() and continue probing.

But, actually, clk_get returns ERR_PTR(-ENOENT) if "clocks" property
is missing.


-- 
Best Regards
Masahiro Yamada

Re: of_clk_add_(hw_)providers multipule times for one node?

[Masahiro Yamada]

2016-08-11 8:08 GMT+09:00 Stephen Boyd :
> On 08/10, Masahiro Yamada wrote:
>> Hi Stephen,
>>
>>
>>
>> 2016-08-09 8:37 GMT+09:00 Stephen Boyd :
>> > On 08/08, Masahiro Yamada wrote:
>> >> Hi Stephen,
>> >>
>> >>
>> >> 2016-08-05 6:25 GMT+09:00 Stephen Boyd :
>> >
>> >>
>> >> of_clk_add_provider() calls of_clk_del_provider()
>> >> in its failure path.
>> >>
>> >> Notice of_clk_del_provider() unregister
>> >> all the providers associated with the device node.
>> >
>> > Where is that? I see a break statement in the while loop after
>> > the first matching np is found.
>>
>> Ah, I missed the "break".
>>
>> So, this works *almost* well.
>>
>> I mean *almost* because the of_clk_mutex is released
>> between of_clk_add_hw_provider() and of_clk_del_provider().
>>
>> What if two providers are added concurrently.
>> I know it never happens in use-cases we assume, though.
>
> Agreed, that would be bad. We can definitely do better in that
> case and properly delete the provider that we have already
> registered without calling of_clk_del_provider() though. We have
> everything in the local scope at the time.
>
>>
>>
>> >>
>> >> Some platform drivers call of_clk_del_provider() in a .remove callback,
>> >> so the same problem could happen.
>> >>
>> >> Why does of_clk_del_provider() take (struct device_node *np) ?
>> >> Shouldn't it take (struct of_clk_provider *cp)?
>> >>
>> >
>> > Not sure. Probably someone thought they could hide the structure
>> > from consumers and just return success or failure.
>>
>> consumers?   or did you mean providers?
>> I think consumers have no chance to call of_clk_del_provider().
>
> Sorry, bad choice of words. I meant users of this
> of_clk_add*_provider() API.
>
>>
>>
>> > The best we can do is have the framework only return probe defer
>> > if there isn't a provider registered. Once a provider is
>> > registered, it needs to do the right thing and return the
>> > appropriate error (invalid or probe defer for example) at the
>> > right time.
>>
>> Agreed.
>
> Ok. I think I will merge my patch then to restore previous
> behavior.
>
>>
>> Lastly, we have two solutions so far.  Which do you think is better?
>>
>> One solution is, as others suggested,
>> CLK_OF_DECLARE() can allocate a bigger array than it needs,
>> so that blank entries can be filled by a platfrom_driver later.
>>
>>
>> The other way is,
>> CLK_OF_DECLARE() and a platfrom_driver
>> allocate separate of_clk_provider for each of them.
>>
>
> I believe we have precedence for the former case, so there's some
> momentum around that approach. It doesn't make me feel great
> though because we have published the provider before all clks are
> registered, and then we go back and modify the array in place
> while consumers could potentially be using it. I suppose we're
> saved because cpus access the pointer in the array and only see
> the whole pointer and not half of the old one and half of the new
> one?


I am not sure.

But, maybe just filling the blank entries of the array seems safe.
In this case, filling should be done at the end of the probe callback.
Otherwise, devm_clk_hw_register() will free the clk_hw when the driver
is detached.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH] time,virt: resync steal time when guest & host lose sync

[Wanpeng Li]

2016-08-12 10:44 GMT+08:00 Rik van Riel :
> On Thu, 2016-08-11 at 18:11 +0800, Wanpeng Li wrote:
>> 2016-08-11 0:52 GMT+08:00 Rik van Riel :
>> > On Wed, 10 Aug 2016 07:39:08 +0800
>> > Wanpeng Li  wrote:
>> >
>> > > The regression is caused by your commit "sched,time: Count
>> > > actually
>> > > elapsed irq & softirq time".
>> >
>> > Wanpeng, does this patch fix your issue?
>>
>> I test this against kvm guest (nohz_full, four vCPUs running on one
>> pCPU, four cpuhog processes running on four vCPUs).
>> before this fix patch:
>> vCPU0's st is 100%, other vCPUs' st are ~75%.
>> after this fix patch:
>> all vCPUs' st are ~85%.
>> However, w/o commit "sched,time: Count actually elapsed irq & softirq
>> time", all vCPUs' st are ~75%.
>
> If you pass ULONG_MAX as the maxtime argument to
> steal_account_process_time(), does the steal time
> get accounted properly at 75%?

Yes.

>
> If that is the case, I have a hypothesis:
> 1) The guest is running so much slower when sharing
>a CPU 4 ways, that it is accounting only ~90% of
>wall clock time as CPU time, due to missing the
>other 10% or so of clock ticks.
> 2) account_process_tick() only ever processes one tick
>at a time - if it gets called only 90x a second for
>a 100Hz guest, but all the steal time recorded by
>the host is fully accounted (ULONG_MAX limit), then
>that could make up for lost/skipped timer ticks.
> 3) not accounting "extra" steal time (beyond the amount
>of time accounted by account_process_tick) would reduce
>the total amount of time that gets accounted if there
>are missed ticks, taking time away from user/system/etc
>
> Does the above make sense?
>
> Am I overlooking some mechanism through which lost/skipped
> ticks are made up for in the kernel?  I looked through the
> code in kernel/time/ briefly, but did not spot it...
>
> --
>
> All Rights Reversed.

Re: WARNING: CPU: 0 PID: 1271 at drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8

[John Stultz]

On Thu, Aug 4, 2016 at 9:52 PM, John Stultz  wrote:
> Hey Ulf,
>   Since moving my HiKey branch to pre-v4.8-rc1 (linus's HEAD), I've
> been seeing the following warning occasionally. Usually after seeing
> it, the system will refuse to reboot (system does the "Emergency
> remount complete" but then just sits there, and if I ctrl-c I can use
> the shell fine but many commands will get me stuck).
>
> Anyway, if you have any ideas...
>
> thanks
> -john
>
> [   24.154245] [ cut here ]
> [   24.158903] WARNING: CPU: 2 PID: 1273 at
> drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8
> [   24.167605]
> [   24.169104] CPU: 2 PID: 1273 Comm: mmcqd/0 Not tainted
> 4.7.0-11945-gb30f1d6-dirty #706
> [   24.177024] Hardware name: HiKey Development Board (DT)
> [   24.182253] task: ffc0793d8c80 task.stack: ffc078c48000
> [   24.188178] PC is at mmc_release_host+0xa0/0xa8
> [   24.192725] LR is at mmc_put_card+0x18/0x3c
> [   24.196917] pc : [] lr : []
> pstate: 8145
> [   24.204317] sp : ffc078c4bd20
> [   24.207636] x29: ffc078c4bd20 x28: 
> [   24.212975] x27:  x26: ffc077903420
> [   24.216220] x25: ffc078788028 x24: ffc0787e8800
> [   24.216232] x23: ffc078788000 x22: 
> [   24.216243] x21:  x20: ffc078788018
> [   24.216254] x19: ffc0787e8800 x18: 
> [   24.216265] x17:  x16: 
> [   24.216276] x15:  x14: ffc078789430
> [   24.216288] x13: 002f x12: b853
> [   24.216299] x11: ffc077903420 x10: 0860
> [   24.216310] x9 : ffc078c48000 x8 : ffc0793d9540
> [   24.216322] x7 : 00d3f8c7 x6 : 2bd0
> [   24.216333] x5 : 021458fa x4 : 00ff
> [   24.216344] x3 : d055 x2 : ffc078c4bd5c
> [   24.216355] x1 :  x0 : 
> [   24.216366]
> [   24.216372] ---[ end trace 74dade4766b71d8d ]---
> [   24.216377] Call trace:
> [   24.216386] Exception stack(0xffc078c4bb50 to 0xffc078c4bc80)
> [   24.216394] bb40:
> ffc0787e8800 0080
> [   24.216403] bb60: ffc078c4bd20 ff80086c2550
> ff8008ca6000 ffc0784fb200
> [   24.216411] bb80: ffc07bf4b7e8 0008
> ffc0793d8d00 ff8008c82780
> [   24.216420] bba0: ffc078c4bbe0 ff800843576c
> ffc078c4bbf0 ff800843576c
> [   24.216429] bbc0: ffc078c4bcc0 ffc078c4bc78
> ffc078c4bc10 ff800843576c
> [   24.216437] bbe0: ffc078c4bce0 ffc078c4bc98
>  
> [   24.216445] bc00: ffc078c4bd5c d055
> 00ff 021458fa
> [   24.216452] bc20: 2bd0 00d3f8c7
> ffc0793d9540 ffc078c48000
> [   24.216460] bc40: 0860 ffc077903420
> b853 002f
> [   24.216467] bc60: ffc078789430 
>  
> [   24.216479] [] mmc_release_host+0xa0/0xa8
> [   24.216486] [] mmc_put_card+0x18/0x3c
> [   24.216497] [] mmc_blk_issue_rq+0x11c/0x4a4
> [   24.216506] [] mmc_queue_thread+0x98/0x158
> [   24.216517] [] kthread+0xd0/0xe4
> [   24.216527] [] ret_from_fork+0x10/0x40


Hey Ulf,
  I *think* I've narrowed this down to
6024e16654c1e1a2475e848d735963d05a12dba9 ("mmc: dw_mmc: set to
MMC_CAP_ERASE by default"). Its fairly sporadic so I may be seeing
this as a false positive, but after reverting that patch I've
seemingly stopped seeing the issue.

Anyway, I'll do some further testing tomorrow w/ that removed. Usually
I see the issue 1-2 times an hour, so if I go the day w/o a problem
I'll let you know.

Zhangfei/Guodong: Any ideas as to why ERASE might cause trouble on HiKey?

thanks
-john

[PATCH] smartreflex: Neaten logging

[Joe Perches]

Use a more common logging style.

Miscellanea:

o Use pr_warn
o Coalesce formats adding missing spaces
o Argument alignment
o Remove unnecessary OOM messages as k.alloc does stack dumps

Signed-off-by: Joe Perches 
---
 drivers/power/avs/smartreflex.c | 115 +++-
 1 file changed, 54 insertions(+), 61 deletions(-)

diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index db9973b..fa0f19b 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -136,7 +136,7 @@ static void sr_set_clk_length(struct omap_sr *sr)
 
if (IS_ERR(fck)) {
dev_err(&sr->pdev->dev, "%s: unable to get fck for device %s\n",
-   __func__, dev_name(&sr->pdev->dev));
+   __func__, dev_name(&sr->pdev->dev));
return;
}
 
@@ -170,8 +170,8 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
 {
if (!sr_class || !(sr_class->enable) || !(sr_class->configure)) {
dev_warn(&sr->pdev->dev,
-   "%s: smartreflex class driver not registered\n",
-   __func__);
+"%s: smartreflex class driver not registered\n",
+__func__);
return;
}
 
@@ -183,8 +183,8 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
 {
if (!sr_class || !(sr_class->disable)) {
dev_warn(&sr->pdev->dev,
-   "%s: smartreflex class driver not registered\n",
-   __func__);
+"%s: smartreflex class driver not registered\n",
+__func__);
return;
}
 
@@ -225,9 +225,8 @@ static int sr_late_init(struct omap_sr *sr_info)
 
 error:
list_del(&sr_info->node);
-   dev_err(&sr_info->pdev->dev, "%s: ERROR in registering"
-   "interrupt handler. Smartreflex will"
-   "not function as desired\n", __func__);
+   dev_err(&sr_info->pdev->dev, "%s: ERROR in registering interrupt 
handler. Smartreflex will not function as desired\n",
+   __func__);
 
return ret;
 }
@@ -263,7 +262,7 @@ static void sr_v1_disable(struct omap_sr *sr)
 
if (timeout >= SR_DISABLE_TIMEOUT)
dev_warn(&sr->pdev->dev, "%s: Smartreflex disable timedout\n",
-   __func__);
+__func__);
 
/* Disable MCUDisableAcknowledge interrupt & clear pending interrupt */
sr_modify_reg(sr, ERRCONFIG_V1, ERRCONFIG_MCUDISACKINTEN,
@@ -308,7 +307,7 @@ static void sr_v2_disable(struct omap_sr *sr)
 
if (timeout >= SR_DISABLE_TIMEOUT)
dev_warn(&sr->pdev->dev, "%s: Smartreflex disable timedout\n",
-   __func__);
+__func__);
 
/* Disable MCUDisableAcknowledge interrupt & clear pending interrupt */
sr_write_reg(sr, IRQENABLE_CLR, IRQENABLE_MCUDISABLEACKINT);
@@ -322,7 +321,7 @@ static struct omap_sr_nvalue_table *sr_retrieve_nvalue_row(
 
if (!sr->nvalue_table) {
dev_warn(&sr->pdev->dev, "%s: Missing ntarget value table\n",
-   __func__);
+__func__);
return NULL;
}
 
@@ -356,8 +355,8 @@ int sr_configure_errgen(struct omap_sr *sr)
u8 senp_shift, senn_shift;
 
if (!sr) {
-   pr_warn("%s: NULL omap_sr from %pF\n", __func__,
-   (void *)_RET_IP_);
+   pr_warn("%s: NULL omap_sr from %pF\n",
+   __func__, (void *)_RET_IP_);
return -EINVAL;
}
 
@@ -387,8 +386,8 @@ int sr_configure_errgen(struct omap_sr *sr)
vpboundint_st = ERRCONFIG_VPBOUNDINTST_V2;
break;
default:
-   dev_err(&sr->pdev->dev, "%s: Trying to Configure smartreflex"
-   "module without specifying the ip\n", __func__);
+   dev_err(&sr->pdev->dev, "%s: Trying to Configure smartreflex 
module without specifying the ip\n",
+   __func__);
return -EINVAL;
}
 
@@ -423,8 +422,8 @@ int sr_disable_errgen(struct omap_sr *sr)
u32 vpboundint_en, vpboundint_st;
 
if (!sr) {
-   pr_warn("%s: NULL omap_sr from %pF\n", __func__,
-   (void *)_RET_IP_);
+   pr_warn("%s: NULL omap_sr from %pF\n",
+   __func__, (void *)_RET_IP_);
return -EINVAL;
}
 
@@ -440,8 +439,8 @@ int sr_disable_errgen(struct omap_sr *sr)
vpboundint_st = ERRCONFIG_VPBOUNDINTST_V2;
break;
default:
-   dev_err(&sr->pdev->dev, "%s: Trying to Configure smartreflex"
-   "module without specifying the ip\n", __func__);
+   dev_err(&sr->pdev->dev, "%s: Trying to Configure smartrefle

Re: [PATCH 1/4] befs: check allocation_group number before use

[Salah Triki]

On Thu, Aug 11, 2016 at 11:56:16AM +0100, Luis de Bethencourt wrote:
> On 10/08/16 23:12, Salah Triki wrote:
> > Check that the allocation group number is not greater or equal to the
> > number of allocations group in the file system and return BEF_ERR in the
> > case of error.
> > 
> > Signed-off-by: Salah Triki 
> > ---
> >  fs/befs/befs.h | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/fs/befs/befs.h b/fs/befs/befs.h
> > index 55f3ea2..6daf4c4 100644
> > --- a/fs/befs/befs.h
> > +++ b/fs/befs/befs.h
> > @@ -121,6 +121,11 @@ BEFS_I(const struct inode *inode)
> >  static inline befs_blocknr_t
> >  iaddr2blockno(struct super_block *sb, const befs_inode_addr *iaddr)
> >  {
> > +   if (iaddr->allocation_group >= BEFS_SB(sb)->num_ags) {
> > +   befs_error(sb, "BEFS: Invalid allocation group %u, max is %u",
> > +  iaddr->allocation_group, BEFS_SB(sb)->num_ags);
> > +   return BEFS_ERR;
> > +   }
> > return ((iaddr->allocation_group << BEFS_SB(sb)->ag_shift) +
> > iaddr->start);
> >  }
> > 
> 
> Hi Salah,
> 
> To understand why would we check for this. When can this error happen? I mean,
> when can iaddr2blockno() be called with an out of bounds allocation group?
> 
> Thanks,
> Luis

Hi Luis,

allocation group number is set to blockno >> BEFS_SB(sb)->ag_shift by 
blockno2iaddr(), so if ag_shift is not valid, an out of bound may occur. 
By now, thanx to your question ;), I think it's better to check the validity 
of ag_shift when the superblock is loaded.

Nack.

Thanx for the question :)
Salah 

Re: [PATCH] befs: fix typos in btree.c

[Salah Triki]

On Thu, Aug 11, 2016 at 10:15:16PM +0100, Luis de Bethencourt wrote:
> Fixing typos in kernel-doc function descriptions in fs/befs/btree.c.
> 
> Signed-off-by: Luis de Bethencourt 
> ---
> 
> Hi,
> 
> Noticed the typo of "actuall" below and decided to fix all typos in the
> btree.c file.
> 
> Thanks,
> Luis
> 
>  fs/befs/btree.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/befs/btree.c b/fs/befs/btree.c
> index 54a1f95..866d070 100644
> --- a/fs/befs/btree.c
> +++ b/fs/befs/btree.c
> @@ -242,7 +242,7 @@ befs_bt_read_node(struct super_block *sb, const 
> befs_data_stream *ds,
>   *   Read the superblock and rootnode of the b+tree.
>   *   Drill down through the interior nodes using befs_find_key().
>   *   Once at the correct leaf node, use befs_find_key() again to get the
> - *   actuall value stored with the key.
> + *   actual value stored with the key.
>   */
>  int
>  befs_btree_find(struct super_block *sb, const befs_data_stream *ds,
> @@ -397,7 +397,7 @@ befs_find_key(struct super_block *sb, struct 
> befs_btree_node *node,
>   * @keysize: Length of the returned key
>   * @value: Value stored with the returned key
>   *
> - * Heres how it works: Key_no is the index of the key/value pair to 
> + * Here's how it works: Key_no is the index of the key/value pair to
>   * return in keybuf/value.
>   * Bufsize is the size of keybuf (BEFS_NAME_LEN+1 is a good size). Keysize 
> is 
>   * the number of characters in the key (just a convenience).
> @@ -533,7 +533,6 @@ befs_btree_read(struct super_block *sb, const 
> befs_data_stream *ds,
>   * @node_off: Pointer to offset of current node within datastream. Modified
>   *   by the function.
>   *
> - *
>   * Helper function for btree traverse. Moves the current position to the 
>   * start of the first leaf node.
>   *
> @@ -707,7 +706,7 @@ befs_bt_get_key(struct super_block *sb, struct 
> befs_btree_node *node,
>   *
>   * Returns 0 if @key1 and @key2 are equal.
>   * Returns >0 if @key1 is greater.
> - * Returns <0 if @key2 is greater..
> + * Returns <0 if @key2 is greater.
>   */
>  static int
>  befs_compare_strings(const void *key1, int keylen1,
> -- 
> 2.5.1
> 

Signed-off-by: Salah Triki 

Thanx,
Salah

[Patch v2] x86, ACPI: Fix the wrong assignment when Handle apic/x2apic entries

[Baoquan He]

By pure accident the bug makes no functional difference, because the only
expression where we are using these values is (!count && !x2count), in which
the variables are interchangeable, but it makes sense to fix the bug
nevertheless.

Signed-off-by: Baoquan He 
[Ingo rewrote changelog]
---
v1-v2:
  -Just update change log.

 arch/x86/kernel/acpi/boot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 90d84c3..2b25d3f 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1031,8 +1031,8 @@ static int __init acpi_parse_madt_lapic_entries(void)
return ret;
}
 
-   x2count = madt_proc[0].count;
-   count = madt_proc[1].count;
+   count = madt_proc[0].count;
+   x2count = madt_proc[1].count;
}
if (!count && !x2count) {
printk(KERN_ERR PREFIX "No LAPIC entries present\n");
-- 
2.5.5

Re: [PATCH v9 0/2] [media] atmel-isc: add driver for Atmel ISC

[Hans Verkuil]

One quick question:

On 08/11/2016 09:06 AM, Songjun Wu wrote:
> The Image Sensor Controller driver includes two parts.
> 1) Driver code to implement the ISC function.
> 2) Device tree binding documentation, it describes how
>to add the ISC in device tree.
> 
> Test result with v4l-utils.
> # v4l2-compliance -f
> v4l2-compliance SHA   : not available
> 
> Driver Info:
> Driver name   : atmel_isc
> Card type : Atmel Image Sensor Controller
> Bus info  : platform:atmel_isc f0008000.isc
> Driver version: 4.7.0
> Capabilities  : 0x8421
> Video Capture
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0421
> Video Capture
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video0 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK (Not Supported)
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> test VIDIOC_QUERYCTRL: OK (Not Supported)
> test VIDIOC_G/S_CTRL: OK (Not Supported)
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 0 Private Controls: 0

Can you confirm that the sensor subdevice you are using does not have any 
controls?
I ask since that is fairly unusual, so I want to make sure that controls are 
really
not supported in this setup.

Regards,

Hans

Re: [Patch v4 6/9] driver/edac/fsl_ddr: Add support of little endian

[Borislav Petkov]

On Tue, Aug 09, 2016 at 02:55:43PM -0700, York Sun wrote:
> Get endianness from device tree. Both big endian and little endian
> are supported. Default to big endian for backward compatibility to
> MPC85xx.
> 
> Signed-off-by: York Sun 
> 
> ---
> Change log
>   v4: Absorb name changes by "Rename macros and names"
>   Drop testing for big-endian as suggested
>   Use of_property_read_bool() as suggested
>   v3: no change
>   v2: Separated from "Add support for ARM-based SoCs" patch
> 
>  .../fsl/ddr.txt}   |  2 +
>  drivers/edac/fsl_ddr_edac.c| 96 
> +-
>  2 files changed, 58 insertions(+), 40 deletions(-)
>  rename Documentation/devicetree/bindings/{powerpc/fsl/mem-ctrlr.txt => 
> memory-controllers/fsl/ddr.txt} (86%)

...

> @@ -95,8 +106,8 @@ static ssize_t fsl_mc_inject_data_lo_store(struct device 
> *dev,
>   struct mem_ctl_info *mci = to_mci(dev);
>   struct fsl_mc_pdata *pdata = mci->pvt_info;
>   if (isdigit(*data)) {
> - out_be32(pdata->mc_vbase + FSL_MC_DATA_ERR_INJECT_LO,
> -  simple_strtoul(data, NULL, 0));
> + ddr_out32(pdata->mc_vbase + FSL_MC_DATA_ERR_INJECT_LO,
> +   simple_strtoul(data, NULL, 0));
>   return count;
>   }
>   return 0;

WARNING: simple_strtoul is obsolete, use kstrtoul instead
#122: FILE: drivers/edac/fsl_ddr_edac.c:96:
+ simple_strtoul(data, NULL, 0));

Please send a fix ontop.

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Kernel 4.4.16 issue? AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0006 address=0x0000000000000080 flags=0x0020]

[Udo van den Heuvel]

Hello,

My dmesg shows a lot of these:

[920255.822392] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0
domain=0x0006 address=0x0080 flags=0x0020]
[920255.823404] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0
domain=0x0006 address=0x0080 flags=0x0020]

# cat /sys/bus/pci/devices/\:00\:12.0/resource
0xfeb5 0xfeb50fff 0x00040200
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
0x 0x 0x
#
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI
Controller (rev 11)

What is wrong?

Kind regards,
Udo

Re: musb: am3358: having problem with high-speed on usb1 at peripheral

[Greg KH]

On Fri, Aug 12, 2016 at 10:23:15AM +0800, ayaka wrote:
> Hello all:
>   I recently add a support for customize am3358 board using the branch
> processor-sdk-linux-03.00.00 from Ti git. But I meet a problem with musb
> at the peripheral mode.

Then you are going to have to get support from TI for this, nothing we
can do here about random vendor kernel trees, sorry.

If you can use the 4.7 tree, or better yet, the 4.8-rc tree, then we
will be glad to help you out.

good luck!

greg k-h

[PATCH] fs: remove unnecessary setting of error

[Salah Triki]

setting error to -EINVAL is unnecessary. It is already set, above.

Signed-off-by: Salah Triki 
---
 fs/open.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/open.c b/fs/open.c
index 4fd6e25..b438edc 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -176,7 +176,6 @@ static long do_sys_ftruncate(unsigned int fd, loff_t 
length, int small)
if (!S_ISREG(inode->i_mode) || !(f.file->f_mode & FMODE_WRITE))
goto out_putf;
 
-   error = -EINVAL;
/* Cannot ftruncate over 2^31 bytes without large file support */
if (small && length > MAX_NON_LFS)
goto out_putf;
-- 
1.9.1

Re: WARNING: CPU: 0 PID: 1271 at drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8

[Jaehoon Chung]

On 08/12/2016 04:13 PM, John Stultz wrote:
> On Thu, Aug 4, 2016 at 9:52 PM, John Stultz  wrote:
>> Hey Ulf,
>>   Since moving my HiKey branch to pre-v4.8-rc1 (linus's HEAD), I've
>> been seeing the following warning occasionally. Usually after seeing
>> it, the system will refuse to reboot (system does the "Emergency
>> remount complete" but then just sits there, and if I ctrl-c I can use
>> the shell fine but many commands will get me stuck).
>>
>> Anyway, if you have any ideas...
>>
>> thanks
>> -john
>>
>> [   24.154245] [ cut here ]
>> [   24.158903] WARNING: CPU: 2 PID: 1273 at
>> drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8
>> [   24.167605]
>> [   24.169104] CPU: 2 PID: 1273 Comm: mmcqd/0 Not tainted
>> 4.7.0-11945-gb30f1d6-dirty #706
>> [   24.177024] Hardware name: HiKey Development Board (DT)
>> [   24.182253] task: ffc0793d8c80 task.stack: ffc078c48000
>> [   24.188178] PC is at mmc_release_host+0xa0/0xa8
>> [   24.192725] LR is at mmc_put_card+0x18/0x3c
>> [   24.196917] pc : [] lr : []
>> pstate: 8145
>> [   24.204317] sp : ffc078c4bd20
>> [   24.207636] x29: ffc078c4bd20 x28: 
>> [   24.212975] x27:  x26: ffc077903420
>> [   24.216220] x25: ffc078788028 x24: ffc0787e8800
>> [   24.216232] x23: ffc078788000 x22: 
>> [   24.216243] x21:  x20: ffc078788018
>> [   24.216254] x19: ffc0787e8800 x18: 
>> [   24.216265] x17:  x16: 
>> [   24.216276] x15:  x14: ffc078789430
>> [   24.216288] x13: 002f x12: b853
>> [   24.216299] x11: ffc077903420 x10: 0860
>> [   24.216310] x9 : ffc078c48000 x8 : ffc0793d9540
>> [   24.216322] x7 : 00d3f8c7 x6 : 2bd0
>> [   24.216333] x5 : 021458fa x4 : 00ff
>> [   24.216344] x3 : d055 x2 : ffc078c4bd5c
>> [   24.216355] x1 :  x0 : 
>> [   24.216366]
>> [   24.216372] ---[ end trace 74dade4766b71d8d ]---
>> [   24.216377] Call trace:
>> [   24.216386] Exception stack(0xffc078c4bb50 to 0xffc078c4bc80)
>> [   24.216394] bb40:
>> ffc0787e8800 0080
>> [   24.216403] bb60: ffc078c4bd20 ff80086c2550
>> ff8008ca6000 ffc0784fb200
>> [   24.216411] bb80: ffc07bf4b7e8 0008
>> ffc0793d8d00 ff8008c82780
>> [   24.216420] bba0: ffc078c4bbe0 ff800843576c
>> ffc078c4bbf0 ff800843576c
>> [   24.216429] bbc0: ffc078c4bcc0 ffc078c4bc78
>> ffc078c4bc10 ff800843576c
>> [   24.216437] bbe0: ffc078c4bce0 ffc078c4bc98
>>  
>> [   24.216445] bc00: ffc078c4bd5c d055
>> 00ff 021458fa
>> [   24.216452] bc20: 2bd0 00d3f8c7
>> ffc0793d9540 ffc078c48000
>> [   24.216460] bc40: 0860 ffc077903420
>> b853 002f
>> [   24.216467] bc60: ffc078789430 
>>  
>> [   24.216479] [] mmc_release_host+0xa0/0xa8
>> [   24.216486] [] mmc_put_card+0x18/0x3c
>> [   24.216497] [] mmc_blk_issue_rq+0x11c/0x4a4
>> [   24.216506] [] mmc_queue_thread+0x98/0x158
>> [   24.216517] [] kthread+0xd0/0xe4
>> [   24.216527] [] ret_from_fork+0x10/0x40
> 
> 
> Hey Ulf,
>   I *think* I've narrowed this down to
> 6024e16654c1e1a2475e848d735963d05a12dba9 ("mmc: dw_mmc: set to
> MMC_CAP_ERASE by default"). Its fairly sporadic so I may be seeing
> this as a false positive, but after reverting that patch I've
> seemingly stopped seeing the issue.

Hmm, i don't think so. I *guess* it's not related with commit 6024e16654.

Before calling mmc_put_card(), is it issued the discard request?

if ((!req && !(mq->flags & MMC_QUEUE_NEW_REQUEST)) ||
 (cmd_flags & MMC_REQ_SPECIAL_MASK))

Which condition hit?

> 
> Anyway, I'll do some further testing tomorrow w/ that removed. Usually
> I see the issue 1-2 times an hour, so if I go the day w/o a problem
> I'll let you know.
> 
> Zhangfei/Guodong: Any ideas as to why ERASE might cause trouble on HiKey?

Did you try to send the Erase command directly? e,g fstrim or other things?
Is it occurred on every booting time?

Best Regards,
Jaehoon Chung

> 
> thanks
> -john
> 
> 
> 

Wrong "nollp" DW DMAC parameter value on ARC SDP.

[Eugeniy Paltsev]

Hi,

"nollp" parameter defines if DW DMAC channel supports multi block
transfer or not.

It is calculated in runtime, but differently depending on on
availability of pdata. If pdata is absent "nollp" is calculated using
autoconfig hardware registers. Otherwise "nollp" is calculated using
the next code construction:
channel_writel(dwc, LLP, DWC_LLP_LOC(0x));
dwc->nollp = DWC_LLP_LOC(channel_readl(dwc, LLP)) == 0;
channel_writel(dwc, LLP, 0);

I realized that these methods give different results.
For example on ARC AXS101 SDP in case of using autoconfig "nollp" was
calculated as "true" (and DMAC works fine), 
otherwise "nollp" was calculated as "false" (and DMAC doesn't work).

So I'm wondering how the code in question really works?
From DW AHB DMAC databook I wasn't able to find anything relevant to
this tricky implementation. Could you please clarify a little but what
happens here?
Maybe we should add "nollp" field in pdata structure and receive it
from pdata/device tree (like we use "is_private" or "is_memcpu" fields)

-- 
 Paltsev Eugeniy

[PATCH v3 2/4] arm64: vdso: constify vm_special_mapping used for aarch32 vectors page

[Jisheng Zhang]

The vm_special_mapping spec which is used for aarch32 vectors page is
never modified, so mark it as const.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/kernel/vdso.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index e320e8f..10ad8ab 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -88,7 +88,7 @@ int aarch32_setup_vectors_page(struct linux_binprm *bprm, int 
uses_interp)
 {
struct mm_struct *mm = current->mm;
unsigned long addr = AARCH32_VECTORS_BASE;
-   static struct vm_special_mapping spec = {
+   static const struct vm_special_mapping spec = {
.name   = "[vectors]",
.pages  = vectors_page,
 
-- 
2.8.1

[PATCH v3 0/4] arm64: put objects into proper sections

[Jisheng Zhang]

This series tries to put some objects into proper sections.

patch1 puts alloc_vectors_page() into .init section. This is a clean up
patch.
patch2 constify vm_special_mapping used for aarch32 vectors page.
patch3 fix the incorrect placement of __initdata and __read_mostly
patch4 apply __ro_after_init to some objects

Previously I only want to mark vdso_pages, vdso_spec, vectors_page and
cpu_ops as __read_mostly for performance reason. Then inspired by
Kees's patch[1], I think __ro_after_init is better.

[1] http://www.spinics.net/lists/arm-kernel/msg523188.html

Changes since v2:
  - include  for __ro_after_init, thank Mark's suggestions
  - make vdso_spec[0].pages and vdso_spec[1].pages assignment style
consistent, thank Mark for pointing it out.

Changes since v1:
  - use __ro_after_init instead of __read_mostly
  - find more objects to be suitable for __ro_after_init
  - add one more patch to fix the incorrect placement of __initdata and
__read_mostly


Jisheng Zhang (4):
  arm64: vdso: add __init section marker to alloc_vectors_page
  arm64: vdso: constify vm_special_mapping used for aarch32 vectors page
  arm64: kaslr: Fix incorrect placement of __initdata and __read_mostly
  arm64: apply __ro_after_init to some objects

 arch/arm64/kernel/cpu_ops.c |  2 +-
 arch/arm64/kernel/kaslr.c   |  4 ++--
 arch/arm64/kernel/vdso.c| 32 
 arch/arm64/mm/dma-mapping.c |  2 +-
 arch/arm64/mm/init.c|  4 ++--
 arch/arm64/mm/mmu.c |  2 +-
 6 files changed, 23 insertions(+), 23 deletions(-)

-- 
2.8.1

[PATCH v3 1/4] arm64: vdso: add __init section marker to alloc_vectors_page

[Jisheng Zhang]

It is not needed after booting, this patch moves the alloc_vectors_page
function to the __init section.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/kernel/vdso.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 076312b..e320e8f 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -55,7 +55,7 @@ struct vdso_data *vdso_data = &vdso_data_store.data;
  */
 static struct page *vectors_page[1];
 
-static int alloc_vectors_page(void)
+static int __init alloc_vectors_page(void)
 {
extern char __kuser_helper_start[], __kuser_helper_end[];
extern char __aarch32_sigret_code_start[], __aarch32_sigret_code_end[];
-- 
2.8.1

[PATCH v3 3/4] arm64: kaslr: Fix incorrect placement of __initdata and __read_mostly

[Jisheng Zhang]

__initdata and __read_mostly should be placed after the variable name
for the variable to be placed in the intended section.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/kernel/kaslr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index b054691..8ebabc4 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -20,8 +20,8 @@
 #include 
 #include 
 
-u64 __read_mostly module_alloc_base;
-u16 __initdata memstart_offset_seed;
+u64 module_alloc_base __read_mostly;
+u16 memstart_offset_seed __initdata;
 
 static __init u64 get_kaslr_seed(void *fdt)
 {
-- 
2.8.1

Re: [PATCH v3 4/7] clk: rockchip: rk3399: fix incorrect aclk_emmc source gate bits

[Heiko Stübner]

Am Dienstag, 2. August 2016, 15:19:58 schrieb Xing Zheng:
> Dues to incorrect diagram, we need to fix incorrect bits for
> (c/g)pll_aclk_emmc_src:
> cpll_aclk_emmc_src --> G6[13]
> gpll_aclk_emmc_src --> G6[12]
> 
> Signed-off-by: Xing Zheng 
> Reviewed-by: Shawn Lin 

applied to my clk-fixes branch for 4.8


Thanks
Heiko

[PATCH v3 4/4] arm64: apply __ro_after_init to some objects

[Jisheng Zhang]

These objects are set during initialization, thereafter are read only.

Previously I only want to mark vdso_pages, vdso_spec, vectors_page and
cpu_ops as __read_mostly from performance point of view. Then inspired
by Kees's patch[1] to apply more __ro_after_init for arm, I think it's
better to mark them as __ro_after_init. What's more, I find some more
objects are also read only after init. So apply __ro_after_init to all
of them.

This patch also removes global vdso_pagelist and tries to clean up
vdso_spec[] assignment code.

[1] http://www.spinics.net/lists/arm-kernel/msg523188.html

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/kernel/cpu_ops.c |  2 +-
 arch/arm64/kernel/kaslr.c   |  2 +-
 arch/arm64/kernel/vdso.c| 28 ++--
 arch/arm64/mm/dma-mapping.c |  2 +-
 arch/arm64/mm/init.c|  4 ++--
 arch/arm64/mm/mmu.c |  2 +-
 6 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
index c7cfb8f..6d32d1a 100644
--- a/arch/arm64/kernel/cpu_ops.c
+++ b/arch/arm64/kernel/cpu_ops.c
@@ -28,7 +28,7 @@ extern const struct cpu_operations smp_spin_table_ops;
 extern const struct cpu_operations acpi_parking_protocol_ops;
 extern const struct cpu_operations cpu_psci_ops;
 
-const struct cpu_operations *cpu_ops[NR_CPUS];
+const struct cpu_operations *cpu_ops[NR_CPUS] __ro_after_init;
 
 static const struct cpu_operations *dt_supported_cpu_ops[] __initconst = {
&smp_spin_table_ops,
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index 8ebabc4..93c47e1 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -20,7 +20,7 @@
 #include 
 #include 
 
-u64 module_alloc_base __read_mostly;
+u64 module_alloc_base __ro_after_init;
 u16 memstart_offset_seed __initdata;
 
 static __init u64 get_kaslr_seed(void *fdt)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 10ad8ab..c1ff7c2 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -19,6 +19,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -37,8 +38,7 @@
 #include 
 
 extern char vdso_start, vdso_end;
-static unsigned long vdso_pages;
-static struct page **vdso_pagelist;
+static unsigned long vdso_pages __ro_after_init;
 
 /*
  * The vDSO data page.
@@ -53,7 +53,7 @@ struct vdso_data *vdso_data = &vdso_data_store.data;
 /*
  * Create and map the vectors page for AArch32 tasks.
  */
-static struct page *vectors_page[1];
+static struct page *vectors_page[1] __ro_after_init;
 
 static int __init alloc_vectors_page(void)
 {
@@ -110,11 +110,19 @@ int aarch32_setup_vectors_page(struct linux_binprm *bprm, 
int uses_interp)
 }
 #endif /* CONFIG_COMPAT */
 
-static struct vm_special_mapping vdso_spec[2];
+static struct vm_special_mapping vdso_spec[2] __ro_after_init = {
+   {
+   .name   = "[vvar]",
+   },
+   {
+   .name   = "[vdso]",
+   },
+};
 
 static int __init vdso_init(void)
 {
int i;
+   struct page **vdso_pagelist;
 
if (memcmp(&vdso_start, "\177ELF", 4)) {
pr_err("vDSO is not a valid ELF object!\n");
@@ -138,16 +146,8 @@ static int __init vdso_init(void)
for (i = 0; i < vdso_pages; i++)
vdso_pagelist[i + 1] = pfn_to_page(PHYS_PFN(__pa(&vdso_start)) 
+ i);
 
-   /* Populate the special mapping structures */
-   vdso_spec[0] = (struct vm_special_mapping) {
-   .name   = "[vvar]",
-   .pages  = vdso_pagelist,
-   };
-
-   vdso_spec[1] = (struct vm_special_mapping) {
-   .name   = "[vdso]",
-   .pages  = &vdso_pagelist[1],
-   };
+   vdso_spec[0].pages = &vdso_pagelist[0];
+   vdso_spec[1].pages = &vdso_pagelist[1];
 
return 0;
 }
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index c4284c4..59d44e7 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -30,7 +30,7 @@
 
 #include 
 
-static int swiotlb __read_mostly;
+static int swiotlb __ro_after_init;
 
 static pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot,
 bool coherent)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index bbb7ee7..e8b81ea 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -55,8 +55,8 @@
  * executes, which assigns it its actual value. So use a default value
  * that cannot be mistaken for a real physical address.
  */
-s64 memstart_addr __read_mostly = -1;
-phys_addr_t arm64_dma_phys_limit __read_mostly;
+s64 memstart_addr __ro_after_init = -1;
+phys_addr_t arm64_dma_phys_limit __ro_after_init;
 
 #ifdef CONFIG_BLK_DEV_INITRD
 static int __init early_initrd(char *p)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 4989948..6029bed 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -46,7 +46,7 @@
 
 u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
 
-u64 kimage_voffset __read_mostly;
+u64 kimage_v

Re: [PATCH] get_maintainer: Quiet noisy implicit -f vcs_file_exists checking

[Wolfram Sang]

On Thu, Aug 11, 2016 at 03:46:03PM -0700, Joe Perches wrote:
> Checking command line filenames that are outside the git tree
> can emit a noisy and confusing message.
> 
> Quiet that message by redirecting stderr.
> Verify that the command was executed successfully.
> 
> Fixes: 4cad35a7ca69 ("get_maintainer.pl: reduce need for command-line option 
> -f")
> Reported-by: Wolfram Sang 
> Signed-off-by: Joe Perches 

Tested-by: Wolfram Sang 



signature.asc
Description: PGP signature

[PATCH v2] sched/deadline: Fix the intention to re-evalute tick dependency for offline cpu

[Wanpeng Li]

From: Wanpeng Li 

The dl task will be replenished after dl task timer fire and start a 
new period. It will be enqueued and to re-evaluate its dependency on 
the tick in order to restart it. However, if cpu is hot-unplug, 
irq_work_queue will splash since the target cpu is offline.

As a result:

WARNING: CPU: 2 PID: 0 at kernel/irq_work.c:69 irq_work_queue_on+0xad/0xe0
Call Trace:
 dump_stack+0x99/0xd0
 __warn+0xd1/0xf0
 warn_slowpath_null+0x1d/0x20
 irq_work_queue_on+0xad/0xe0
 tick_nohz_full_kick_cpu+0x44/0x50
 tick_nohz_dep_set_cpu+0x74/0xb0
 enqueue_task_dl+0x226/0x480
 activate_task+0x5c/0xa0
 dl_task_timer+0x19b/0x2c0
 ? push_dl_task.part.31+0x190/0x190
  
This can be triggered by hot-unplug the full dynticks cpu which dl 
task is running on. 

We enqueue the dl task on the offline CPU, because we need to do 
replenish for start_dl_timer(). So, as Juri pointed out, we would 
need to do is calling replenish_dl_entity() directly, instead of 
enqueue_task_dl(). pi_se shouldn't be a problem as the task shouldn't 
be boosted if it was throttled.

This patch fix it by just replenish dl entity to avoid the intention 
to re-evaluate tick dependency if the cpu is offline.

Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Juri Lelli 
Cc: Luca Abeni 
Cc: Frederic Weisbecker 
Signed-off-by: Wanpeng Li 
---
v1 -> v2:
 * replenish dl entity

 kernel/sched/deadline.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d091f4a..b141bd2 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -641,11 +641,15 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
goto unlock;
}
 
-   enqueue_task_dl(rq, p, ENQUEUE_REPLENISH);
-   if (dl_task(rq->curr))
-   check_preempt_curr_dl(rq, p, 0);
-   else
-   resched_curr(rq);
+   if (unlikely(!rq->online))
+   replenish_dl_entity(dl_se, dl_se);
+   else {
+   enqueue_task_dl(rq, p, ENQUEUE_REPLENISH);
+   if (dl_task(rq->curr))
+   check_preempt_curr_dl(rq, p, 0);
+   else
+   resched_curr(rq);
+   }
 
 #ifdef CONFIG_SMP
/*
-- 
1.9.1

Re: [PATCH v9 01/10] clk: fix initial state of critical clock's parents

[James Liao]

On Wed, 2016-08-10 at 14:09 -0700, Stephen Boyd wrote:
> (Including lists)
> 
> On 08/09, James Liao wrote:
> > On Wed, 2016-08-03 at 13:46 +0800, James Liao wrote:
> >>
> >> Hi Mike,
> >>
> >> Do you have new patches to fix new clock parents? If not, I think we can
> >> use my patch first. Is it okay?
> >>
> >
> > Hi Stephen,
> >
> > Do you have comments for the bug fixing? I prefer to use my patch (clk:
> > fix initial state of critical clock's parents). How do you think?
> >
> 
> How about we recalc accuracies and rates in addition to the patch
> from Mike? That will fix everything?

Hi Stephen,

It works!

I'll send a new series of MT2701 clock support in few days. Should I
include this patch in my series? Or you'll merge it into clk-next
directly?


Best regards,

James

> ---8<
> From: Michael Turquette 
> Subject: [PATCH] clk: migrate ref counts when orphans are reunited
> 
> It's always nice to see families reunited, and this is equally true when
> talking about parent clocks and their children. However, if the orphan
> clk had a positive prepare_count or enable_count, then we would not
> migrate those counts up the parent chain correctly.
> 
> This has manifested with the recent critical clocks feature, which often
> enables clocks very early, before their parents have been registered.
> 
> Fixed by replacing the call to clk_core_reparent with calls to
> __clk_set_parent_{before,after}.
> 
> Cc: James Liao 
> Cc: Erin Lo 
> Signed-off-by: Michael Turquette 
> [sb...@codeaurora.org: Recalc accuracies and rates too]
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/clk/clk.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 820a939fb6bb..dc3fff2bf839 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2449,8 +2449,16 @@ static int __clk_core_init(struct clk_core *core)
>   hlist_for_each_entry_safe(orphan, tmp2, &clk_orphan_list, child_node) {
>   struct clk_core *parent = __clk_init_parent(orphan);
>  
> - if (parent)
> - clk_core_reparent(orphan, parent);
> + /*
> +  * we could call __clk_set_parent, but that would result in a
> +  * reducant call to the .set_rate op, if it exists
> +  */
> + if (parent) {
> + __clk_set_parent_before(orphan, parent);
> + __clk_set_parent_after(orphan, parent, NULL);
> + __clk_recalc_accuracies(orphan);
> + __clk_recalc_rates(orphan, 0);
> + }
>   }
>  
>   /*

Re: [PATCH v2 2/2] kexec: extend kexec_file_load system call

[Balbir Singh]

On Thu, Aug 11, 2016 at 08:03:58PM -0300, Thiago Jung Bauermann wrote:
> From: AKASHI Takahiro 
> 
> Device tree blob must be passed to a second kernel on DTB-capable
> archs, like powerpc and arm64, but the current kernel interface
> lacks this support.
> 
> This patch extends kexec_file_load system call by adding an extra
> argument to this syscall so that an arbitrary number of file descriptors
> can be handed out from user space to the kernel.
> 
>   long sys_kexec_file_load(int kernel_fd, int initrd_fd,
>unsigned long cmdline_len,
>const char __user *cmdline_ptr,
>unsigned long flags,
>const struct kexec_fdset __user *ufdset);
> 
> If KEXEC_FILE_EXTRA_FDS is set to the "flags" argument, the "ufdset"
> argument points to the following struct buffer:
> 
>   struct kexec_fdset {
>   int nr_fds;
>   struct kexec_file_fd fds[0];
>   }
> 
> Signed-off-by: AKASHI Takahiro 
> Signed-off-by: Thiago Jung Bauermann 
> ---
>  include/linux/fs.h |  1 +
>  include/linux/kexec.h  |  7 ++--
>  include/linux/syscalls.h   |  4 ++-
>  include/uapi/linux/kexec.h | 22 
>  kernel/kexec_file.c| 83 
> ++
>  5 files changed, 108 insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 3523bf62f328..847d9c31f428 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2656,6 +2656,7 @@ extern int do_pipe_flags(int *, int);
>   id(MODULE, kernel-module)   \
>   id(KEXEC_IMAGE, kexec-image)\
>   id(KEXEC_INITRAMFS, kexec-initramfs)\
> + id(KEXEC_PARTIAL_DTB, kexec-partial-dtb)\

The backspace is over-indented?

>   id(POLICY, security-policy) \
>   id(MAX_ID, )
>  
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 4f85d284ed0b..29202935055d 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -148,7 +148,10 @@ struct kexec_file_ops {
>   kexec_verify_sig_t *verify_sig;
>  #endif
>  };
> -#endif
> +
> +int __weak arch_kexec_verify_buffer(enum kexec_file_type type, const void 
> *buf,
> + unsigned long size);
> +#endif /* CONFIG_KEXEC_FILE */
>  
>  struct kimage {
>   kimage_entry_t head;
> @@ -280,7 +283,7 @@ extern int kexec_load_disabled;
>  
>  /* List of defined/legal kexec file flags */
>  #define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
> -  KEXEC_FILE_NO_INITRAMFS)
> +  KEXEC_FILE_NO_INITRAMFS | KEXEC_FILE_EXTRA_FDS)
>  
>  #define VMCOREINFO_BYTES   (4096)
>  #define VMCOREINFO_NOTE_NAME   "VMCOREINFO"
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index d02239022bd0..fc072bdb74e3 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -66,6 +66,7 @@ struct perf_event_attr;
>  struct file_handle;
>  struct sigaltstack;
>  union bpf_attr;
> +struct kexec_fdset;
>  
>  #include 
>  #include 
> @@ -321,7 +322,8 @@ asmlinkage long sys_kexec_load(unsigned long entry, 
> unsigned long nr_segments,
>  asmlinkage long sys_kexec_file_load(int kernel_fd, int initrd_fd,
>   unsigned long cmdline_len,
>   const char __user *cmdline_ptr,
> - unsigned long flags);
> + unsigned long flags,
> + const struct kexec_fdset __user *ufdset);
>  
>  asmlinkage long sys_exit(int error_code);
>  asmlinkage long sys_exit_group(int error_code);
> diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
> index aae5ebf2022b..6279be79efba 100644
> --- a/include/uapi/linux/kexec.h
> +++ b/include/uapi/linux/kexec.h
> @@ -23,6 +23,28 @@
>  #define KEXEC_FILE_UNLOAD0x0001
>  #define KEXEC_FILE_ON_CRASH  0x0002
>  #define KEXEC_FILE_NO_INITRAMFS  0x0004
> +#define KEXEC_FILE_EXTRA_FDS 0x0008
> +
> +enum kexec_file_type {
> + KEXEC_FILE_TYPE_KERNEL,
> + KEXEC_FILE_TYPE_INITRAMFS,
> +
> + /*
> +  * Device Tree Blob containing just the nodes and properties that
> +  * the kexec_file_load caller wants to add or modify.
> +  */
> + KEXEC_FILE_TYPE_PARTIAL_DTB,
> +};
> +
> +struct kexec_file_fd {
> + enum kexec_file_type type;
> + int fd;
> +};
> +
> +struct kexec_fdset {
> + int nr_fds;
> + struct kexec_file_fd fds[0];
> +};
>  
>  /* These values match the ELF architecture values.
>   * Unless there is a good reason that should continue to be the case.
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 113af2f219b9..d6803dd884e2 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -25,6 +25,9 @@
>  #include 
>  #include 

Re: [PATCH v3 2/9] hwmon: (core) New hwmon registration API

[Keerthy]

On Monday 25 July 2016 09:02 AM, Guenter Roeck wrote:

Up to now, each hwmon driver has to implement its own sysfs attributes.
This requires a lot of template code, and distracts from the driver's core
function to read and write chip registers.

To be able to reduce driver complexity, move sensor attribute handling
and thermal zone registration into hwmon core. By using the new API,
driver code and data size is typically reduced by 20-70%, depending
on driver complexity and the number of sysfs attributes supported.

With this patch, the new API only supports thermal sensors. Support for
other sensor types will be added with subsequent patches.


Hi Guenter,

Seems like this patch introduces a cycling dependency between
thermal_sys and hwmon:

DEPMOD 4.8.0-rc1-next-20160811-1-g2f84cf7854e7
depmod: ERROR: Found 2 modules in dependency cycles!
depmod: ERROR: Cycle detected: hwmon -> thermal_sys -> hwmon

As reported by R, Vignesh .

- Keerthy


Acked-by: Punit Agrawal 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Guenter Roeck 
---
v3:
- Thermal registration depends on IS_REACHABLE(CONFIG_THERMAL) and
   CONFIG_THERMAL_OF.
v2:
- Document callback function parameters of struct hwmon_ops in
   include/linux/hwmon.h.
- Clarify that the is_visible() callback is mandatory.
- Initialize device attribute read/write callback functions unconditionally.
- If an attribute has no template string, treat it as invisible, not as
   error. Affected are virtual attributes such as HWMON_C_REGISTER_TZ.
- Added newline to improve readability.

Review comments not addressed:
- Stick with u32 for attribute masks. We could use u64, but it is currently
   not needed, and changing it later would be straightforward.
- Do not use for_each_set_bit() to walk attribute masks.
   for_each_set_bit() expects a pointer to an unsigned long as argument,
   which would make it difficult to switch to u64 attribute masks if/when
   needed.

  drivers/hwmon/hwmon.c | 485 +++---
  include/linux/hwmon.h | 148 +++
  2 files changed, 606 insertions(+), 27 deletions(-)

diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index 649a68d119b4..3e4cc442a089 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -12,6 +12,7 @@

  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

+#include 
  #include 
  #include 
  #include 
@@ -21,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 

  #define HWMON_ID_PREFIX "hwmon"
  #define HWMON_ID_FORMAT HWMON_ID_PREFIX "%d"
@@ -28,9 +30,35 @@
  struct hwmon_device {
const char *name;
struct device dev;
+   const struct hwmon_chip_info *chip;
+
+   struct attribute_group group;
+   const struct attribute_group **groups;
  };
+
  #define to_hwmon_device(d) container_of(d, struct hwmon_device, dev)

+struct hwmon_device_attribute {
+   struct device_attribute dev_attr;
+   const struct hwmon_ops *ops;
+   enum hwmon_sensor_types type;
+   u32 attr;
+   int index;
+};
+
+#define to_hwmon_attr(d) \
+   container_of(d, struct hwmon_device_attribute, dev_attr)
+
+/*
+ * Thermal zone information
+ * In addition to the reference to the hwmon device,
+ * also provides the sensor index.
+ */
+struct hwmon_thermal_data {
+   struct hwmon_device *hwdev; /* Reference to hwmon device */
+   int index;  /* sensor index */
+};
+
  static ssize_t
  show_name(struct device *dev, struct device_attribute *attr, char *buf)
  {
@@ -78,25 +106,286 @@ static struct class hwmon_class = {

  static DEFINE_IDA(hwmon_ida);

-/**
- * hwmon_device_register_with_groups - register w/ hwmon
- * @dev: the parent device
- * @name: hwmon name attribute
- * @drvdata: driver data to attach to created device
- * @groups: List of attribute groups to create
- *
- * hwmon_device_unregister() must be called when the device is no
- * longer needed.
- *
- * Returns the pointer to the new device.
- */
-struct device *
-hwmon_device_register_with_groups(struct device *dev, const char *name,
- void *drvdata,
- const struct attribute_group **groups)
+/* Thermal zone handling */
+
+#if IS_REACHABLE(CONFIG_THERMAL) && defined(CONFIG_THERMAL_OF)
+static int hwmon_thermal_get_temp(void *data, int *temp)
+{
+   struct hwmon_thermal_data *tdata = data;
+   struct hwmon_device *hwdev = tdata->hwdev;
+   int ret;
+   long t;
+
+   ret = hwdev->chip->ops->read(&hwdev->dev, hwmon_temp, hwmon_temp_input,
+tdata->index, &t);
+   if (ret < 0)
+   return ret;
+
+   *temp = t;
+
+   return 0;
+}
+
+static struct thermal_zone_of_device_ops hwmon_thermal_ops = {
+   .get_temp = hwmon_thermal_get_temp,
+};
+
+static int hwmon_thermal_add_sensor(struct device *dev,
+   struct hwmon_device *hwdev, int index)
+{
+   struct hwmon_thermal_data *tda

[PATCH v3] ARM: VDSO: put RO and RO after init objects into proper sections

[Jisheng Zhang]

vdso_data_mapping is never modified, so mark it as const.

vdso_total_pages, vdso_data_page, vdso_text_mapping and cntvct_ok are
initialized by vdso_init(), thereafter are read only.

The fact that they are read only after init makes them candidates for
__ro_after_init declarations.

Signed-off-by: Jisheng Zhang 
---

Since v2:
  - include  explicitly for __ro_after_init

Since v1:
  - use __ro_after_init instead of __read_mostly
  - apply __ro_after_init for vdso_total_pages and cntvct_ok as well

 arch/arm/kernel/vdso.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index 994e971..bbbffe94 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -17,6 +17,7 @@
  * along with this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -39,7 +40,7 @@
 static struct page **vdso_text_pagelist;
 
 /* Total number of pages needed for the data and text portions of the VDSO. */
-unsigned int vdso_total_pages __read_mostly;
+unsigned int vdso_total_pages __ro_after_init;
 
 /*
  * The VDSO data page.
@@ -47,13 +48,13 @@ unsigned int vdso_total_pages __read_mostly;
 static union vdso_data_store vdso_data_store __page_aligned_data;
 static struct vdso_data *vdso_data = &vdso_data_store.data;
 
-static struct page *vdso_data_page;
-static struct vm_special_mapping vdso_data_mapping = {
+static struct page *vdso_data_page __ro_after_init;
+static const struct vm_special_mapping vdso_data_mapping = {
.name = "[vvar]",
.pages = &vdso_data_page,
 };
 
-static struct vm_special_mapping vdso_text_mapping = {
+static struct vm_special_mapping vdso_text_mapping __ro_after_init = {
.name = "[vdso]",
 };
 
@@ -67,7 +68,7 @@ struct elfinfo {
 /* Cached result of boot-time check for whether the arch timer exists,
  * and if so, whether the virtual counter is useable.
  */
-static bool cntvct_ok __read_mostly;
+static bool cntvct_ok __ro_after_init;
 
 static bool __init cntvct_functional(void)
 {
-- 
2.8.1

Re: [PATCH RESEND v2 1/3] dt: bindings: add bindings for Allwinner A64 usb phy

[Hans de Goede]

Hi,

On 12-08-16 05:06, Icenowy Zheng wrote:

Signed-off-by: Icenowy Zheng 


Series is still:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 95736d7..287150d 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -10,6 +10,7 @@ Required properties:
   * allwinner,sun8i-a23-usb-phy
   * allwinner,sun8i-a33-usb-phy
   * allwinner,sun8i-h3-usb-phy
+  * allwinner,sun50i-a64-usb-phy
 - reg : a list of offset + length pairs
 - reg-names :
   * "phy_ctrl"

[tip:locking/core] locking/Documentation: Fix wrong section reference

[tip-bot for SeongJae Park]

Commit-ID:  d7cab36db83be458e8987ae352902958977e7925
Gitweb: http://git.kernel.org/tip/d7cab36db83be458e8987ae352902958977e7925
Author: SeongJae Park 
AuthorDate: Thu, 11 Aug 2016 11:17:41 -0700
Committer:  Ingo Molnar 
CommitDate: Fri, 12 Aug 2016 08:24:13 +0200

locking/Documentation: Fix wrong section reference

Signed-off-by: SeongJae Park 
Signed-off-by: Paul E. McKenney 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: dhowe...@redhat.com
Cc: linux-a...@vger.kernel.org
Cc: will.dea...@arm.com
Link: 
http://lkml.kernel.org/r/1470939463-31950-2-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar 
---
 Documentation/memory-barriers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index e1926a0..19c8eb6 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -2076,7 +2076,7 @@ systems, and so cannot be counted on in such a situation 
to actually achieve
 anything at all - especially with respect to I/O accesses - unless combined
 with interrupt disabling operations.
 
-See also the section on "Inter-CPU locking barrier effects".
+See also the section on "Inter-CPU acquiring barrier effects".
 
 
 As an example, consider the following:

[tip:locking/core] locking/Documentation: Maintain consistent blank line

[tip-bot for SeongJae Park]

Commit-ID:  dfeccea61716d3ca1bf3477610d1f29abf6d99ca
Gitweb: http://git.kernel.org/tip/dfeccea61716d3ca1bf3477610d1f29abf6d99ca
Author: SeongJae Park 
AuthorDate: Thu, 11 Aug 2016 11:17:40 -0700
Committer:  Ingo Molnar 
CommitDate: Fri, 12 Aug 2016 08:24:13 +0200

locking/Documentation: Maintain consistent blank line

Signed-off-by: SeongJae Park 
Signed-off-by: Paul E. McKenney 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: dhowe...@redhat.com
Cc: linux-a...@vger.kernel.org
Cc: will.dea...@arm.com
Link: 
http://lkml.kernel.org/r/1470939463-31950-1-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar 
---
 Documentation/memory-barriers.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index a4d0a99..e1926a0 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1928,6 +1928,7 @@ There are some more advanced barrier functions:
 
  See Documentation/DMA-API.txt for more information on consistent memory.
 
+
 MMIO WRITE BARRIER
 --
 

[tip:locking/core] locking/Documentation: Fix a typo of example result

[tip-bot for SeongJae Park]

Commit-ID:  8b9e771555745a029557a0a481e760fb84376a35
Gitweb: http://git.kernel.org/tip/8b9e771555745a029557a0a481e760fb84376a35
Author: SeongJae Park 
AuthorDate: Thu, 11 Aug 2016 11:17:42 -0700
Committer:  Ingo Molnar 
CommitDate: Fri, 12 Aug 2016 08:24:13 +0200

locking/Documentation: Fix a typo of example result

An example result for data dependent write has a typo.  This commit
fixes the wrong typo.

Signed-off-by: SeongJae Park 
Signed-off-by: Paul E. McKenney 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: dhowe...@redhat.com
Cc: linux-a...@vger.kernel.org
Cc: will.dea...@arm.com
Link: 
http://lkml.kernel.org/r/1470939463-31950-3-git-send-email-paul...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar 
---
 Documentation/memory-barriers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index 19c8eb6..ba818ec 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -609,7 +609,7 @@ A data-dependency barrier must also order against dependent 
writes:
 The data-dependency barrier must order the read into Q with the store
 into *Q.  This prohibits this outcome:
 
-   (Q == B) && (B == 4)
+   (Q == &B) && (B == 4)
 
 Please note that this pattern should be rare.  After all, the whole point
 of dependency ordering is to -prevent- writes to the data structure, along

[tip:perf/urgent] perf/x86/intel/uncore: Add enable_box for client MSR uncore

[tip-bot for Kan Liang]

Commit-ID:  95f3be798472f63b495ca4712af005ea5ac7aa47
Gitweb: http://git.kernel.org/tip/95f3be798472f63b495ca4712af005ea5ac7aa47
Author: Kan Liang 
AuthorDate: Thu, 11 Aug 2016 07:31:14 -0700
Committer:  Ingo Molnar 
CommitDate: Fri, 12 Aug 2016 08:35:05 +0200

perf/x86/intel/uncore: Add enable_box for client MSR uncore

There are bug reports about miscounting uncore counters on some
client machines like Sandybridge, Broadwell and Skylake. It is
very likely to be observed on idle systems.

This issue is caused by a hardware issue. PERF_GLOBAL_CTL could be
cleared after Package C7, and nothing will be count.
The related errata (HSD 158) could be found in:

  
www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-desktop-specification-update.pdf

This patch tries to work around this issue by re-enabling PERF_GLOBAL_CTL
in ->enable_box(). The workaround does not cover all cases. It helps for new
events after returning from C7. But it cannot prevent C7, it will still
miscount if a counter is already active.

There is no drawback in leaving it enabled, so it does not need
disable_box() here.

Signed-off-by: Kan Liang 
Cc: 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Link: 
http://lkml.kernel.org/r/1470925874-59943-1-git-send-email-kan.li...@intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/events/intel/uncore_snb.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/x86/events/intel/uncore_snb.c 
b/arch/x86/events/intel/uncore_snb.c
index 97a69db..9d35ec0 100644
--- a/arch/x86/events/intel/uncore_snb.c
+++ b/arch/x86/events/intel/uncore_snb.c
@@ -100,6 +100,12 @@ static void snb_uncore_msr_init_box(struct 
intel_uncore_box *box)
}
 }
 
+static void snb_uncore_msr_enable_box(struct intel_uncore_box *box)
+{
+   wrmsrl(SNB_UNC_PERF_GLOBAL_CTL,
+   SNB_UNC_GLOBAL_CTL_EN | SNB_UNC_GLOBAL_CTL_CORE_ALL);
+}
+
 static void snb_uncore_msr_exit_box(struct intel_uncore_box *box)
 {
if (box->pmu->pmu_idx == 0)
@@ -127,6 +133,7 @@ static struct attribute_group snb_uncore_format_group = {
 
 static struct intel_uncore_ops snb_uncore_msr_ops = {
.init_box   = snb_uncore_msr_init_box,
+   .enable_box = snb_uncore_msr_enable_box,
.exit_box   = snb_uncore_msr_exit_box,
.disable_event  = snb_uncore_msr_disable_event,
.enable_event   = snb_uncore_msr_enable_event,
@@ -192,6 +199,12 @@ static void skl_uncore_msr_init_box(struct 
intel_uncore_box *box)
}
 }
 
+static void skl_uncore_msr_enable_box(struct intel_uncore_box *box)
+{
+   wrmsrl(SKL_UNC_PERF_GLOBAL_CTL,
+   SNB_UNC_GLOBAL_CTL_EN | SKL_UNC_GLOBAL_CTL_CORE_ALL);
+}
+
 static void skl_uncore_msr_exit_box(struct intel_uncore_box *box)
 {
if (box->pmu->pmu_idx == 0)
@@ -200,6 +213,7 @@ static void skl_uncore_msr_exit_box(struct intel_uncore_box 
*box)
 
 static struct intel_uncore_ops skl_uncore_msr_ops = {
.init_box   = skl_uncore_msr_init_box,
+   .enable_box = skl_uncore_msr_enable_box,
.exit_box   = skl_uncore_msr_exit_box,
.disable_event  = snb_uncore_msr_disable_event,
.enable_event   = snb_uncore_msr_enable_event,

Re: WARNING: CPU: 0 PID: 1271 at drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8

[Shawn Lin]

在 2016/8/12 16:01, Jaehoon Chung 写道:

On 08/12/2016 04:13 PM, John Stultz wrote:

On Thu, Aug 4, 2016 at 9:52 PM, John Stultz  wrote:

Hey Ulf,
  Since moving my HiKey branch to pre-v4.8-rc1 (linus's HEAD), I've
been seeing the following warning occasionally. Usually after seeing
it, the system will refuse to reboot (system does the "Emergency
remount complete" but then just sits there, and if I ctrl-c I can use
the shell fine but many commands will get me stuck).

Anyway, if you have any ideas...

thanks
-john

[   24.154245] [ cut here ]
[   24.158903] WARNING: CPU: 2 PID: 1273 at
drivers/mmc/core/core.c:991 mmc_release_host+0xa0/0xa8
[   24.167605]
[   24.169104] CPU: 2 PID: 1273 Comm: mmcqd/0 Not tainted
4.7.0-11945-gb30f1d6-dirty #706
[   24.177024] Hardware name: HiKey Development Board (DT)
[   24.182253] task: ffc0793d8c80 task.stack: ffc078c48000
[   24.188178] PC is at mmc_release_host+0xa0/0xa8
[   24.192725] LR is at mmc_put_card+0x18/0x3c
[   24.196917] pc : [] lr : []
pstate: 8145
[   24.204317] sp : ffc078c4bd20
[   24.207636] x29: ffc078c4bd20 x28: 
[   24.212975] x27:  x26: ffc077903420
[   24.216220] x25: ffc078788028 x24: ffc0787e8800
[   24.216232] x23: ffc078788000 x22: 
[   24.216243] x21:  x20: ffc078788018
[   24.216254] x19: ffc0787e8800 x18: 
[   24.216265] x17:  x16: 
[   24.216276] x15:  x14: ffc078789430
[   24.216288] x13: 002f x12: b853
[   24.216299] x11: ffc077903420 x10: 0860
[   24.216310] x9 : ffc078c48000 x8 : ffc0793d9540
[   24.216322] x7 : 00d3f8c7 x6 : 2bd0
[   24.216333] x5 : 021458fa x4 : 00ff
[   24.216344] x3 : d055 x2 : ffc078c4bd5c
[   24.216355] x1 :  x0 : 
[   24.216366]
[   24.216372] ---[ end trace 74dade4766b71d8d ]---
[   24.216377] Call trace:
[   24.216386] Exception stack(0xffc078c4bb50 to 0xffc078c4bc80)
[   24.216394] bb40:
ffc0787e8800 0080
[   24.216403] bb60: ffc078c4bd20 ff80086c2550
ff8008ca6000 ffc0784fb200
[   24.216411] bb80: ffc07bf4b7e8 0008
ffc0793d8d00 ff8008c82780
[   24.216420] bba0: ffc078c4bbe0 ff800843576c
ffc078c4bbf0 ff800843576c
[   24.216429] bbc0: ffc078c4bcc0 ffc078c4bc78
ffc078c4bc10 ff800843576c
[   24.216437] bbe0: ffc078c4bce0 ffc078c4bc98
 
[   24.216445] bc00: ffc078c4bd5c d055
00ff 021458fa
[   24.216452] bc20: 2bd0 00d3f8c7
ffc0793d9540 ffc078c48000
[   24.216460] bc40: 0860 ffc077903420
b853 002f
[   24.216467] bc60: ffc078789430 
 
[   24.216479] [] mmc_release_host+0xa0/0xa8
[   24.216486] [] mmc_put_card+0x18/0x3c
[   24.216497] [] mmc_blk_issue_rq+0x11c/0x4a4
[   24.216506] [] mmc_queue_thread+0x98/0x158
[   24.216517] [] kthread+0xd0/0xe4
[   24.216527] [] ret_from_fork+0x10/0x40



Hey Ulf,
  I *think* I've narrowed this down to
6024e16654c1e1a2475e848d735963d05a12dba9 ("mmc: dw_mmc: set to
MMC_CAP_ERASE by default"). Its fairly sporadic so I may be seeing
this as a false positive, but after reverting that patch I've
seemingly stopped seeing the issue.


Hmm, i don't think so. I *guess* it's not related with commit 6024e16654.

Before calling mmc_put_card(), is it issued the discard request?

if ((!req && !(mq->flags & MMC_QUEUE_NEW_REQUEST)) ||
 (cmd_flags & MMC_REQ_SPECIAL_MASK))

Which condition hit?


If special req meets, mrq_pre and mrq_cur are both null after schedule
queue. And for this special req, host->claimed is released. For the
next req peeking from blk, we run into mmc_get_card again which means
we should never meet this WARN when releasing host. So it's
interesting to dig out actually what is happening there...

But at least for dw_mmc-rockchip, we have been using this feature,
ERASE/Trim/discard, for years. I didn't see it ever. Anyway from the
code I was reading, I don't think it should be issue of this commit.

Please look at this regression report I saw.

https://lkml.org/lkml/2016/8/11/130





Anyway, I'll do some further testing tomorrow w/ that removed. Usually
I see the issue 1-2 times an hour, so if I go the day w/o a problem
I'll let you know.

Zhangfei/Guodong: Any ideas as to why ERASE might cause trouble on HiKey?


Did you try to send the Erase command directly? e,g fstrim or other things?
Is it occurred on every booting time?

Best Regards,
Jaehoon Chung



thanks
-john











--
Best Regards
Shawn Lin

[tip:perf/urgent] perf/x86/intel/uncore: Fix uncore num_counters

[tip-bot for Kan Liang]

Commit-ID:  10e9e7bd598f9a66a11a22514c68c13c41fc821b
Gitweb: http://git.kernel.org/tip/10e9e7bd598f9a66a11a22514c68c13c41fc821b
Author: Kan Liang 
AuthorDate: Thu, 11 Aug 2016 07:30:20 -0700
Committer:  Ingo Molnar 
CommitDate: Fri, 12 Aug 2016 08:35:04 +0200

perf/x86/intel/uncore: Fix uncore num_counters

Some uncore boxes' num_counters value for Haswell server and
Broadwell server are not correct (too large, off by one).

This issue was found by comparing the code with the document. Although
there is no bug report from users yet, accessing non-existent counters
is dangerous and the behavior is undefined: it may cause miscounting or
even crashes.

This patch makes them consistent with the uncore document.

Reported-by: Lukasz Odzioba 
Signed-off-by: Kan Liang 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: 
Link: 
http://lkml.kernel.org/r/1470925820-59847-1-git-send-email-kan.li...@intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/events/intel/uncore_snbep.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/events/intel/uncore_snbep.c 
b/arch/x86/events/intel/uncore_snbep.c
index 824e540..8aee83b 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -2626,7 +2626,7 @@ void hswep_uncore_cpu_init(void)
 
 static struct intel_uncore_type hswep_uncore_ha = {
.name   = "ha",
-   .num_counters   = 5,
+   .num_counters   = 4,
.num_boxes  = 2,
.perf_ctr_bits  = 48,
SNBEP_UNCORE_PCI_COMMON_INIT(),
@@ -2645,7 +2645,7 @@ static struct uncore_event_desc hswep_uncore_imc_events[] 
= {
 
 static struct intel_uncore_type hswep_uncore_imc = {
.name   = "imc",
-   .num_counters   = 5,
+   .num_counters   = 4,
.num_boxes  = 8,
.perf_ctr_bits  = 48,
.fixed_ctr_bits = 48,
@@ -2691,7 +2691,7 @@ static struct intel_uncore_type hswep_uncore_irp = {
 
 static struct intel_uncore_type hswep_uncore_qpi = {
.name   = "qpi",
-   .num_counters   = 5,
+   .num_counters   = 4,
.num_boxes  = 3,
.perf_ctr_bits  = 48,
.perf_ctr   = SNBEP_PCI_PMON_CTR0,
@@ -2773,7 +2773,7 @@ static struct event_constraint 
hswep_uncore_r3qpi_constraints[] = {
 
 static struct intel_uncore_type hswep_uncore_r3qpi = {
.name   = "r3qpi",
-   .num_counters   = 4,
+   .num_counters   = 3,
.num_boxes  = 3,
.perf_ctr_bits  = 44,
.constraints= hswep_uncore_r3qpi_constraints,
@@ -2972,7 +2972,7 @@ static struct intel_uncore_type bdx_uncore_ha = {
 
 static struct intel_uncore_type bdx_uncore_imc = {
.name   = "imc",
-   .num_counters   = 5,
+   .num_counters   = 4,
.num_boxes  = 8,
.perf_ctr_bits  = 48,
.fixed_ctr_bits = 48,

[tip:perf/urgent] uprobes/x86: Fix RIP-relative handling of EVEX-encoded instructions

[tip-bot for Denys Vlasenko]

Commit-ID:  68187872c76a96ed4db7bfb064272591f02e208b
Gitweb: http://git.kernel.org/tip/68187872c76a96ed4db7bfb064272591f02e208b
Author: Denys Vlasenko 
AuthorDate: Thu, 11 Aug 2016 17:45:21 +0200
Committer:  Ingo Molnar 
CommitDate: Fri, 12 Aug 2016 08:29:24 +0200

uprobes/x86: Fix RIP-relative handling of EVEX-encoded instructions

Since instruction decoder now supports EVEX-encoded instructions, two fixes
are needed to correctly handle them in uprobes.

Extended bits for MODRM.rm field need to be sanitized just like we do it
for VEX3, to avoid encoding wrong register for register-relative access.

EVEX has _two_ extended bits: b and x. Theoretically, EVEX.x should be
ignored by the CPU (since GPRs go only up to 15, not 31), but let's be
paranoid here: proper encoding for register-relative access
should have EVEX.x = 1.

Secondly, we should fetch vex. for EVEX too.
This is now super easy because instruction decoder populates
vex_prefix.bytes[2] for all flavors of (e)vex encodings, even for VEX2.

Signed-off-by: Denys Vlasenko 
Acked-by: Masami Hiramatsu 
Acked-by: Srikar Dronamraju 
Cc: Alexander Shishkin 
Cc: Andy Lutomirski 
Cc: Arnaldo Carvalho de Melo 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: H. Peter Anvin 
Cc: Jim Keniston 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Masami Hiramatsu 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: linux-kernel@vger.kernel.org
Cc:  # v4.1+
Fixes: 8a764a875fe3 ("x86/asm/decoder: Create artificial 3rd byte for 2-byte 
VEX")
Link: http://lkml.kernel.org/r/20160811154521.20469-1-dvlas...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/uprobes.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 6c1ff31..495c776 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -357,20 +357,22 @@ static void riprel_analyze(struct arch_uprobe *auprobe, 
struct insn *insn)
*cursor &= 0xfe;
}
/*
-* Similar treatment for VEX3 prefix.
-* TODO: add XOP/EVEX treatment when insn decoder supports them
+* Similar treatment for VEX3/EVEX prefix.
+* TODO: add XOP treatment when insn decoder supports them
 */
-   if (insn->vex_prefix.nbytes == 3) {
+   if (insn->vex_prefix.nbytes >= 3) {
/*
 * vex2: c5rLpp   (has no b bit)
 * vex3/xop: c4/8f rxbm wLpp
 * evex: 62rxbR00mm w1pp zllBVaaa
-*   (evex will need setting of both b and x since
-*   in non-sib encoding evex.x is 4th bit of MODRM.rm)
-* Setting VEX3.b (setting because it has inverted meaning):
+* Setting VEX3.b (setting because it has inverted meaning).
+* Setting EVEX.x since (in non-SIB encoding) EVEX.x
+* is the 4th bit of MODRM.rm, and needs the same treatment.
+* For VEX3-encoded insns, VEX3.x value has no effect in
+* non-SIB encoding, the change is superfluous but harmless.
 */
cursor = auprobe->insn + insn_offset_vex_prefix(insn) + 1;
-   *cursor |= 0x20;
+   *cursor |= 0x60;
}
 
/*
@@ -415,12 +417,10 @@ static void riprel_analyze(struct arch_uprobe *auprobe, 
struct insn *insn)
 
reg = MODRM_REG(insn);  /* Fetch modrm.reg */
reg2 = 0xff;/* Fetch vex. */
-   if (insn->vex_prefix.nbytes == 2)
-   reg2 = insn->vex_prefix.bytes[1];
-   else if (insn->vex_prefix.nbytes == 3)
+   if (insn->vex_prefix.nbytes)
reg2 = insn->vex_prefix.bytes[2];
/*
-* TODO: add XOP, EXEV  reading.
+* TODO: add XOP  reading.
 *
 * vex. field is in bits 6-3, bits are inverted.
 * But in 32-bit mode, high-order bit may be ignored.

Re: [RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

[Daniel Vetter]

On Fri, Aug 12, 2016 at 12:05:04PM +0530, Sumit Semwal wrote:
> Hi Jon!
> 
> On 11 August 2016 at 20:06, Jonathan Corbet  wrote:
> > On Thu, 11 Aug 2016 16:17:56 +0530
> > Sumit Semwal  wrote:
> >
> >> Convert dma-buf documentation over to sphinx; also cleanup to
> >> address sphinx warnings.
> >>
> >> While at that, convert dma-buf-sharing.txt as well, and make it the
> >> dma-buf API guide.
> >
> > Thanks for working to improve the documentation!  I do have a few overall
> > comments...
> >
> Thank you for your review, and comments; my responses are inline.
> 
> >  - The two comment fixes are a separate thing that should go straight to
> >the dma-buf maintainer, who is ...  ... evidently somebody
> >familiar to you :)  I assume you'll merge those two directly?
> >
> Yes, of course :) - I will merge them directly, and will remove them
> from v2 of this series.
> 
> >  - It looks like you create a new RST document but leave the old one in
> >place.  Having two copies of the document around can only lead to
> >confusion, so I think the old one should go.
> >
> Agreed on this as well; will correct it.
> 
> >  - I really wonder if we want to start carving pieces out of
> >device-drivers.tmpl in this way.  I guess I would rather see the
> >conversion of that book and the better integration of the other docs
> >*into* it.  One of the goals of this whole thing is to unify our
> >documentation, not to reinforce the silos.
> >
> I should've mentioned it in the cover letter - my intention of taking
> the dma-buf pieces out was to focus on these first while moving to
> sphinx.
> 
> My proposal would be, if all the device driver section owners could
> take the relevant pieces, convert them to sphinx (ironing out warnings
> etc in the process), then we can again 'bind' them together into the
> device drivers book in rst format.
> This breaks the documentation conversion task into manageable pieces
> that can be handled independently, and gives everyone flexibility to
> work on their schedules.
> 
> This should also help in a good technical re-look at the content by
> subsystem developers, and make any documentation updates as required.
> The beauty of sphinx should allow us this, I think? Just my 2 cents.

I already tried to trick Sumit into converting the entire
device-drivers.tmpl, but he didn't take the bait ;-)

I think just extracting dma-buf stuff (dma_buf, fence, reservation and all
that) is ok though, it is a fairly stand-alone topic.
-Daniel

> 
> > Does that make sense?
> >
> I do hope that my proposal above finds some merit with everyone.
> 
> > Thanks,
> >
> > jon
> 
> BR,
> Sumit.
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH RESEND] phy: brcm-sata: Return proper error if brcm_sata_phy_init fails

[Kishon Vijay Abraham I]

On Wednesday 10 August 2016 03:34 PM, Axel Lin wrote:
> Return proper error instead of 0 if brcm_sata_phy_init fails.

merged now, thanks.

-Kishon

> 
> Signed-off-by: Axel Lin 
> ---
> It was sent on https://lkml.org/lkml/2016/5/23/12 .
>  drivers/phy/phy-brcm-sata.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-brcm-sata.c b/drivers/phy/phy-brcm-sata.c
> index 18d6626..8ffc44a 100644
> --- a/drivers/phy/phy-brcm-sata.c
> +++ b/drivers/phy/phy-brcm-sata.c
> @@ -367,7 +367,7 @@ static int brcm_sata_phy_init(struct phy *phy)
>   rc = -ENODEV;
>   };
>  
> - return 0;
> + return rc;
>  }
>  
>  static const struct phy_ops phy_ops = {
> 

[PATCH] timer: Make msleep(0) a nop

[ville . syrjala]

From: Ville Syrjälä 

Thanks to the msecs_to_jiffies()+1 msleep(0) may actually sleep for up
to one jiffy. Presumably the caller should be satisfied if we "sleep"
for 0 jiffies instead of 0-1 jiffies, so let's just turn msleep(0)
into a nop.

This can simplify some callers as they don't have to check for the
0 msecs case themselves anymore. Or if they're not checking for 0,
they might avoid a needless sleep occasionally.

A slight concern might be that someone is calling msleep(0) and
depending on some delay being there. But that can clearly blow up
even without this change, so I'm not overly worried about it.

Cc: Thomas Gleixner 
Cc: John Stultz 
Signed-off-by: Ville Syrjälä 
---
 kernel/time/timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 555670a5143c..1f9ccfccb68f 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1870,7 +1870,7 @@ void __init init_timers(void)
  */
 void msleep(unsigned int msecs)
 {
-   unsigned long timeout = msecs_to_jiffies(msecs) + 1;
+   unsigned long timeout = msecs ? msecs_to_jiffies(msecs) + 1 : 0;
 
while (timeout)
timeout = schedule_timeout_uninterruptible(timeout);
@@ -1884,7 +1884,7 @@ EXPORT_SYMBOL(msleep);
  */
 unsigned long msleep_interruptible(unsigned int msecs)
 {
-   unsigned long timeout = msecs_to_jiffies(msecs) + 1;
+   unsigned long timeout = msecs ? msecs_to_jiffies(msecs) + 1 : 0;
 
while (timeout && !signal_pending(current))
timeout = schedule_timeout_interruptible(timeout);
-- 
2.7.4

Re: [PATCH] phy: sun9i-usb: fix error handling

[Kishon Vijay Abraham I]

On Wednesday 06 July 2016 11:36 AM, Chen-Yu Tsai wrote:
> On Wed, Jul 6, 2016 at 2:00 PM, Christophe JAILLET
>  wrote:
>> This is likely that checking 'phy->hsic_clk' instead of 'phy->clk' is
>> expected here.
>>
>> Signed-off-by: Christophe JAILLET 
> 
> Acked-by: Chen-Yu Tsai 

merged, thanks

-Kishon

[PATCH v5 1/2] Documentation: synopsys-dw-mshc: add binding for resets

[Guodong Xu]

Add resets property to synopsys-dw-mshc bindings. It is intended to
represent the hardware reset signal present internally in some host
controller IC designs.

See Documentation/devicetree/bindings/reset/reset.txt for details.

Signed-off-by: Guodong Xu 
Reviewed-by: Shawn Lin 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 8636f5a..4e00e85 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -39,6 +39,10 @@ Required Properties:
 
 Optional properties:
 
+* resets: phandle + reset specifier pair, intended to represent hardware
+  reset signal present internally in some host controller IC designs.
+  See Documentation/devicetree/bindings/reset/reset.txt for details.
+
 * clocks: from common clock binding: handle to biu and ciu clocks for the
   bus interface unit clock and the card interface unit clock.
 
-- 
1.9.1

[PATCH v5 0/2] mmc: dw_mmc: host controller reset support

[Guodong Xu]

mmc host controller registers may in abnormal state if mmc is used in
bootloader, eg. to load kernel from eMMC. Some controllers cann't
clear their registers when clk is set. They use dedicated reset
logics to do this.

In this patch, a 'resets' property is added into dw_mmc dts
node. When driver does parse_dt and probe, it calls reset API to
triiger 'reset' of dwmmc host controller. When probe error or
remove, it calls reset API to assert it.

Chip vendor's actual reset logics is implemented in reset driver, not
in dw_mmc code.

Please also refer to Documentation/devicetree/bindings/reset/reset.txt

Changelog:
v5:
 * rebase onto https://github.com/jh80chung/dw-mmc
v4:
 * add reset_control_assert() and usleep() before calling _deassert().

Guodong Xu (2):
  Documentation: synopsys-dw-mshc: add binding for resets
  mmc: dw_mmc: add reset support to dwmmc host controller

 .../devicetree/bindings/mmc/synopsys-dw-mshc.txt   |  4 
 drivers/mmc/host/dw_mmc.c  | 23 +-
 include/linux/mmc/dw_mmc.h |  2 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH v5 2/2] mmc: dw_mmc: add reset support to dwmmc host controller

[Guodong Xu]

Dwmmc host controller may in unknown state when entering kernel boot. One
example is when booting from eMMC, bootloader need initialize MMC host
controller into some state so it can read. In order to make sure MMC host
controller in a clean initial state, this reset support is added.

With this patch, a 'resets' property can be added into dw_mmc device
tree node. The hardware logic is: dwmmc host controller IP receives a reset
signal from a 'reset provider' (eg. power management unit). The 'resets'
property points to this reset signal. So, during dwmmc driver probe,
it can use this signal to reset itself.

Refer to [1] for more information.

[1] Documentation/devicetree/bindings/reset/reset.txt

Signed-off-by: Guodong Xu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Zhangfei Gao 
Reviewed-by: Shawn Lin 
---
 drivers/mmc/host/dw_mmc.c  | 23 ++-
 include/linux/mmc/dw_mmc.h |  2 ++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1b719a6..4dff0ee 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2872,6 +2872,13 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
dw_mci *host)
if (!pdata)
return ERR_PTR(-ENOMEM);
 
+   /* find reset controller when exist */
+   pdata->rstc = devm_reset_control_get_optional(dev, NULL);
+   if (IS_ERR(pdata->rstc)) {
+   if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+
/* find out number of slots supported */
of_property_read_u32(np, "num-slots", &pdata->num_slots);
 
@@ -2943,7 +2950,9 @@ int dw_mci_probe(struct dw_mci *host)
 
if (!host->pdata) {
host->pdata = dw_mci_parse_dt(host);
-   if (IS_ERR(host->pdata)) {
+   if (PTR_ERR(host->pdata) == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (IS_ERR(host->pdata)) {
dev_err(host->dev, "platform data not available\n");
return -EINVAL;
}
@@ -2997,6 +3006,12 @@ int dw_mci_probe(struct dw_mci *host)
}
}
 
+   if (!IS_ERR(host->pdata->rstc)) {
+   reset_control_assert(host->pdata->rstc);
+   usleep_range(10, 50);
+   reset_control_deassert(host->pdata->rstc);
+   }
+
setup_timer(&host->cmd11_timer,
dw_mci_cmd11_timer, (unsigned long)host);
 
@@ -3146,6 +3161,9 @@ err_dmaunmap:
if (host->use_dma && host->dma_ops->exit)
host->dma_ops->exit(host);
 
+   if (!IS_ERR(host->pdata->rstc))
+   reset_control_assert(host->pdata->rstc);
+
 err_clk_ciu:
clk_disable_unprepare(host->ciu_clk);
 
@@ -3176,6 +3194,9 @@ void dw_mci_remove(struct dw_mci *host)
if (host->use_dma && host->dma_ops->exit)
host->dma_ops->exit(host);
 
+   if (!IS_ERR(host->pdata->rstc))
+   reset_control_assert(host->pdata->rstc);
+
clk_disable_unprepare(host->ciu_clk);
clk_disable_unprepare(host->biu_clk);
 }
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 83b0edfc..f5af2bd 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_MCI_SLOTS  2
 
@@ -259,6 +260,7 @@ struct dw_mci_board {
/* delay in mS before detecting cards after interrupt */
u32 detect_delay_ms;
 
+   struct reset_control *rstc;
struct dw_mci_dma_ops *dma_ops;
struct dma_pdata *data;
 };
-- 
1.9.1

Re: [PATCH v4 2/2] mmc: dw_mmc: add reset support to dwmmc host controller

[Guodong Xu]

On 11 August 2016 at 18:30, Jaehoon Chung  wrote:
> Hi Guodong,
>
> On 08/11/2016 11:23 AM, Shawn Lin wrote:
>> On 2016/8/10 16:03, Guodong Xu wrote:
>>> Dwmmc host controller may in unknown state when entering kernel boot. One
>>> example is when booting from eMMC, bootloader need initialize MMC host
>>> controller into some state so it can read. In order to make sure MMC host
>>> controller in a clean initial state, this reset support is added.
>>>
>>> With this patch, a 'resets' property can be added into dw_mmc device
>>> tree node. The hardware logic is: dwmmc host controller IP receives a reset
>>> signal from a 'reset provider' (eg. power management unit). The 'resets'
>>> property points to this reset signal. So, during dwmmc driver probe,
>>> it can use this signal to reset itself.
>>>
>>> Refer to [1] for more information.
>>>
>>> [1] Documentation/devicetree/bindings/reset/reset.txt
>>>
>>> Signed-off-by: Guodong Xu 
>>> Signed-off-by: Xinwei Kong 
>>> Signed-off-by: Zhangfei Gao 
>>
>> Looks good to me,
>>
>> Reviewed-by: Shawn Lin 
>
> Could you rebase on https://github.com/jh80chung/dw-mmc.git?
> Otherwise, when i apply your patch, i will rebase.
>

Sure, I rebased.
Sending v5.

-Guodong

> Best Regards,
> Jaehoon Chung
>
>>
>>> ---
>>>  drivers/mmc/host/dw_mmc.c  | 23 ++-
>>>  include/linux/mmc/dw_mmc.h |  2 ++
>>>  2 files changed, 24 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index 32380d5..481d441 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -2915,6 +2915,13 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
>>> dw_mci *host)
>>>  if (!pdata)
>>>  return ERR_PTR(-ENOMEM);
>>>
>>> +/* find reset controller when exist */
>>> +pdata->rstc = devm_reset_control_get_optional(dev, NULL);
>>> +if (IS_ERR(pdata->rstc)) {
>>> +if (PTR_ERR(pdata->rstc) == -EPROBE_DEFER)
>>> +return ERR_PTR(-EPROBE_DEFER);
>>> +}
>>> +
>>>  /* find out number of slots supported */
>>>  of_property_read_u32(np, "num-slots", &pdata->num_slots);
>>>
>>> @@ -2986,7 +2993,9 @@ int dw_mci_probe(struct dw_mci *host)
>>>
>>>  if (!host->pdata) {
>>>  host->pdata = dw_mci_parse_dt(host);
>>> -if (IS_ERR(host->pdata)) {
>>> +if (PTR_ERR(host->pdata) == -EPROBE_DEFER) {
>>> +return -EPROBE_DEFER;
>>> +} else if (IS_ERR(host->pdata)) {
>>>  dev_err(host->dev, "platform data not available\n");
>>>  return -EINVAL;
>>>  }
>>> @@ -3040,6 +3049,12 @@ int dw_mci_probe(struct dw_mci *host)
>>>  }
>>>  }
>>>
>>> +if (!IS_ERR(host->pdata->rstc)) {
>>> +reset_control_assert(host->pdata->rstc);
>>> +usleep_range(10, 50);
>>> +reset_control_deassert(host->pdata->rstc);
>>> +}
>>> +
>>>  setup_timer(&host->cmd11_timer,
>>>  dw_mci_cmd11_timer, (unsigned long)host);
>>>
>>> @@ -3189,6 +3204,9 @@ err_dmaunmap:
>>>  if (host->use_dma && host->dma_ops->exit)
>>>  host->dma_ops->exit(host);
>>>
>>> +if (!IS_ERR(host->pdata->rstc))
>>> +reset_control_assert(host->pdata->rstc);
>>> +
>>>  err_clk_ciu:
>>>  if (!IS_ERR(host->ciu_clk))
>>>  clk_disable_unprepare(host->ciu_clk);
>>> @@ -3221,6 +3239,9 @@ void dw_mci_remove(struct dw_mci *host)
>>>  if (host->use_dma && host->dma_ops->exit)
>>>  host->dma_ops->exit(host);
>>>
>>> +if (!IS_ERR(host->pdata->rstc))
>>> +reset_control_assert(host->pdata->rstc);
>>> +
>>>  if (!IS_ERR(host->ciu_clk))
>>>  clk_disable_unprepare(host->ciu_clk);
>>>
>>> diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
>>> index 83b0edfc..f5af2bd 100644
>>> --- a/include/linux/mmc/dw_mmc.h
>>> +++ b/include/linux/mmc/dw_mmc.h
>>> @@ -17,6 +17,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #define MAX_MCI_SLOTS2
>>>
>>> @@ -259,6 +260,7 @@ struct dw_mci_board {
>>>  /* delay in mS before detecting cards after interrupt */
>>>  u32 detect_delay_ms;
>>>
>>> +struct reset_control *rstc;
>>>  struct dw_mci_dma_ops *dma_ops;
>>>  struct dma_pdata *data;
>>>  };
>>>
>>
>>
>

Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression

[Ye Xiaolong]

On 08/12, Ye Xiaolong wrote:
>On 08/12, Dave Chinner wrote:

[snip]

>>lkp-folk: the patch I've just tested it attached below - can you
>>feed that through your test and see if it fixes the regression?
>>
>
>Hi, Dave
>
>I am verifying your fix patch in lkp environment now, will send the
>result once I get it.
>

Here is the test result.

commit 636b594f38278080db93f2d67d11d31700924f5d
Author: Dave Chinner 
AuthorDate: Fri Aug 12 14:23:44 2016 +0800
Commit: Xiaolong Ye 
CommitDate: Fri Aug 12 14:23:44 2016 +0800

When a write occurs that extends the file, we check to see if we
need to preallocate more delalloc space.  When we do sub-page
writes, the new iomap write path passes a sub-block write length to
the block mapping code.  xfs_iomap_write_delay does not expect to be
pased byte counts smaller than one filesystem block, so it ends up
checking the BMBT on for blocks beyond EOF on every write,
regardless of whether we need to or not. This causes a regression in
aim7 benchmarks as it is full of sub-page writes.

To fix this, clamp the minimum length of a mapping request coming
through xfs_file_iomap_begin() to one filesystem block. This ensures
we are passing the same length to xfs_iomap_write_delay() as we did
when calling through the get_blocks path. This substantially reduces
the amount of lookup load being placed on the BMBT during sub-block
write loads.

Signed-off-by: Dave Chinner 
---
 fs/xfs/xfs_iomap.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 620fc91..5eaace0 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1015,10 +1015,15 @@ xfs_file_iomap_begin(
 * number pulled out of thin air as a best guess for initial
 * testing.
 *
+* xfs_iomap_write_delay() only works if the length passed in is
+* >= one filesystem block. Hence we need to clamp the minimum
+* length we map, too.
+*
 * Note that the values needs to be less than 32-bits wide until
 * the lower level functions are updated.
 */
length = min_t(loff_t, length, 1024 * PAGE_SIZE);
+   length = max_t(loff_t, length, (1 << inode->i_blkbits));
if (xfs_get_extsz_hint(ip)) {
/*
 * xfs_iomap_write_direct() expects the shared lock. It

f0c6bcba74ac51cb  68a9f5e7007c1afa2cf6830b69  636b594f38278080db93f2d67d  
  --  --  
 %stddev %change %stddev %change %stddev
 \  |\  |\  
484435 ±  0% -13.3% 420004 ±  0% -14.0% 416777 ±  0%  
aim7.jobs-per-min
  6491 ±  3% +30.8%   8491 ±  0% +35.7%   8806 ±  1%  
aim7.time.involuntary_context_switches
   376 ±  0% +28.4%484 ±  0% +29.6%488 ±  0%  
aim7.time.system_time
430512 ±  0% -20.1% 343838 ±  0% -19.7% 345708 ±  0%  
aim7.time.voluntary_context_switches
 37.37 ±  0% +15.3%  43.09 ±  0% +16.1%  43.41 ±  0%  
aim7.time.elapsed_time
 37.37 ±  0% +15.3%  43.09 ±  0% +16.1%  43.41 ±  0%  
aim7.time.elapsed_time.max
155184 ±  1%  -2.1% 151864 ±  1%  -2.7% 150937 ±  1%  
aim7.time.minor_page_faults
 0 ±  0%  +Inf% 215412 ±141%  +Inf% 334416 ± 75%  
latency_stats.sum.wait_on_page_bit.__migration_entry_wait.migration_entry_wait.handle_pte_fault.handle_mm_fault.__do_page_fault.do_page_fault.page_fault
 24772 ±  0% -28.6%  17675 ±  0% -26.7%  18149 ±  2%  
vmstat.system.cs
 26816 ±  8% +10.2%  29542 ±  1% +13.3%  30370 ±  1%  
interrupts.CAL:Function_call_interrupts
125122 ± 10% -10.7% 111758 ± 12% -11.1% 111223 ± 11%  
softirqs.SCHED
  3906 ±  0% +28.8%   5032 ±  2% +29.1%   5045 ±  1%  
proc-vmstat.nr_active_file
  3444 ±  5% +41.8%   4884 ±  0% +25.0%   4304 ± 11%  
proc-vmstat.nr_shmem
  4092 ± 14% +61.2%   6595 ±  1% +40.0%   5728 ± 15%  
proc-vmstat.pgactivate
 15627 ±  0% +27.7%  19956 ±  1% +27.4%  19902 ±  0%  
meminfo.Active(file)
 16103 ±  3% +14.3%  18405 ±  8% +11.2%  17900 ±  1%  
meminfo.AnonHugePages
 13777 ±  5% +43.1%  19709 ±  0% +25.0%  17220 ± 11%  
meminfo.Shmem
   1724300 ± 27% -40.5%1025538 ±  1% -41.3%1012868 ±  0%  
sched_debug.cfs_rq:/.load.max
   1724300 ± 27% -40.5%1025538 ±  1% -41.3%1012868 ±  0%  
sched_debug.cpu.load.max
 37.37 ±  0% +15.3%  43.09 ±  0% +16.1%  43.41 ±  0%  
time.elapsed_time
 37.37 ±  0% +15.3%  43.09 ±  0% +16.1%

Re: [PATCH v2] sched/deadline: Fix the intention to re-evalute tick dependency for offline cpu

[kbuild test robot]

Hi Wanpeng,

[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.8-rc1 next-20160811]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Wanpeng-Li/sched-deadline-Fix-the-intention-to-re-evalute-tick-dependency-for-offline-cpu/20160812-162528
config: x86_64-randconfig-x013-201632 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from kernel/sched/sched.h:2,
from kernel/sched/deadline.c:17:
   kernel/sched/deadline.c: In function 'dl_task_timer':
>> kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
>> 'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:139:45: note: in definition of macro 'unlikely'
#  define unlikely(x) (__builtin_constant_p(x) ? !!(x) : 
__branch_check__(x, 0))
^
>> kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
>> 'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:139:53: note: in definition of macro 'unlikely'
#  define unlikely(x) (__builtin_constant_p(x) ? !!(x) : 
__branch_check__(x, 0))
^
>> kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
>> 'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:112:47: note: in definition of macro 
'likely_notrace'
#define likely_notrace(x) __builtin_expect(!!(x), 1)
  ^
   include/linux/compiler.h:139:58: note: in expansion of macro 
'__branch_check__'
#  define unlikely(x) (__builtin_constant_p(x) ? !!(x) : 
__branch_check__(x, 0))
 ^~~~
>> kernel/sched/deadline.c:644:6: note: in expansion of macro 'unlikely'
 if (unlikely(!rq->online))
 ^~~~

vim +644 kernel/sched/deadline.c

   638   */
   639  if (!task_on_rq_queued(p)) {
   640  replenish_dl_entity(dl_se, dl_se);
   641  goto unlock;
   642  }
   643  
 > 644  if (unlikely(!rq->online))
   645  replenish_dl_entity(dl_se, dl_se);
   646  else {
   647  enqueue_task_dl(rq, p, ENQUEUE_REPLENISH);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [RFC 2/4] dma-buf/fence: kerneldoc: remove spurious section header

[Daniel Vetter]

On Thu, Aug 11, 2016 at 04:17:58PM +0530, Sumit Semwal wrote:
> Commit e941759c74a44d6ac2eed21bb0a38b21fe4559e2 ("fence: dma-buf
> cross-device synchronization (v18)") had a spurious kerneldoc section
> header that caused Sphinx to complain. Fix it.
> 
> Fixes: e941759c74a4 ("fence: dma-buf cross-device synchronization (v18)")
> 
> Signed-off-by: Sumit Semwal 

On patches 1&2 Reviewed-by: Daniel Vetter 


> ---
>  include/linux/fence.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/fence.h b/include/linux/fence.h
> index 5aa95eb886f7..5de89dab0013 100644
> --- a/include/linux/fence.h
> +++ b/include/linux/fence.h
> @@ -60,7 +60,7 @@ struct fence_cb;
>   * implementer of the fence for its own purposes. Can be used in different
>   * ways by different fence implementers, so do not rely on this.
>   *
> - * *) Since atomic bitops are used, this is not guaranteed to be the case.
> + * Since atomic bitops are used, this is not guaranteed to be the case.
>   * Particularly, if the bit was set, but fence_signal was called right
>   * before this bit was set, it would have been able to set the
>   * FENCE_FLAG_SIGNALED_BIT, before enable_signaling was called.
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2] sched/deadline: Fix the intention to re-evalute tick dependency for offline cpu

[kbuild test robot]

Hi Wanpeng,

[auto build test WARNING on tip/sched/core]
[also build test WARNING on v4.8-rc1 next-20160811]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Wanpeng-Li/sched-deadline-Fix-the-intention-to-re-evalute-tick-dependency-for-offline-cpu/20160812-162528
config: x86_64-randconfig-x019-201632 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/capability.h:16,
from include/linux/capability.h:15,
from include/linux/sched.h:15,
from kernel/sched/sched.h:2,
from kernel/sched/deadline.c:17:
   kernel/sched/deadline.c: In function 'dl_task_timer':
   kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/sched/deadline.c:644:2: note: in expansion of macro 'if'
 if (unlikely(!rq->online))
 ^~
   kernel/sched/deadline.c:644:6: note: in expansion of macro 'unlikely'
 if (unlikely(!rq->online))
 ^~~~
   kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/sched/deadline.c:644:2: note: in expansion of macro 'if'
 if (unlikely(!rq->online))
 ^~
   kernel/sched/deadline.c:644:6: note: in expansion of macro 'unlikely'
 if (unlikely(!rq->online))
 ^~~~
   kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/sched/deadline.c:644:2: note: in expansion of macro 'if'
 if (unlikely(!rq->online))
 ^~
   include/linux/compiler.h:125:14: note: in expansion of macro 'likely_notrace'
   __r = likely_notrace(x);   \
 ^~
   include/linux/compiler.h:139:58: note: in expansion of macro 
'__branch_check__'
#  define unlikely(x) (__builtin_constant_p(x) ? !!(x) : 
__branch_check__(x, 0))
 ^~~~
   kernel/sched/deadline.c:644:6: note: in expansion of macro 'unlikely'
 if (unlikely(!rq->online))
 ^~~~
   kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/sched/deadline.c:644:2: note: in expansion of macro 'if'
 if (unlikely(!rq->online))
 ^~
   kernel/sched/deadline.c:644:6: note: in expansion of macro 'unlikely'
 if (unlikely(!rq->online))
 ^~~~
   kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> kernel/sched/deadline.c:644:2: note: in expansion of macro 'if'
 if (unlikely(!rq->online))
 ^~
   kernel/sched/deadline.c:644:6: note: in expansion of macro 'unlikely'
 if (unlikely(!rq->online))
 ^~~~
   kernel/sched/deadline.c:644:18: error: 'struct rq' has no member named 
'online'
 if (unlikely(!rq->online))
 ^
   include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(con

Re: [v10 PATCH 2/5] phy: Add USB Type-C PHY driver for rk3399

[Kishon Vijay Abraham I]

Hi,

On Wednesday 10 August 2016 05:02 AM, Chris Zhong wrote:
> Add a PHY provider driver for the rk3399 SoC Type-c PHY. The USB
> Type-C PHY is designed to support the USB3 and DP applications. The
> PHY basically has two main components: USB3 and DisplyPort. USB3
> operates in SuperSpeed mode and the DP can operate at RBR, HBR and
> HBR2 data rates. Hence, create 2 PHY deivces, the phy[0] for DP,
> and phy[1] for USB3.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Kever Yang 
> 
> ---
> 
> Changes in v10:
> - do not control dp select and hpd config in phy driver
> 
> Changes in v9:
> - the new_mode should be int not u8
> - move mutex_lock(&tcphy->lock); to earlier place. in
>   rockchip_usb3_phy_power_off
> - better mutex lock for phy mode and flip
> - split the Type-C PHY into two PHYs: USB3 and DP
> 
> Changes in v8:
> - set the default cable id to EXTCON_USB_HOST
> - optimization Error log
> 
> Changes in v7:
> - support new API of extcon
> 
> Changes in v6:
> - delete the support of PIN_ASSIGN_A/B
> - set the default mode to MODE_DFP_USB
> - disable DP PLL at USB3 only mode
> 
> Changes in v5:
> - support get property from extcon
> - remove PIN ASSIGN A/B support
> 
> Changes in v4:
> - select EXTCON
> - use phy framework to control the USB3 and DP function
> - rename PIN_MAP_ to PIN_ASSIGN_
> 
> Changes in v3:
> - remove the phy framework(Kishon Vijay Abraham I)
> - add parentheses around the macro
> - use a single space between type and name
> - add spaces after opening and before closing braces.
> - use u16 for register value
> - remove type-c phy header file
> - CodingStyle optimization
> - use some cable extcon to get type-c port information
> - add a extcon to notify Display Port
> 
> Changes in v2:
> - select RESET_CONTROLLER
> - alphabetic order
> - modify some spelling mistakes
> - make mode cleaner
> - use bool for enable/disable
> - check all of the return value
> - return a better err number
> - use more readx_poll_timeout()
> - clk_disable_unprepare(tcphy->clk_ref);
> - remove unuse functions, rockchip_typec_phy_power_on/off
> - remove unnecessary typecast from void *
> - use dts node to distinguish between phys.
> 
> Changes in v1:
> - update the licence note
> - init core clock to 50MHz
> - use extcon API
> - remove unused global
> - add some comments for magic num
> - change usleep_range(1000, 2000) tousleep_range(1000, 1050)
> - remove __func__ from dev_err
> - return err number when get clk failed
> - remove ADDR_ADJ define
> - use devm_clk_get(&pdev->dev, "tcpdcore")
> 
>  drivers/phy/Kconfig  |   9 +
>  drivers/phy/Makefile |   1 +
>  drivers/phy/phy-rockchip-typec.c | 981 
> +++
>  3 files changed, 991 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-typec.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 26566db..83706a5 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -351,6 +351,15 @@ config PHY_ROCKCHIP_DP
>   help
> Enable this to support the Rockchip Display Port PHY.
>  
> +config PHY_ROCKCHIP_TYPEC
> + tristate "Rockchip TYPEC PHY Driver"
> + depends on ARCH_ROCKCHIP && OF

please also include COMPILE_TEST if ARCH_ROCKCHIP is not selected.
> + select EXTCON
> + select GENERIC_PHY
> + select RESET_CONTROLLER
> + help
> +   Enable this to support the Rockchip USB TYPEC PHY.
> +
>  config PHY_ST_SPEAR1310_MIPHY
>   tristate "ST SPEAR1310-MIPHY driver"
>   select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 24596a9..91fa413 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += 
> phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
>  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
>  obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
> +obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
>  obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>  obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-typec.c 
> b/drivers/phy/phy-rockchip-typec.c
> new file mode 100644
> index 000..8ec0df4
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-typec.c
> @@ -0,0 +1,981 @@
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong 
> + * Kever Yang 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License fo

Donation of $ 1.5 million Dollars

[Chris Colin & Weir]

My wife and I have awarded you with a donation of $ 1.5 million Dollars
from part of our Jackpot Lottery of 161,653,000 Million Pounds, send your
name,address, phone for claims.

View http://www.bbc.co.uk/news/uk-scotland-glasgow-west-18801698

We await your earliest response and God Bless you.

Best of luck.

Chris Colin & Weir

Reply E-mail: chriscolin10...@gmail.com

Re: [Patch v4 9/9] arm64: Update device tree for Layerscape SoCs

[Borislav Petkov]

On Tue, Aug 09, 2016 at 02:59:39PM -0700, York Sun wrote:
> Add DDR memory controller nodes to enable EDAC driver.
> 
> Signed-off-by: York Sun 
> 
> ---
> Change log
>   v4: no change
>   v3: no change
>   v2: no change
> 
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |  7 +++
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 14 ++
>  2 files changed, 21 insertions(+)

This needs an ACK from DT people.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

[PATCH] time: alarmtimer: Add the trcepoints for alarmtimer

[Baolin Wang]

For system debugging, we usually want to know who sets one alarm timer, the
time of the timer, when the timer started and fired and so on.

Thus adding tracepoints can help us trace the alarmtimer information.

Signed-off-by: Baolin Wang 
---
 include/trace/events/alarmtimer.h |  135 +
 kernel/time/alarmtimer.c  |   21 +-
 2 files changed, 153 insertions(+), 3 deletions(-)
 create mode 100644 include/trace/events/alarmtimer.h

diff --git a/include/trace/events/alarmtimer.h 
b/include/trace/events/alarmtimer.h
new file mode 100644
index 000..69f69b6
--- /dev/null
+++ b/include/trace/events/alarmtimer.h
@@ -0,0 +1,135 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM alarmtimer
+
+#if !defined(_TRACE_ALARMTIMER_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_ALARMTIMER_H
+
+#include 
+#include 
+#include 
+
+#define show_alarm_type(type)  __print_flags(type, " | ",  \
+   { 1 << ALARM_REALTIME, "ALARM_REALTIME" },  \
+   { 1 << ALARM_BOOTTIME, "ALARM_BOOTTIME" })
+
+DECLARE_EVENT_CLASS(alarm_setting,
+
+   TP_PROTO(struct rtc_time *rtc_time, int flag),
+
+   TP_ARGS(rtc_time, flag),
+
+   TP_STRUCT__entry(
+   __field(unsigned int, second)
+   __field(unsigned int, minute)
+   __field(unsigned int, hour)
+   __field(unsigned int, day)
+   __field(unsigned int, mon)
+   __field(unsigned int, year)
+   __field(unsigned int, alarm_type)
+   ),
+
+   TP_fast_assign(
+   __entry->second = rtc_time->tm_sec;
+   __entry->minute = rtc_time->tm_min;
+   __entry->hour = rtc_time->tm_hour;
+   __entry->day = rtc_time->tm_mday;
+   __entry->mon = rtc_time->tm_mon;
+   __entry->year = rtc_time->tm_year;
+   __entry->alarm_type = flag;
+   ),
+
+   TP_printk("alarmtimer type:%s expires time: %u-%u-%u %u:%u:%u",
+ show_alarm_type((1 << __entry->alarm_type)),
+ __entry->year + 1900,
+ __entry->mon + 1,
+ __entry->day,
+ __entry->hour,
+ __entry->minute,
+ __entry->second
+   )
+);
+
+DEFINE_EVENT(alarm_setting, alarmtimer_suspend,
+
+   TP_PROTO(struct rtc_time *time, int flag),
+
+   TP_ARGS(time, flag)
+);
+
+DECLARE_EVENT_CLASS(alarm_processing,
+
+   TP_PROTO(struct alarm *alarm, char *process_name),
+
+   TP_ARGS(alarm, process_name),
+
+   TP_STRUCT__entry(
+   __field(unsigned long long, expires)
+   __field(unsigned int, second)
+   __field(unsigned int, minute)
+   __field(unsigned int, hour)
+   __field(unsigned int, day)
+   __field(unsigned int, mon)
+   __field(unsigned int, year)
+   __field(unsigned int, alarm_type)
+   __string(name, process_name)
+   ),
+
+   TP_fast_assign(
+   __entry->expires = alarm->node.expires.tv64;
+   __entry->second = rtc_ktime_to_tm(alarm->node.expires).tm_sec;
+   __entry->minute = rtc_ktime_to_tm(alarm->node.expires).tm_min;
+   __entry->hour = rtc_ktime_to_tm(alarm->node.expires).tm_hour;
+   __entry->day = rtc_ktime_to_tm(alarm->node.expires).tm_mday;
+   __entry->mon = rtc_ktime_to_tm(alarm->node.expires).tm_mon;
+   __entry->year = rtc_ktime_to_tm(alarm->node.expires).tm_year;
+   __entry->alarm_type = alarm->type;
+   __assign_str(name, process_name);
+   ),
+
+   TP_printk("process:%s alarmtimer type:%s expires:%llu "
+ "state:%s time: %u-%u-%u %u:%u:%u",
+ __get_str(name),
+ show_alarm_type((1 << __entry->alarm_type)),
+ __entry->expires,
+ strcmp(__get_str(name), "null") ? "fired" : "not fired",
+ __entry->year + 1900,
+ __entry->mon + 1,
+ __entry->day,
+ __entry->hour,
+ __entry->minute,
+ __entry->second
+   )
+);
+
+DEFINE_EVENT(alarm_processing, alarmtimer_fired,
+
+   TP_PROTO(struct alarm *alarm, char *process_name),
+
+   TP_ARGS(alarm, process_name)
+);
+
+DEFINE_EVENT(alarm_processing, alarmtimer_start,
+
+   TP_PROTO(struct alarm *alarm, char *process_name),
+
+   TP_ARGS(alarm, process_name)
+);
+
+DEFINE_EVENT(alarm_processing, alarmtimer_restart,
+
+   TP_PROTO(struct alarm *alarm, char *process_name),
+
+   TP_ARGS(alarm, process_name)
+);
+
+DEFINE_EVENT(alarm_processing, alarmtimer_cancel,
+
+   TP_PROTO(struct alarm *alarm, char *process_name),
+
+   TP_ARGS(alarm, process_name)
+);
+
+#endif /* _TRACE_ALARMTIMER_H */
+
+/* This part must be outside protection */
+#include 
diff --git a/kernel/time/alarmtimer.c b/

Re: [Patch v4 8/9] driver/edac/layerscape_edac: Add Layerscape EDAC support

[Borislav Petkov]

On Tue, Aug 09, 2016 at 02:55:45PM -0700, York Sun wrote:
> Add DDR EDAC for ARM-based compatible controllers. Both big-endian
> and little-endian are supported, as specified in device tree.
> 
> Signed-off-by: York Sun 
> 
> ---
> Change log
>   v4: Drop adding atomic_scrub() for arm64
>   Drop NO_IRQ
>   v3: no change
>   v2: Create new driver using shared DDR object
> 
>  arch/arm64/Kconfig.platforms   |  1 +
>  drivers/edac/Kconfig   |  7 +
>  drivers/edac/Makefile  |  3 ++
>  drivers/edac/fsl_ddr_edac.c|  2 +-
>  drivers/edac/layerscape_edac.c | 67 
> ++
>  5 files changed, 79 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/edac/layerscape_edac.c
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 7ef1d05..185a215 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -41,6 +41,7 @@ config ARCH_EXYNOS
>  
>  config ARCH_LAYERSCAPE
>   bool "ARMv8 based Freescale Layerscape SoC family"
> + select EDAC_SUPPORT
>   help
> This enables support for the Freescale Layerscape SoC family.
>  
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 6ca7474..f1ac4e2 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -258,6 +258,13 @@ config EDAC_MPC85XX
> Support for error detection and correction on the Freescale
> MPC8349, MPC8560, MPC8540, MPC8548, T4240
>  
> +config EDAC_LAYERSCAPE
> + tristate "Freescale Layerscape DDR"
> + depends on EDAC_MM_EDAC && ARCH_LAYERSCAPE
> + help
> +   Support for error detection and correction on Freescale memory
> +   controllers on Layerscape SoCs.
> +
>  config EDAC_MV64X60
>   tristate "Marvell MV64x60"
>   depends on EDAC_MM_EDAC && MV64X60
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ee047a4..910dc83 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -54,6 +54,9 @@ obj-$(CONFIG_EDAC_PASEMI)   += pasemi_edac.o
>  mpc85xx_edac_mod-y   := fsl_ddr_edac.o mpc85xx_edac.o
>  obj-$(CONFIG_EDAC_MPC85XX)   += mpc85xx_edac_mod.o
>  
> +layerscape_edac_mod-y:= fsl_ddr_edac.o 
> layerscape_edac.o
> +obj-$(CONFIG_EDAC_LAYERSCAPE)+= layerscape_edac_mod.o
> +
>  obj-$(CONFIG_EDAC_MV64X60)   += mv64x60_edac.o
>  obj-$(CONFIG_EDAC_CELL)  += cell_edac.o
>  obj-$(CONFIG_EDAC_PPC4XX)+= ppc4xx_edac.o
> diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
> index d8ce1f6..afade14 100644
> --- a/drivers/edac/fsl_ddr_edac.c
> +++ b/drivers/edac/fsl_ddr_edac.c
> @@ -26,6 +26,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include "edac_module.h"
>  #include "edac_core.h"
>  #include "fsl_ddr_edac.h"
> @@ -478,7 +479,6 @@ int fsl_mc_err_probe(struct platform_device *op)
>  
>   pdata = mci->pvt_info;
>   pdata->name = "fsl_mc_err";
> - pdata->irq = NO_IRQ;
>   mci->pdev = &op->dev;
>   pdata->edac_idx = edac_mc_idx++;
>   dev_set_drvdata(mci->pdev, mci);
> diff --git a/drivers/edac/layerscape_edac.c b/drivers/edac/layerscape_edac.c
> new file mode 100644
> index 000..6ba771d
> --- /dev/null
> +++ b/drivers/edac/layerscape_edac.c
> @@ -0,0 +1,67 @@
> +/*
> + * Freescale Memory Controller kernel module
> + *
> + * Derived from mpc85xx_edac.c

Up to here is fine...

> + * Author: Dave Jiang 
> + *
> + * 2006-2007 (c) MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */

... but I'm not sure about this. This is a new driver which you are
adding and not Dave. You probably could say

"Author: York Sun 
(c) NXP ...

Derived from mpc85xx_edac.c, (c) Montavista ..."

so that we have both copyright tags in there.

> +
> +#include "edac_core.h"
> +#include "fsl_ddr_edac.h"
> +
> +static const struct of_device_id fsl_ddr_mc_err_of_match[] = {
> + { .compatible = "fsl,qoriq-memory-controller", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, fsl_ddr_mc_err_of_match);
> +
> +static struct platform_driver fsl_ddr_mc_err_driver = {
> + .probe = fsl_mc_err_probe,
> + .remove = fsl_mc_err_remove,
> + .driver = {
> + .name = "fsl_ddr_mc_err",
> + .of_match_table = fsl_ddr_mc_err_of_match,
> + },
> +};
> +
> +static int __init fsl_ddr_mc_init(void)
> +{
> + int res = 0;

No need to init it since it is going to be overwritten anyway.

> +
> + /* make sure error reporting method is sane */
> + switch (edac_op_state) {
> + case EDAC_OPSTATE_POLL:
> + case EDAC_OPSTATE_INT:
> + break;
> + default:
> + edac_op_state = EDAC_OPSTATE_INT;
> + break;
> + }
> +
> + res = platform_driver_register(&fsl_ddr_mc_e

Re: [PATCH v5 0/2] mmc: dw_mmc: host controller reset support

[Jaehoon Chung]

Hi Guodong,

On 08/12/2016 05:51 PM, Guodong Xu wrote:
> mmc host controller registers may in abnormal state if mmc is used in
> bootloader, eg. to load kernel from eMMC. Some controllers cann't
> clear their registers when clk is set. They use dedicated reset
> logics to do this.
> 
> In this patch, a 'resets' property is added into dw_mmc dts
> node. When driver does parse_dt and probe, it calls reset API to
> triiger 'reset' of dwmmc host controller. When probe error or
> remove, it calls reset API to assert it.
> 
> Chip vendor's actual reset logics is implemented in reset driver, not
> in dw_mmc code.
> 
> Please also refer to Documentation/devicetree/bindings/reset/reset.txt
> 
> Changelog:
> v5:
>  * rebase onto https://github.com/jh80chung/dw-mmc
> v4:
>  * add reset_control_assert() and usleep() before calling _deassert().
> 
> Guodong Xu (2):
>   Documentation: synopsys-dw-mshc: add binding for resets
>   mmc: dw_mmc: add reset support to dwmmc host controller

Applied on my dw-mmc tree. Thanks!

Best Regards,
Jaehoon Chung

> 
>  .../devicetree/bindings/mmc/synopsys-dw-mshc.txt   |  4 
>  drivers/mmc/host/dw_mmc.c  | 23 
> +-
>  include/linux/mmc/dw_mmc.h |  2 ++
>  3 files changed, 28 insertions(+), 1 deletion(-)
> 

Re: [PATCH] regulator: Add LTC3676 support

[Mark Brown]

On Thu, Aug 11, 2016 at 01:48:21PM -0700, Tim Harvey wrote:

> regulators must have a non-null ops field or they will fail
> registration so I can't just not assign it. What would be an
> appropriate ops structure for a always-on fixed regulator?

OK, empty is fine there.


signature.asc
Description: PGP signature

[GIT PULL] Please pull powerpc/linux.git powerpc-4.8-3 tag

[Michael Ellerman]

Hi Linus,

Please pull some powerpc fixes for 4.8:

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.8-3

for you to fetch changes up to ca49e64f0cb1368fc666a53b16b45d4505763d9c:

  selftests/powerpc: Specify we expect to build with std=gnu99 (2016-08-10 
23:21:37 +1000)


powerpc fixes for 4.8 #3

 - powerpc/vdso: Fix build rules to rebuild vdsos correctly from Nicholas Piggin
 - powerpc/ptrace: Fix coredump since ptrace TM changes from Cyril Bur
 - powerpc/32: Fix csum_partial_copy_generic() from Christophe Leroy
 - cxl: Set psl_fir_cntl to production environment value from Frederic Barrat
 - powerpc/eeh: Switch to conventional PCI address output in EEH log from 
Guilherme G. Piccoli
 - cxl: Use fixed width predefined types in data structure. from Philippe 
Bergheaud
 - powerpc/vdso: Add missing include file from Guenter Roeck
 - powerpc: Fix unused function warning 'lmb_to_memblock' from Alastair D'Silva
 - powerpc/powernv/ioda: Fix TCE invalidate to work in real mode again from 
Alexey Kardashevskiy
 - powerpc/cell: Add missing error code in spufs_mkgang() from Dan Carpenter
 - crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading from 
Anton Blanchard
 - powerpc/pasemi: Fix coherent_dma_mask for dma engine from Darren Stevens

Benjamin Herrenschmidt:
 - powerpc/32: Fix crash during static key init
 - powerpc: Update obsolete comment in setup_32.c about early_init()
 - powerpc: Print the kernel load address at the end of prom_init()
 - powerpc/pnv/pci: Fix incorrect PE reservation attempt on some 64-bit BARs
 - powerpc/xics: Properly set Edge/Level type and enable resend

Mahesh Salgaonkar:
 - powerpc/book3s: Fix MCE console messages for unrecoverable MCE.
 - powerpc/powernv: Fix MCE handler to avoid trashing CR0/CR1 registers.
 - powerpc/powernv: Move IDLE_STATE_ENTER_SEQ macro to cpuidle.h
 - powerpc/powernv: Load correct TOC pointer while waking up from winkle.

Andrew Donnellan:
 - cxl: Fix sparse warnings
 - cxl: Fix NULL dereference in cxl_context_init() on PowerVM guests

Michael Ellerman:
 - selftests/powerpc: Specify we expect to build with std=gnu99
 - powerpc/Makefile: Use cflags-y/aflags-y for setting endian options
 - powerpc/pci: Fix endian bug in fixed PHB numbering


Alastair D'Silva (1):
  powerpc: Fix unused function warning 'lmb_to_memblock'

Alexey Kardashevskiy (1):
  powerpc/powernv/ioda: Fix TCE invalidate to work in real mode again

Andrew Donnellan (2):
  cxl: Fix NULL dereference in cxl_context_init() on PowerVM guests
  cxl: Fix sparse warnings

Anton Blanchard (1):
  crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading

Benjamin Herrenschmidt (5):
  powerpc/xics: Properly set Edge/Level type and enable resend
  powerpc/pnv/pci: Fix incorrect PE reservation attempt on some 64-bit BARs
  powerpc: Print the kernel load address at the end of prom_init()
  powerpc: Update obsolete comment in setup_32.c about early_init()
  powerpc/32: Fix crash during static key init

Christophe Leroy (1):
  powerpc/32: Fix csum_partial_copy_generic()

Cyril Bur (1):
  powerpc/ptrace: Fix coredump since ptrace TM changes

Dan Carpenter (1):
  powerpc/cell: Add missing error code in spufs_mkgang()

Darren Stevens (1):
  powerpc/pasemi: Fix coherent_dma_mask for dma engine

Frederic Barrat (1):
  cxl: Set psl_fir_cntl to production environment value

Guenter Roeck (1):
  powerpc/vdso: Add missing include file

Guilherme G. Piccoli (1):
  powerpc/eeh: Switch to conventional PCI address output in EEH log

Mahesh Salgaonkar (4):
  powerpc/powernv: Load correct TOC pointer while waking up from winkle.
  powerpc/powernv: Move IDLE_STATE_ENTER_SEQ macro to cpuidle.h
  powerpc/powernv: Fix MCE handler to avoid trashing CR0/CR1 registers.
  powerpc/book3s: Fix MCE console messages for unrecoverable MCE.

Michael Ellerman (3):
  powerpc/pci: Fix endian bug in fixed PHB numbering
  powerpc/Makefile: Use cflags-y/aflags-y for setting endian options
  selftests/powerpc: Specify we expect to build with std=gnu99

Nicholas Piggin (1):
  powerpc/vdso: Fix build rules to rebuild vdsos correctly

Philippe Bergheaud (1):
  cxl: Use fixed width predefined types in data structure.

 arch/powerpc/Makefile   | 22 
 arch/powerpc/crypto/crc32c-vpmsum_glue.c|  3 +-
 arch/powerpc/include/asm/cpuidle.h  | 13 +
 arch/powerpc/include/asm/feature-fixups.h   |  1 +
 arch/powerpc/include/asm/switch_to.h|  8 ---
 arch/powerpc/include/asm/xics.h |  2 +
 arch/powerpc/kernel/eeh.c  

Re: [PATCH v4 9/9] arm64: dts: mediatek: Add Video Decoder for MT8173

[Tiffany Lin]

Hi Matthias,

On Thu, 2016-08-11 at 17:44 +0200, Matthias Brugger wrote:
> 
> On 10/08/16 16:48, Tiffany Lin wrote:
> > Add video decoder node for MT8173
> >
> > Signed-off-by: Tiffany Lin 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi |   44 
> > ++
> >  1 file changed, 44 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index 10f638f..2872cd7 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -974,6 +974,50 @@
> > #clock-cells = <1>;
> > };
> >
> > +   vcodec_dec: vcodec@1600 {
> > +   compatible = "mediatek,mt8173-vcodec-dec";
> > +   reg = <0 0x1600 0 0x100>,   /* VDEC_SYS */
> > + <0 0x1602 0 0x1000>,  /* VDEC_MISC */
> > + <0 0x16021000 0 0x800>,   /* VDEC_LD */
> > + <0 0x16021800 0 0x800>,   /* VDEC_TOP */
> > + <0 0x16022000 0 0x1000>,  /* VDEC_CM */
> > + <0 0x16023000 0 0x1000>,  /* VDEC_AD */
> > + <0 0x16024000 0 0x1000>,  /* VDEC_AV */
> > + <0 0x16025000 0 0x1000>,  /* VDEC_PP */
> > + <0 0x16026800 0 0x800>,   /* VDEC_HWD */
> > + <0 0x16027000 0 0x800>,   /* VDEC_HWQ */
> > + <0 0x16027800 0 0x800>,   /* VDEC_HWB */
> > + <0 0x16028400 0 0x400>;   /* VDEC_HWG */
> > +   interrupts = ;
> > +   mediatek,larb = <&larb1>;
> > +   iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>,
> > +<&iommu M4U_PORT_HW_VDEC_PP_EXT>,
> > +<&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>,
> > +<&iommu M4U_PORT_HW_VDEC_PRED_RD_EXT>,
> > +<&iommu M4U_PORT_HW_VDEC_PRED_WR_EXT>,
> > +<&iommu M4U_PORT_HW_VDEC_UFO_EXT>,
> > +<&iommu M4U_PORT_HW_VDEC_VLD_EXT>,
> > +<&iommu M4U_PORT_HW_VDEC_VLD2_EXT>;
> > +   mediatek,vpu = <&vpu>;
> > +   power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
> > +   clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>,
> > +<&topckgen CLK_TOP_UNIVPLL_D2>,
> > +<&topckgen CLK_TOP_CCI400_SEL>,
> > +<&topckgen CLK_TOP_VDEC_SEL>,
> > +<&topckgen CLK_TOP_VCODECPLL>,
> > +<&apmixedsys CLK_APMIXED_VENCPLL>,
> > +<&topckgen CLK_TOP_VENC_LT_SEL>,
> > +<&topckgen CLK_TOP_VCODECPLL_370P5>;
> > +   clock-names = "vcodecpll",
> > + "univpll_d2",
> > + "clk_cci400_sel",
> > + "vdec_sel",
> > + "vdecpll",
> > + "vencpll",
> > + "venc_lt_sel",
> > + "vdec_bus_clk_src";
> > +   };
> > +
> 
> Shouldn't we set here:
> status = "disabled";
> 
> To save power on headless systems?
> 
We only power on when there is at least one decode instance created.
In this case, do we need "status = "disabled";" here?
I see some other device nodes in dtsi do not add this.
Sorry, I am just confused when should we add status for device node.


best regards,
Tiffany

> Regards,
> Matthias
> 
> > larb1: larb@1601 {
> > compatible = "mediatek,mt8173-smi-larb";
> > reg = <0 0x1601 0 0x1000>;
> >

Re: [PATCH v1] x86/power/64: Restore processor state before using per-cpu variables

[Jiri Kosina]

On Fri, 12 Aug 2016, Jiri Kosina wrote:

> One thing is still beyond me though ... how the heck this doesn't happen 
> without DEBUG_LOCK_ALLOC? The percpu area pointer should be corrupted 
> nevertheless, shouldn't it?

The reason is that turning DEBUG_LOCK_ALLOC changing 
trace_suspend_resume() from

810c7280 :
810c7280:   55  push   %rbp
810c7281:   48 89 e5mov%rsp,%rbp
810c7284:   41 56   push   %r14
810c7286:   41 55   push   %r13
810c7288:   41 54   push   %r12
810c728a:   53  push   %rbx
810c728b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
810c7290:   65 8b 05 59 2f f4 7emov
%gs:0x7ef42f59(%rip),%eax# a1f0 
810c7297:   89 c0   mov%eax,%eax
810c7299:   48 0f a3 05 9f 2f c4bt %rax,0xc42f9f(%rip)  
  # 81d0a240 <__cpu_online_mask>

to

810ad150 :
810ad150:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
810ad155:   c3  retq   
810ad156:   65 8b 05 93 d0 f5 7emov
%gs:0x7ef5d093(%rip),%eax# a1f0 
810ad15d:   89 c0   mov%eax,%eax
810ad15f:   48 0f a3 05 59 0b c4bt %rax,0xc40b59(%rip)  
  # 81cedcc0 <__cpu_online_mask>
810ad166:   00

IOW, with the config change, trace_suspend_resume() returns immediately 
without trying to get the current SMP id. And it's because of 
DEBUG_LOCK_ALLOC implies LOCKDEP, and that does this to __DECLARE_TRACE()

 * When lockdep is enabled, we make sure to always do the RCU portions 
of
 * the tracepoint code, regardless of whether tracing is on. However,
 * don't check if the condition is false, due to interaction with idle
 * instrumentation. This lets us find RCU issues triggered with 
tracepoints
 * even when this tracepoint is off. This code has no purpose other than
 * poking RCU a bit.
 */
#define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) 
\
extern struct tracepoint __tracepoint_##name;   
\
static inline void trace_##name(proto)  
\
{   
\
if (static_key_false(&__tracepoint_##name.key)) 
\
__DO_TRACE(&__tracepoint_##name,
\
TP_PROTO(data_proto),   
\
TP_ARGS(data_args), 
\
TP_CONDITION(cond),,);  
\
if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { 
\
rcu_read_lock_sched_notrace();  
\

rcu_dereference_sched(__tracepoint_##name.funcs);\
rcu_read_unlock_sched_notrace();
\
}   
\
} 

That's pretty nasty, as turning LOCKDEP on has sideffects on the code 
that'd normally not be expected to be run at all (tracepoint off).

Oh well.

Thanks again,

-- 
Jiri Kosina
SUSE Labs

[PATCH v3] sched/deadline: Fix the intention to re-evalute tick dependency for offline cpu

[Wanpeng Li]

From: Wanpeng Li 

The dl task will be replenished after dl task timer fire and start a 
new period. It will be enqueued and to re-evaluate its dependency on 
the tick in order to restart it. However, if cpu is hot-unplug, 
irq_work_queue will splash since the target cpu is offline.

As a result:

WARNING: CPU: 2 PID: 0 at kernel/irq_work.c:69 irq_work_queue_on+0xad/0xe0
Call Trace:
 dump_stack+0x99/0xd0
 __warn+0xd1/0xf0
 warn_slowpath_null+0x1d/0x20
 irq_work_queue_on+0xad/0xe0
 tick_nohz_full_kick_cpu+0x44/0x50
 tick_nohz_dep_set_cpu+0x74/0xb0
 enqueue_task_dl+0x226/0x480
 activate_task+0x5c/0xa0
 dl_task_timer+0x19b/0x2c0
 ? push_dl_task.part.31+0x190/0x190
  
This can be triggered by hot-unplug the full dynticks cpu which dl 
task is running on. 

We enqueue the dl task on the offline CPU, because we need to do 
replenish for start_dl_timer(). So, as Juri pointed out, we would 
need to do is calling replenish_dl_entity() directly, instead of 
enqueue_task_dl(). pi_se shouldn't be a problem as the task shouldn't 
be boosted if it was throttled.

This patch fix it by just replenish dl entity to avoid the intention 
to re-evaluate tick dependency if the cpu is offline.

Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Juri Lelli 
Cc: Luca Abeni 
Cc: Frederic Weisbecker 
Signed-off-by: Wanpeng Li 
---
v2 -> v3:
 * move rq->online check under CONFIG_SMP
v1 -> v2:
 * replenish dl entity

 kernel/sched/deadline.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d091f4a..ce0fb00 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -641,6 +641,11 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
goto unlock;
}
 
+#ifdef CONFIG_SMP
+   if (unlikely(!rq->online))
+   goto offline;
+#endif
+
enqueue_task_dl(rq, p, ENQUEUE_REPLENISH);
if (dl_task(rq->curr))
check_preempt_curr_dl(rq, p, 0);
@@ -648,6 +653,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
resched_curr(rq);
 
 #ifdef CONFIG_SMP
+offline:
/*
 * Perform balancing operations here; after the replenishments.  We
 * cannot drop rq->lock before this, otherwise the assertion in
@@ -659,6 +665,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
 * XXX figure out if select_task_rq_dl() deals with offline cpus.
 */
if (unlikely(!rq->online)) {
+   replenish_dl_entity(dl_se, dl_se);
lockdep_unpin_lock(&rq->lock, rf.cookie);
rq = dl_task_offline_migration(rq, p);
rf.cookie = lockdep_pin_lock(&rq->lock);
-- 
1.9.1

[PATCH] mfd: arizona: Add sensible return value to some error paths

[Charles Keepax]

There are some cases in arizona_dev_init, such as where we don't
recognise the chip ID, in which we head to the error path without
setting a sensible error code in ret. This would lead to the chip
silently failing probe, as it would still return 0. Fix this up by
adding appropriate sets of the return value.

Signed-off-by: Charles Keepax 
---
 drivers/mfd/arizona-core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index e4f97b3..34a2c26 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -1121,6 +1121,7 @@ int arizona_dev_init(struct arizona *arizona)
break;
default:
dev_err(arizona->dev, "Unknown device ID: %x\n", reg);
+   ret = -EINVAL;
goto err_reset;
}
 
@@ -1280,12 +1281,14 @@ int arizona_dev_init(struct arizona *arizona)
break;
default:
dev_err(arizona->dev, "Unknown device ID %x\n", reg);
+   ret = -EINVAL;
goto err_reset;
}
 
if (!subdevs) {
dev_err(arizona->dev,
"No kernel support for device ID %x\n", reg);
+   ret = -EINVAL;
goto err_reset;
}
 
-- 
2.1.4

[PATCH RESEND] phy: exynos5-usbdrd: Remove "static" from local variable

[Axel Lin]

The 'reg' local variable does not need to be static.

Signed-off-by: Axel Lin 
---
This patch was sent on 
http://www.spinics.net/lists/linux-samsung-soc/msg51405.html

 drivers/phy/phy-exynos5-usbdrd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 20696f5..07ed608 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -249,7 +249,7 @@ static void exynos5_usbdrd_phy_isol(struct phy_usb_instance 
*inst,
 static unsigned int
 exynos5_usbdrd_pipe3_set_refclk(struct phy_usb_instance *inst)
 {
-   static u32 reg;
+   u32 reg;
struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
 
/* restore any previous reference clock settings */
@@ -295,7 +295,7 @@ exynos5_usbdrd_pipe3_set_refclk(struct phy_usb_instance 
*inst)
 static unsigned int
 exynos5_usbdrd_utmi_set_refclk(struct phy_usb_instance *inst)
 {
-   static u32 reg;
+   u32 reg;
struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
 
/* restore any previous reference clock settings */
-- 
2.1.4

Re: [PATCH RESEND] phy: exynos5-usbdrd: Remove "static" from local variable

[Krzysztof Kozlowski]

On 08/12/2016 11:27 AM, Axel Lin wrote:
> The 'reg' local variable does not need to be static.
> 
> Signed-off-by: Axel Lin 
> ---
> This patch was sent on 
> http://www.spinics.net/lists/linux-samsung-soc/msg51405.html
> 
>  drivers/phy/phy-exynos5-usbdrd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Looks correct, good catch!

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[GIT PULL] sound fixes for 4.8-rc2

[Takashi Iwai]

Linus,

please pull sound fixes for v4.8-rc2 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-4.8-rc2

The topmost commit is a52ff34e5ec61749c62c6618b76a9d6dbecee450



sound fixes for 4.8-rc2

A regression fix of HD-audio runtime PM and two USB quirks.



Piotr Karasinski (1):
  ALSA: usb-audio: Add a sample rate quirk for Creative Live! Cam Socialize 
HD (VF0610)

Takashi Iwai (1):
  ALSA: hda - Manage power well properly for resume

Vittorio Gambaletta (VittGam) (1):
  ALSA: usb-audio: Add quirk for ELP HD USB Camera

---
 sound/pci/hda/hda_intel.c | 32 
 sound/usb/quirks.c|  2 ++
 2 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 89dacf9b4e6c..160c7f713722 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -906,20 +906,23 @@ static int azx_resume(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip;
struct hda_intel *hda;
+   struct hdac_bus *bus;
 
if (!card)
return 0;
 
chip = card->private_data;
hda = container_of(chip, struct hda_intel, chip);
+   bus = azx_bus(chip);
if (chip->disabled || hda->init_failed || !chip->running)
return 0;
 
-   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL
-   && hda->need_i915_power) {
-   snd_hdac_display_power(azx_bus(chip), true);
-   snd_hdac_i915_set_bclk(azx_bus(chip));
+   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
+   snd_hdac_display_power(bus, true);
+   if (hda->need_i915_power)
+   snd_hdac_i915_set_bclk(bus);
}
+
if (chip->msi)
if (pci_enable_msi(pci) < 0)
chip->msi = 0;
@@ -929,6 +932,11 @@ static int azx_resume(struct device *dev)
 
hda_intel_init_chip(chip, true);
 
+   /* power down again for link-controlled chips */
+   if ((chip->driver_caps & AZX_DCAPS_I915_POWERWELL) &&
+   !hda->need_i915_power)
+   snd_hdac_display_power(bus, false);
+
snd_power_change_state(card, SNDRV_CTL_POWER_D0);
 
trace_azx_resume(chip);
@@ -1008,6 +1016,7 @@ static int azx_runtime_resume(struct device *dev)
 
chip = card->private_data;
hda = container_of(chip, struct hda_intel, chip);
+   bus = azx_bus(chip);
if (chip->disabled || hda->init_failed)
return 0;
 
@@ -1015,15 +1024,9 @@ static int azx_runtime_resume(struct device *dev)
return 0;
 
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
-   bus = azx_bus(chip);
-   if (hda->need_i915_power) {
-   snd_hdac_display_power(bus, true);
+   snd_hdac_display_power(bus, true);
+   if (hda->need_i915_power)
snd_hdac_i915_set_bclk(bus);
-   } else {
-   /* toggle codec wakeup bit for STATESTS read */
-   snd_hdac_set_codec_wakeup(bus, true);
-   snd_hdac_set_codec_wakeup(bus, false);
-   }
}
 
/* Read STATESTS before controller reset */
@@ -1043,6 +1046,11 @@ static int azx_runtime_resume(struct device *dev)
azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) &
~STATESTS_INT_MASK);
 
+   /* power down again for link-controlled chips */
+   if ((chip->driver_caps & AZX_DCAPS_I915_POWERWELL) &&
+   !hda->need_i915_power)
+   snd_hdac_display_power(bus, false);
+
trace_azx_runtime_resume(chip);
return 0;
 }
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 6adde457b602..6cf1f3597455 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1128,6 +1128,7 @@ bool snd_usb_get_sample_rate_quirk(struct snd_usb_audio 
*chip)
 {
/* devices which do not support reading the sample rate. */
switch (chip->usb_id) {
+   case USB_ID(0x041E, 0x4080): /* Creative Live Cam VF0610 */
case USB_ID(0x045E, 0x075D): /* MS Lifecam Cinema  */
case USB_ID(0x045E, 0x076D): /* MS Lifecam HD-5000 */
case USB_ID(0x045E, 0x076E): /* MS Lifecam HD-5001 */
@@ -1138,6 +1139,7 @@ bool snd_usb_get_sample_rate_quirk(struct snd_usb_audio 
*chip)
case USB_ID(0x047F, 0xAA05): /* Plantronics DA45 */
case USB_ID(0x04D8, 0xFEEA): /* Benchmark DAC1 Pre */
case USB_ID(0x0556, 0x0014): /* Phoenix Audio TMX320VC */
+   case USB_ID(0x05A3, 0x9420): /* ELP HD USB Camera */
case USB_ID(0x074D, 0x3553): /* Outlaw RR2150 (Micronas UAC3553B) */
case USB_ID(0x1de7, 0x0013): /* Phoenix Audio MT202exe */
case USB

Re: [PATCH v6 0/5] /dev/random - a new approach

[Stephan Mueller]

Am Donnerstag, 11. August 2016, 17:36:32 CEST schrieb Theodore Ts'o:

Hi Theodore,

> On Thu, Aug 11, 2016 at 02:24:21PM +0200, Stephan Mueller wrote:
> > The following patch set provides a different approach to /dev/random 
which
> > I call Linux Random Number Generator (LRNG) to collect entropy within the
> > Linux kernel. The main improvements compared to the legacy /dev/random is
> > to provide sufficient entropy during boot time as well as in virtual
> > environments and when using SSDs. A secondary design goal is to limit the
> > impact of the entropy collection on massive parallel systems and also
> > allow the use accelerated cryptographic primitives. Also, all steps of
> > the entropic data processing are testable. Finally massive performance
> > improvements are visible at /dev/urandom and get_random_bytes.
> > 
> > The design and implementation is driven by a set of goals described in 
[1]
> > that the LRNG completely implements. Furthermore, [1] includes a
> > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
> > AIS20/31.
> 
> Given the changes that have landed in Linus's tree for 4.8, how many
> of the design goals for your LRNG are still left not yet achieved?

The core concerns I have at this point are the following:

- correlation: the interrupt noise source is closely correlated to the HID/
block noise sources. I see that the fast_pool somehow "smears" that 
correlation. However, I have not seen a full assessment that the correlation 
is gone away. Given that I do not believe that the HID event values (key 
codes, mouse coordinates) have any entropy -- the user sitting at the console 
exactly knows what he pressed and which mouse coordinates are created, and 
given that for block devices, only the high-resolution time stamp gives any 
entropy, I am suggesting to remove the HID/block device noise sources and 
leave the IRQ noise source. Maybe we could record the HID event values to 
further stir the pool but do not credit it any entropy. Of course, that would 
imply that the assumed entropy in an IRQ event is revalued. I am currently 
finishing up an assessment of how entropy behaves in a VM (where I hope that 
the report is released). Please note that contrary to my initial 
expectations, the IRQ events are the only noise sources which are almost 
unaffected by a VMM operation. Hence, IRQs are much better in a VM 
environment than block or HID noise sources.

- entropy estimate: the current entropy heuristics IMHO have nothing to do 
with the entropy of the data coming in. Currently, the min of first/second/
third derivative of the Jiffies time stamp is used and capped at 11. That 
value is the entropy value credited to the event. Given that the entropy 
rests with the high-res time stamp and not with jiffies or the event value, I 
think that the heuristic is not helpful. I understand that it underestimates 
on average the available entropy, but that is the only relationship I see. In 
my mentioned entropy in VM assessment (plus the BSI report on /dev/random 
which is unfortunately written in German, but available in the Internet) I 
did a min entropy calculation based on different min entropy formulas 
(SP800-90B). That calculation shows that we get from the noise sources is 
about 5 to 6 bits. On average the entropy heuristic credits between 0.5 and 1 
bit for events, so it underestimates the entropy. Yet, the entropy heuristic 
can credit up to 11 bits. Here I think it becomes clear that the current 
entropy heuristic is not helpful. In addition, on systems where no high-res 
timer is available, I assume (I have not measured it yet), the entropy 
heuristic even overestimates the entropy.

- albeit I like the current injection of twice the fast_pool into the 
ChaCha20 (which means that the pathological case where the collection of 128 
bits of entropy would result in an attack resistance of 2 * 128 bits and 
*not* 2^128 bits is now increased to an attack strength of 2^64 * 2 bits), /
dev/urandom has *no* entropy until that injection happens. The injection 
happens early in the boot cycle, but in my test system still after user space 
starts. I tried to inject "atomically" (to not fall into the aforementioned 
pathological case trap) of 32 / 112 / 256 bits of entropy into the /dev/
urandom RNG to have /dev/urandom at least seeded with a few bits before user 
space starts followed by the atomic injection of the subsequent bits.


A minor issue that may not be of too much importance: if there is a user 
space entropy provider waiting with select(2) or poll(2) on /dev/random (like 
rngd or my jitterentropy-rngd), this provider is only woken up when somebody 
pulls on /dev/random. If /dev/urandom is pulled (and the system does not 
receive entropy from the add*randomness noise sources), the user space 
provider is *not* woken up. So, /dev/urandom spins as a DRNG even though it 
could use a topping off of its entropy once in a while. In my jitterentropy-
rngd I have han

[PATCH] crypto: fix ctx pointer and digest copy in sha256-mb

[Xiaodong Liu]

1. fix ctx pointer
Use req_ctx which is the ctx for the next job that have
been completed in the lanes instead of the first
completed job rctx, whose completion could have been
called and released.
2. fix digest copy
Use XMM register to copy another 16 bytes sha256 digest
instead of a regular register.

Signed-off-by: Xiaodong Liu 
---
 arch/x86/crypto/sha256-mb/sha256_mb.c| 4 ++--
 arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S | 7 ---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/crypto/sha256-mb/sha256_mb.c 
b/arch/x86/crypto/sha256-mb/sha256_mb.c
index 89fa85e..6f97fb3 100644
--- a/arch/x86/crypto/sha256-mb/sha256_mb.c
+++ b/arch/x86/crypto/sha256-mb/sha256_mb.c
@@ -485,10 +485,10 @@ static int sha_complete_job(struct 
mcryptd_hash_request_ctx *rctx,
 
req = cast_mcryptd_ctx_to_req(req_ctx);
if (irqs_disabled())
-   rctx->complete(&req->base, ret);
+   req_ctx->complete(&req->base, ret);
else {
local_bh_disable();
-   rctx->complete(&req->base, ret);
+   req_ctx->complete(&req->base, ret);
local_bh_enable();
}
}
diff --git a/arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S 
b/arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S
index b691da9..a78a069 100644
--- a/arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S
+++ b/arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S
@@ -265,13 +265,14 @@ ENTRY(sha256_mb_mgr_get_comp_job_avx2)
vpinsrd $1, _args_digest+1*32(state, idx, 4), %xmm0, %xmm0
vpinsrd $2, _args_digest+2*32(state, idx, 4), %xmm0, %xmm0
vpinsrd $3, _args_digest+3*32(state, idx, 4), %xmm0, %xmm0
-   movl_args_digest+4*32(state, idx, 4), tmp2_w
+   vmovd   _args_digest(state , idx, 4) , %xmm0
vpinsrd $1, _args_digest+5*32(state, idx, 4), %xmm1, %xmm1
vpinsrd $2, _args_digest+6*32(state, idx, 4), %xmm1, %xmm1
vpinsrd $3, _args_digest+7*32(state, idx, 4), %xmm1, %xmm1
 
-   vmovdqu %xmm0, _result_digest(job_rax)
-   movltmp2_w, _result_digest+1*16(job_rax)
+vmovdqu %xmm0, _result_digest(job_rax)
+offset =  (_result_digest + 1*16)
+vmovdqu %xmm1, offset(job_rax)
 
pop %rbx
 
-- 
1.9.1

Re: Resend: Another 4.4 to 4.5 floppy issue

[Jiri Kosina]

On Thu, 11 Aug 2016, Mark Hounschell wrote:

> I just tested what is currently in Linus' tree and it does NOT work for 
> me.

Is there some minimalized reproducer you are seeing the regression with 
that you could share?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/4] befs: check allocation_group number before use

[Luis de Bethencourt]

On 12/08/16 08:26, Salah Triki wrote:
> On Thu, Aug 11, 2016 at 11:56:16AM +0100, Luis de Bethencourt wrote:
>> On 10/08/16 23:12, Salah Triki wrote:
>>> Check that the allocation group number is not greater or equal to the
>>> number of allocations group in the file system and return BEF_ERR in the
>>> case of error.
>>>
>>> Signed-off-by: Salah Triki 
>>> ---
>>>  fs/befs/befs.h | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/fs/befs/befs.h b/fs/befs/befs.h
>>> index 55f3ea2..6daf4c4 100644
>>> --- a/fs/befs/befs.h
>>> +++ b/fs/befs/befs.h
>>> @@ -121,6 +121,11 @@ BEFS_I(const struct inode *inode)
>>>  static inline befs_blocknr_t
>>>  iaddr2blockno(struct super_block *sb, const befs_inode_addr *iaddr)
>>>  {
>>> +   if (iaddr->allocation_group >= BEFS_SB(sb)->num_ags) {
>>> +   befs_error(sb, "BEFS: Invalid allocation group %u, max is %u",
>>> +  iaddr->allocation_group, BEFS_SB(sb)->num_ags);
>>> +   return BEFS_ERR;
>>> +   }
>>> return ((iaddr->allocation_group << BEFS_SB(sb)->ag_shift) +
>>> iaddr->start);
>>>  }
>>>
>>
>> Hi Salah,
>>
>> To understand why would we check for this. When can this error happen? I 
>> mean,
>> when can iaddr2blockno() be called with an out of bounds allocation group?
>>
>> Thanks,
>> Luis
> 
> Hi Luis,
> 
> allocation group number is set to blockno >> BEFS_SB(sb)->ag_shift by 
> blockno2iaddr(), so if ag_shift is not valid, an out of bound may occur. 
> By now, thanx to your question ;), I think it's better to check the validity 
> of ag_shift when the superblock is loaded.
> 
> Nack.
> 
> Thanx for the question :)
> Salah 
> 

No problem :)

I will assume the Nack covers patch 1 to 3. Since they are all related.

Enjoy the weekend,
Luis

[PATCH] crypto: fix ctx pointer in sha512-mb

[Xiaodong Liu]

Signed-off-by: Xiaodong Liu 
---
 arch/x86/crypto/sha512-mb/sha512_mb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c 
b/arch/x86/crypto/sha512-mb/sha512_mb.c
index f4cf5b7..d210174 100644
--- a/arch/x86/crypto/sha512-mb/sha512_mb.c
+++ b/arch/x86/crypto/sha512-mb/sha512_mb.c
@@ -497,10 +497,10 @@ static int sha_complete_job(struct 
mcryptd_hash_request_ctx *rctx,
 
req = cast_mcryptd_ctx_to_req(req_ctx);
if (irqs_disabled())
-   rctx->complete(&req->base, ret);
+   req_ctx->complete(&req->base, ret);
else {
local_bh_disable();
-   rctx->complete(&req->base, ret);
+   req_ctx->complete(&req->base, ret);
local_bh_enable();
}
}
-- 
1.9.1

Re: [RFC PATCH] kernel/fork: fix CLONE_CHILD_CLEARTID regression in nscd

[Michal Hocko]

On Wed 03-08-16 23:08:04, Oleg Nesterov wrote:
> sorry for delay, I am travelling till the end of the week.

Same here...

> On 08/01, Michal Hocko wrote:
> >
> > fec1d0115240 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit")
> 
> almost 10 years ago ;)

Yes, it's been a while... I guess nscd doesn't enable persistent host
caching by default. I just know that our customer wanted to enable this
feature to find out it doesn't work properly. At least that is my
understanding.

> > has caused a subtle regression in nscd which uses CLONE_CHILD_CLEARTID
> > to clear the nscd_certainly_running flag in the shared databases, so
> > that the clients are notified when nscd is restarted.
> 
> So iiuc with this patch nscd_certainly_running should be cleared even if
> ncsd was killed by !sig_kernel_coredump() signal, right?

Yes.

> > We should also check for vfork because
> > this is killable since d68b46fe16ad ("vfork: make it killable").
> 
> Hmm, why? Can't understand... In any case this check doesn't look right, the
> comment says "a killed vfork parent" while tsk->vfork_done != NULL means it
> is a vforked child.
> 
> So if we want this change, why we can't simply do
> 
>   -   if (!(tsk->flags & PF_SIGNALED) &&
>   +   if (!(tsk->signal->flags & SIGNAL_GROUP_COREDUMP) &&
> 
> ?

This is what I had initially. But then the comment above the check made
me worried that the parent of vforked child might get confused if the
flag is cleared. I might have completely misunderstood the point of the
comment though. So if you believe that vfork_done check is incorrect I
can drop it. It shouldn't have any effect on the nscd usecase AFAIU.

Thanks!

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] KVM: nVMX: postpone VMCS changes on MSR_IA32_APICBASE write

[Radim Krčmář]

2016-08-12 14:07+0800, Wanpeng Li:
> 2016-08-09 2:16 GMT+08:00 Radim Krčmář :
>> If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the
>> write with vmcs02 as the current VMCS.
>> This will incorrectly apply modifications intended for vmcs01 to vmcs02
>> and L2 can use it to gain access to L0's x2APIC registers by disabling
>> virtualized x2APIC while using msr bitmap that assumes enabled.
>>
>> Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the
>> current VMCS.  An alternative solution would temporarily make vmcs01 the
>> current VMCS, but it requires more care.
> 
> There is a scenario both L1 and L2 are running on x2apic mode, L1
> don't own the APIC_BASE writes, then L2 is intended to disable x2apic
> mode, however, your logic will also disable x2apic mode for L1.

You mean a case where L1 does intercept APIC_BASE?

That case is not affected, because it should cause a nested VM exit, so
vmx_set_virtual_x2apic_mode() won't be called in the first place.

Re: [PATCH v8 10/10] Input: sur40 - use new V4L2 touch input type

[Hans Verkuil]

Hi Nick,

On 07/18/2016 11:10 PM, Nick Dyer wrote:
> Support both V4L2_TCH_FMT_TU08 and V4L2_PIX_FMT_GREY for backwards
> compatibility.
> 
> Note: I have not tested these changes (I have no access to the hardware)
> so not signing off.

I can't merge this without your Signed-off. The Signed-off has nothing to do 
with
whether or not you have tested the code. I'm leaving this out of the pull 
request
for now.

Regards,

Hans

> ---
>  drivers/input/touchscreen/sur40.c |  122 
> +++--
>  1 file changed, 89 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/sur40.c 
> b/drivers/input/touchscreen/sur40.c
> index 4ea4757..fc275cb 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -139,6 +139,27 @@ struct sur40_image_header {
>  #define SUR40_GET_STATE   0xc5 /*  4 bytes state (?) */
>  #define SUR40_GET_SENSORS 0xb1 /*  8 bytes sensors   */
>  
> +static const struct v4l2_pix_format sur40_pix_format[] = {
> + {
> + .pixelformat = V4L2_TCH_FMT_TU08,
> + .width  = SENSOR_RES_X / 2,
> + .height = SENSOR_RES_Y / 2,
> + .field = V4L2_FIELD_NONE,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .bytesperline = SENSOR_RES_X / 2,
> + .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
> + },
> + {
> + .pixelformat = V4L2_PIX_FMT_GREY,
> + .width  = SENSOR_RES_X / 2,
> + .height = SENSOR_RES_Y / 2,
> + .field = V4L2_FIELD_NONE,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .bytesperline = SENSOR_RES_X / 2,
> + .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
> + }
> +};
> +
>  /* master device state */
>  struct sur40_state {
>  
> @@ -149,6 +170,7 @@ struct sur40_state {
>   struct v4l2_device v4l2;
>   struct video_device vdev;
>   struct mutex lock;
> + struct v4l2_pix_format pix_fmt;
>  
>   struct vb2_queue queue;
>   struct list_head buf_list;
> @@ -169,7 +191,6 @@ struct sur40_buffer {
>  
>  /* forward declarations */
>  static const struct video_device sur40_video_device;
> -static const struct v4l2_pix_format sur40_video_format;
>  static const struct vb2_queue sur40_queue;
>  static void sur40_process_video(struct sur40_state *sur40);
>  
> @@ -420,7 +441,7 @@ static void sur40_process_video(struct sur40_state *sur40)
>   goto err_poll;
>   }
>  
> - if (le32_to_cpu(img->size) != sur40_video_format.sizeimage) {
> + if (le32_to_cpu(img->size) != sur40->pix_fmt.sizeimage) {
>   dev_err(sur40->dev, "image size mismatch\n");
>   goto err_poll;
>   }
> @@ -431,7 +452,7 @@ static void sur40_process_video(struct sur40_state *sur40)
>  
>   result = usb_sg_init(&sgr, sur40->usbdev,
>   usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), 0,
> - sgt->sgl, sgt->nents, sur40_video_format.sizeimage, 0);
> + sgt->sgl, sgt->nents, sur40->pix_fmt.sizeimage, 0);
>   if (result < 0) {
>   dev_err(sur40->dev, "error %d in usb_sg_init\n", result);
>   goto err_poll;
> @@ -586,13 +607,14 @@ static int sur40_probe(struct usb_interface *interface,
>   if (error)
>   goto err_unreg_v4l2;
>  
> + sur40->pix_fmt = sur40_pix_format[0];
>   sur40->vdev = sur40_video_device;
>   sur40->vdev.v4l2_dev = &sur40->v4l2;
>   sur40->vdev.lock = &sur40->lock;
>   sur40->vdev.queue = &sur40->queue;
>   video_set_drvdata(&sur40->vdev, sur40);
>  
> - error = video_register_device(&sur40->vdev, VFL_TYPE_GRABBER, -1);
> + error = video_register_device(&sur40->vdev, VFL_TYPE_TOUCH, -1);
>   if (error) {
>   dev_err(&interface->dev,
>   "Unable to register video subdevice.");
> @@ -651,10 +673,10 @@ static int sur40_queue_setup(struct vb2_queue *q,
>   *nbuffers = 3 - q->num_buffers;
>  
>   if (*nplanes)
> - return sizes[0] < sur40_video_format.sizeimage ? -EINVAL : 0;
> + return sizes[0] < sur40->pix_fmt.sizeimage ? -EINVAL : 0;
>  
>   *nplanes = 1;
> - sizes[0] = sur40_video_format.sizeimage;
> + sizes[0] = sur40->pix_fmt.sizeimage;
>  
>   return 0;
>  }
> @@ -666,7 +688,7 @@ static int sur40_queue_setup(struct vb2_queue *q,
>  static int sur40_buffer_prepare(struct vb2_buffer *vb)
>  {
>   struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
> - unsigned long size = sur40_video_format.sizeimage;
> + unsigned long size = sur40->pix_fmt.sizeimage;
>  
>   if (vb2_plane_size(vb, 0) < size) {
>   dev_err(&sur40->usbdev->dev, "buffer too small (%lu < %lu)\n",
> @@ -741,7 +763,7 @@ static int sur40_vidioc_querycap(struct file *file, void 
> *priv,
>   strlcpy(cap->driver, DRIVER_SHORT, sizeof(cap->driver));
>   strlcpy(cap->card, DRIVER_LONG, sizeof(cap

Re: [PATCH v10 1/2] printk: Make printk() completely async

[Petr Mladek]

On Wed 2016-08-10 14:17:55, Viresh Kumar wrote:
> +Vladi/Greg,
> 
> On Wed, Apr 6, 2016 at 1:27 AM, Jan Kara  wrote:
> > On Mon 04-04-16 15:51:49, Andrew Morton wrote:
> 
> >> > +static int __init init_printk_kthread(void)
> >> > +{
> >> > +   struct task_struct *thread;
> >> > +
> >> > +   if (printk_sync)
> >> > +   return 0;
> >> > +
> >> > +   thread = kthread_run(printk_kthread_func, NULL, "printk");
> >>
> >> This gets normal scheduling policy, so a spinning userspace SCHED_FIFO
> >> task will block printk for ever.  This seems bad.
> >
> > I have to research this a bit but won't the SCHED_FIFO task that has
> > potentially unbounded amount of work lockup the CPU even though it does
> > occasional cond_resched()?
> 
> We are facing complete hogs because of the printk thread being a SCHED_FIFO
> task and have this patch to fix it up for now.
> 
> Author: Vladislav Levenetz 
> Date:   Wed Aug 10 13:58:00 2016 -0700
> 
> SW-7786: printk: Lower the priority of printk thread
> 
> Flooding the console (with a test module) in a tight loop indefinitely
> makes android user interface very sluggish. Opening YouTube app and the
> device hangs and becomes even more unresponsive to the point it
> completely hangs.
> 
> The asynchronous printk thread is a SCHED FIFO thread with priority
> MAX_RT_PRIO - 1. If we create it as a simple thread (i.e. no SCHED FIFO)
> instead, we observe much better performance using the same printk flood
> test. We don't even notice any kind of sluggishness during device usage.
> We can play a YouTube clip smoothly and use the device normally in
> general.  The kernel log looks fine as well, as the flood of messages
> continue normally.
> 
> Signed-off-by: Vladislav Levenetz 
> Signed-off-by: Viresh Kumar 
> ---
>  kernel/printk/printk.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index c32872872cb6..ad5b30e5e6d9 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2856,9 +2856,6 @@ static int printk_kthread_func(void *data)
>  static int __init_printk_kthread(void)
>  {
> struct task_struct *thread;
> -   struct sched_param param = {
> -   .sched_priority = MAX_RT_PRIO - 1,
> -   };
> 
> if (!printk_kthread_can_run || printk_sync || printk_kthread)
> return 0;
> @@ -2870,7 +2867,6 @@ static int __init_printk_kthread(void)
> return PTR_ERR(thread);
> }
> 
> -   sched_setscheduler(thread, SCHED_FIFO, ¶m);
> printk_kthread = thread;
> return 0;
>  }

IMHO, this is fine. We force the synchronous mode in critical
situations anyway.

But I was curious if we could hit a printk from the wake_up_process().
The change above causes using the fair scheduler and there is
the following call chain [*]

  vprintk_emit()
  -> wake_up_process()
   -> try_to_wake_up()
-> ttwu_queue()
 -> ttwu_do_activate()
  -> ttwu_activate()
   -> activate_task()
-> enqueue_task()
 -> enqueue_task_fair() via p->sched_class->enqueue_task
  -> cfs_rq_of()
   -> task_of()
-> WARN_ON_ONCE(!entity_is_task(se))

We should never trigger this because printk_kthread is a task.
But what if the date gets inconsistent?

Then there is the following chain:

  vprintk_emit()
  -> wake_up_process()
   -> try_to_wake_up()
-> ttwu_queue()
 -> ttwu_do_activate()
  -> ttwu_activate()
   -> activate_task()
-> enqueue_task()
 -> enqueue_task_fair() via p->sched_class->enqueue_task
  ->hrtick_update()
   -> hrtick_start_fair()
-> WARN_ON(task_rq(p) != rq)

This looks like another paranoid consistency check that might be
triggered when the scheduler gets messed.

I see few possible solutions:

1. Replace the WARN_ONs by printk_deferred().

   This is the usual solution but it would make debugging less convenient.


2. Force synchronous printk inside WARN()/BUG() macros.

   This would make sense even from other reasons. These are printed
   when the system is in a strange state. There is no guarantee that
   the printk_kthread will get scheduled.


3. Force printk_deferred() inside WARN()/BUG() macros via the per-CPU
   printk_func.

   It might be elegant. But we do not want this outside the scheduler
   code. Therefore we would need special variants of  WARN_*_SCHED()
   BUG_*_SCHED() macros.


I personally prefer the 2nd solution. What do you think about it,
please?


Best Regards,
Petr

Re: [PATCH RESEND v2 2/3] phy: sun4i: add support for A64 usb phy

[Kishon Vijay Abraham I]

On Friday 12 August 2016 08:36 AM, Icenowy Zheng wrote:
> There's something unknown in the pmu part that shared with H3.
> It's renamed as PMU_UNK1 from PMU_UNK_H3.
> 
> Signed-off-by: Icenowy Zheng 

Fixed the following checkpatch warning and merged this to linux-phy tree.

WARNING: line over 80 characters
#311: FILE: drivers/phy/phy-sun4i-usb.c:794:
+   { .compatible = "allwinner,sun50i-a64-usb-phy", .data = 
&sun50i_a64_cfg},

Thanks
Kishon

> ---
>  drivers/phy/phy-sun4i-usb.c | 34 --
>  1 file changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index 0a45bc6..a4db658 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -49,7 +49,7 @@
>  #define REG_PHYCTL_A33   0x10
>  #define REG_PHY_UNK_H3   0x20
>  
> -#define REG_PMU_UNK_H3   0x10
> +#define REG_PMU_UNK1 0x10
>  
>  #define PHYCTL_DATA  BIT(7)
>  
> @@ -97,6 +97,7 @@ enum sun4i_usb_phy_type {
>   sun6i_a31_phy,
>   sun8i_a33_phy,
>   sun8i_h3_phy,
> + sun50i_a64_phy,
>  };
>  
>  struct sun4i_usb_phy_cfg {
> @@ -105,6 +106,7 @@ struct sun4i_usb_phy_cfg {
>   u32 disc_thresh;
>   u8 phyctl_offset;
>   bool dedicated_clocks;
> + bool enable_pmu_unk1;
>  };
>  
>  struct sun4i_usb_phy_data {
> @@ -180,8 +182,9 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> *phy, u32 addr, u32 data,
>  
>   mutex_lock(&phy_data->mutex);
>  
> - if (phy_data->cfg->type == sun8i_a33_phy) {
> - /* A33 needs us to set phyctl to 0 explicitly */
> + if (phy_data->cfg->type == sun8i_a33_phy ||
> + phy_data->cfg->type == sun50i_a64_phy) {
> + /* A33 or A64 needs us to set phyctl to 0 explicitly */
>   writel(0, phyctl);
>   }
>  
> @@ -255,14 +258,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> + if (data->cfg->enable_pmu_unk1) {
> + val = readl(phy->pmu + REG_PMU_UNK1);
> + writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> + }
> +
>   if (data->cfg->type == sun8i_h3_phy) {
>   if (phy->index == 0) {
>   val = readl(data->base + REG_PHY_UNK_H3);
>   writel(val & ~1, data->base + REG_PHY_UNK_H3);
>   }
> -
> - val = readl(phy->pmu + REG_PMU_UNK_H3);
> - writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
>   } else {
>   /* Enable USB 45 Ohm resistor calibration */
>   if (phy->index == 0)
> @@ -713,6 +718,7 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = false,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
> @@ -721,6 +727,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
>   .disc_thresh = 2,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = false,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
> @@ -729,6 +736,7 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = true,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
> @@ -737,6 +745,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
>   .disc_thresh = 2,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = false,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
> @@ -745,6 +754,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A10,
>   .dedicated_clocks = true,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
> @@ -753,6 +763,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
>   .disc_thresh = 3,
>   .phyctl_offset = REG_PHYCTL_A33,
>   .dedicated_clocks = true,
> + .enable_pmu_unk1 = false,
>  };
>  
>  static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
> @@ -760,6 +771,16 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
>   .type = sun8i_h3_phy,
>   .disc_thresh = 3,
>   .dedicated_clocks = true,
> + .enable_pmu_unk1 = true,
> +};
> +
> +static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
> + .num_phys = 2,
> + .type = sun50i_a64_phy,
> + .disc_thresh = 3,
> + .phyctl_offset = REG_PHYCTL_A33,
> + .dedicated_clocks = true,
> + .enable_pmu_unk1 = true,
>  };
>  
>  static const struct of_device_id sun4i_usb_phy_of_match[] = {
> @@ -770,6 +791,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] 
> = {
>  

Re: [PATCH V4] phy: bcm-ns-usb3: new driver for USB 3.0 PHY on Northstar

[Kishon Vijay Abraham I]

Hi,

On Friday 12 August 2016 03:58 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Northstar is a family of SoCs used in home routers. They have USB 2.0
> and 3.0 controllers with PHYs that need to be properly initialized.
> This driver provides PHY init support in a generic way and can be bound
> with XHCI controller driver.
> 
> There aren't any public datasheets from Broadcom so we can't have nice
> defines for all used bits. It means we just follow Broadcom's
> initialization procedure using their magic values. We were quite lucky
> actually that Broadcom put some comments in their SDK reference code
> explaining what given writes are responsible for.
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Redesign the driver to don't depend on bcma. This will allow reusing it on
> Northstar+ which doesn't use bcma. This requires providing two different
> registers ranges in DT which was documented in bindings info.
> V3: Use readl and writel
> Fix MODULE_LICENSE to match header (v2)
> Mention C0 series in Documentation
> RESEND: I can see that my PHY driver for USB 2.0:
>   [PATCH V4] phy: bcm-ns-usb2: new driver for USB 2.0 PHY on Northstar
>   sent on 14 Apr 2016 was accepted, however:
>   [PATCH V3] phy: bcm-ns-usb3: new driver for USB 3.0 PHY on Northstar
>   sent the very same day wasn't.
>   I'm sending a simply rebased version hoping it can be accepted or
>   commented somehow (e.g. what needs to be changed).
> V4: Comment on magic values in commit message
> Add Copyright for Broadcom and their magic values
> Some in-code trivial comments on enabling MDIO
> Use some existing defines
> Drop setting .owner
> Rebased on top of updated "next" branch
> ---
>  .../devicetree/bindings/phy/bcm-ns-usb3-phy.txt|  23 ++
>  drivers/phy/Kconfig|   9 +
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-bcm-ns-usb3.c  | 273 
> +
>  4 files changed, 306 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
>  create mode 100644 drivers/phy/phy-bcm-ns-usb3.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt 
> b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> new file mode 100644
> index 000..09aeba9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/bcm-ns-usb3-phy.txt
> @@ -0,0 +1,23 @@
> +Driver for Broadcom Northstar USB 3.0 PHY
> +
> +Required properties:
> +
> +- compatible: one of: "brcm,ns-ax-usb3-phy", "brcm,ns-bx-usb3-phy".
> +- reg: register mappings for DMP (Device Management Plugin) and ChipCommon B
> +   MMI.
> +- reg-names: "dmp" and "ccb-mii"
> +
> +Initialization of USB 3.0 PHY depends on Northstar version. There are 
> currently
> +three known series: Ax, Bx and Cx.
> +Known A0: BCM4707 rev 0
> +Known B0: BCM4707 rev 4, BCM53573 rev 2
> +Known B1: BCM4707 rev 6
> +Known C0: BCM47094 rev 0
> +
> +Example:
> + usb3-phy {
> + compatible = "brcm,ns-ax-usb3-phy";
> + reg = <0x18105000 0x1000>, <0x18003000 0x1000>;
> + reg-names = "dmp", "ccb-mii";
> + #phy-cells = <0>;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 19bff3a..afbdd6a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -24,6 +24,15 @@ config PHY_BCM_NS_USB2
> Enable this to support Broadcom USB 2.0 PHY connected to the USB
> controller on Northstar family.
>  
> +config PHY_BCM_NS_USB3
> + tristate "Broadcom Northstar USB 3.0 PHY Driver"
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + depends on HAS_IOMEM && OF
> + select GENERIC_PHY
> + help
> +   Enable this to support Broadcom USB 3.0 PHY connected to the USB
> +   controller on Northstar family.
> +
>  config PHY_BERLIN_USB
>   tristate "Marvell Berlin USB PHY Driver"
>   depends on ARCH_BERLIN && RESET_CONTROLLER && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 90ae198..b99370a 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -4,6 +4,7 @@
>  
>  obj-$(CONFIG_GENERIC_PHY)+= phy-core.o
>  obj-$(CONFIG_PHY_BCM_NS_USB2)+= phy-bcm-ns-usb2.o
> +obj-$(CONFIG_PHY_BCM_NS_USB3)+= phy-bcm-ns-usb3.o
>  obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
>  obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
>  obj-$(CONFIG_PHY_DA8XX_USB)  += phy-da8xx-usb.o
> diff --git a/drivers/phy/phy-bcm-ns-usb3.c b/drivers/phy/phy-bcm-ns-usb3.c
> new file mode 100644
> index 000..c9326c5
> --- /dev/null
> +++ b/drivers/phy/phy-bcm-ns-usb3.c
> @@ -0,0 +1,273 @@
> +/*
> + * Broadcom Northstar USB 3.0 PHY Driver
> + *
> + * Copyright (C) 2016 Rafał Miłecki 
> + *
> + * All magic values used for initialization (and related comments) were 
> obtained
> + * from Broadcom's SD

A potential data race in drivers/net/ethernet/smsc/smc91c92_cs.ko

[Pavel Andrianov]

Hi!

There is a potential data race in drivers/net/ethernet/smsc/smc91c92_cs.ko.
Regard two threads:

Thread 1Thread 2
...
... ->smc_open
->smc_tx_timeout   ->mod_timer
  -> smc_reset   ->media_check - timer function
-> smc_set_xcvr->smc_set_xcvr 

In this case the struct 'smc' is modified from two threads 
simultaneously. Likely, the first thread should acquire the same 
spinlock smc->lock as the second thread in media_check.


--
Pavel Andrianov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: andria...@ispras.ru

Re: Correct modules for Bay Trail MAX98090 soc?

[Mark Brown]

On Thu, Aug 11, 2016 at 06:31:27PM -0500, Pierre-Louis Bossart wrote:
> On 8/11/16 3:42 PM, Laura Abbott wrote:

> > which changed the dependencies for CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH.
> > The set of options Fedora selects means that
> > CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH
> > can't be selected. Is there another driver that's supposed to replace
> > CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH on Bay Trail or do the dependencies
> > need to be updated? The bugzilla has alsa-info for working and non-
> > working cases and the Fedora config is attached.

> If you remove support for all other baytrail options this driver should
> still be there and selectable. We just can't support both this driver for
> Chromebooks and the rest for other machines with the same distribution at
> the moment.

That sounds like a regression, what's the plan to fix it.


signature.asc
Description: PGP signature

[PATCH stable-4.4 0/3] backport memcg id patches

[Michal Hocko]

Hi,
this is my attempt to backport Johannes' 73f576c04b94 ("mm: memcontrol:
fix cgroup creation failure after many small jobs") to 4.4 based stable
kernel. The backport is not straightforward and there are 2 follow up
fixes on top of this commit. I would like to integrate these to our SLES
based kernel and believe other users might benefit from the backport as
well. All 3 patches are in the Linus tree already.

I would really appreciate if Johannes could double check after me before
this gets into the stable tree but my testing didn't reveal anything
unexpected.

Thanks!

[PATCH stable-4.4 3/3] mm: memcontrol: fix memcg id ref counter on swap charge move

[Michal Hocko]

From: Vladimir Davydov 

commit 615d66c37c755c49ce022c9e5ac0875d27d2603d upstream.

Since commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure
after many small jobs") swap entries do not pin memcg->css.refcnt
directly.  Instead, they pin memcg->id.ref.  So we should adjust the
reference counters accordingly when moving swap charges between cgroups.

Fixes: 73f576c04b941 ("mm: memcontrol: fix cgroup creation failure after many 
small jobs")
Link: 
http://lkml.kernel.org/r/9ce297c64954a42dc90b543bc76106c4a94f07e8.1470219853.git.vdavy...@virtuozzo.com
Signed-off-by: Vladimir Davydov 
Acked-by: Michal Hocko 
Acked-by: Johannes Weiner 
Cc: [3.19+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Michal Hocko 
---
 mm/memcontrol.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index dd6e2d24d9b1..d3e6e4fa61b8 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4136,9 +4136,9 @@ static struct cftype mem_cgroup_legacy_files[] = {
 
 static DEFINE_IDR(mem_cgroup_idr);
 
-static void mem_cgroup_id_get(struct mem_cgroup *memcg)
+static void mem_cgroup_id_get_many(struct mem_cgroup *memcg, unsigned int n)
 {
-   atomic_inc(&memcg->id.ref);
+   atomic_add(n, &memcg->id.ref);
 }
 
 static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
@@ -4159,9 +4159,9 @@ static struct mem_cgroup *mem_cgroup_id_get_online(struct 
mem_cgroup *memcg)
return memcg;
 }
 
-static void mem_cgroup_id_put(struct mem_cgroup *memcg)
+static void mem_cgroup_id_put_many(struct mem_cgroup *memcg, unsigned int n)
 {
-   if (atomic_dec_and_test(&memcg->id.ref)) {
+   if (atomic_sub_and_test(n, &memcg->id.ref)) {
idr_remove(&mem_cgroup_idr, memcg->id.id);
memcg->id.id = 0;
 
@@ -4170,6 +4170,16 @@ static void mem_cgroup_id_put(struct mem_cgroup *memcg)
}
 }
 
+static inline void mem_cgroup_id_get(struct mem_cgroup *memcg)
+{
+   mem_cgroup_id_get_many(memcg, 1);
+}
+
+static inline void mem_cgroup_id_put(struct mem_cgroup *memcg)
+{
+   mem_cgroup_id_put_many(memcg, 1);
+}
+
 /**
  * mem_cgroup_from_id - look up a memcg from a memcg id
  * @id: the memcg id to look up
@@ -4856,6 +4866,8 @@ static void __mem_cgroup_clear_mc(void)
if (!mem_cgroup_is_root(mc.from))
page_counter_uncharge(&mc.from->memsw, mc.moved_swap);
 
+   mem_cgroup_id_put_many(mc.from, mc.moved_swap);
+
/*
 * we charged both to->memory and to->memsw, so we
 * should uncharge to->memory.
@@ -4863,9 +4875,9 @@ static void __mem_cgroup_clear_mc(void)
if (!mem_cgroup_is_root(mc.to))
page_counter_uncharge(&mc.to->memory, mc.moved_swap);
 
-   css_put_many(&mc.from->css, mc.moved_swap);
+   mem_cgroup_id_get_many(mc.to, mc.moved_swap);
+   css_put_many(&mc.to->css, mc.moved_swap);
 
-   /* we've already done css_get(mc.to) */
mc.moved_swap = 0;
}
memcg_oom_recover(from);
-- 
2.8.1

[PATCH stable-4.4 1/3] mm: memcontrol: fix cgroup creation failure after many small jobs

[Michal Hocko]

From: Johannes Weiner 

commit 73f576c04b9410ed19660f74f97521bee6e1c546 upstream.

The memory controller has quite a bit of state that usually outlives the
cgroup and pins its CSS until said state disappears.  At the same time
it imposes a 16-bit limit on the CSS ID space to economically store IDs
in the wild.  Consequently, when we use cgroups to contain frequent but
small and short-lived jobs that leave behind some page cache, we quickly
run into the 64k limitations of outstanding CSSs.  Creating a new cgroup
fails with -ENOSPC while there are only a few, or even no user-visible
cgroups in existence.

Although pinning CSSs past cgroup removal is common, there are only two
instances that actually need an ID after a cgroup is deleted: cache
shadow entries and swapout records.

Cache shadow entries reference the ID weakly and can deal with the CSS
having disappeared when it's looked up later.  They pose no hurdle.

Swap-out records do need to pin the css to hierarchically attribute
swapins after the cgroup has been deleted; though the only pages that
remain swapped out after offlining are tmpfs/shmem pages.  And those
references are under the user's control, so they are manageable.

This patch introduces a private 16-bit memcg ID and switches swap and
cache shadow entries over to using that.  This ID can then be recycled
after offlining when the CSS remains pinned only by objects that don't
specifically need it.

This script demonstrates the problem by faulting one cache page in a new
cgroup and deleting it again:

  set -e
  mkdir -p pages
  for x in `seq 128000`; do
[ $((x % 1000)) -eq 0 ] && echo $x
mkdir /cgroup/foo
echo $$ >/cgroup/foo/cgroup.procs
echo trex >pages/$x
echo $$ >/cgroup/cgroup.procs
rmdir /cgroup/foo
  done

When run on an unpatched kernel, we eventually run out of possible IDs
even though there are no visible cgroups:

  [root@ham ~]# ./cssidstress.sh
  [...]
  65000
  mkdir: cannot create directory '/cgroup/foo': No space left on device

After this patch, the IDs get released upon cgroup destruction and the
cache and css objects get released once memory reclaim kicks in.

[han...@cmpxchg.org: init the IDR]
  Link: http://lkml.kernel.org/r/20160621154601.ga22...@cmpxchg.org
Fixes: b2052564e66d ("mm: memcontrol: continue cache reclaim from offlined 
groups")
Link: http://lkml.kernel.org/r/20160617162516.gd19...@cmpxchg.org
Signed-off-by: Johannes Weiner 
Reported-by: John Garcia 
Reviewed-by: Vladimir Davydov 
Acked-by: Tejun Heo 
Cc: Nikolay Borisov 
Cc: [3.19+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Michal Hocko 
---
 include/linux/memcontrol.h |  8 
 mm/memcontrol.c| 95 --
 mm/slab_common.c   |  2 +-
 3 files changed, 85 insertions(+), 20 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index cd0e2413c358..435fd8426b8a 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -174,6 +174,11 @@ struct mem_cgroup_thresholds {
struct mem_cgroup_threshold_ary *spare;
 };
 
+struct mem_cgroup_id {
+   int id;
+   atomic_t ref;
+};
+
 /*
  * The memory controller data structure. The memory controller controls both
  * page cache and RSS per cgroup. We would eventually like to provide
@@ -183,6 +188,9 @@ struct mem_cgroup_thresholds {
 struct mem_cgroup {
struct cgroup_subsys_state css;
 
+   /* Private memcg ID. Used to ID objects that outlive the cgroup */
+   struct mem_cgroup_id id;
+
/* Accounted resources */
struct page_counter memory;
struct page_counter memsw;
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 67648e6b2ac8..b148c1eecc98 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -272,21 +272,7 @@ static inline bool mem_cgroup_is_root(struct mem_cgroup 
*memcg)
 
 static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg)
 {
-   return memcg->css.id;
-}
-
-/*
- * A helper function to get mem_cgroup from ID. must be called under
- * rcu_read_lock().  The caller is responsible for calling
- * css_tryget_online() if the mem_cgroup is used for charging. (dropping
- * refcnt from swap can be called against removed memcg.)
- */
-static inline struct mem_cgroup *mem_cgroup_from_id(unsigned short id)
-{
-   struct cgroup_subsys_state *css;
-
-   css = css_from_id(id, &memory_cgrp_subsys);
-   return mem_cgroup_from_css(css);
+   return memcg->id.id;
 }
 
 /* Writing them here to avoid exposing memcg's inner layout */
@@ -4124,6 +4110,60 @@ static struct cftype mem_cgroup_legacy_files[] = {
{ },/* terminate */
 };
 
+/*
+ * Private memory cgroup IDR
+ *
+ * Swap-out records and page cache shadow entries need to store memcg
+ * references in constrained space, so we maintain an ID space that is
+ * limited to 16 bit (MEM_CGROUP_ID_MAX), limiting the total number of
+ * memory-controlled cgroups to 64k.
+

[PATCH stable-4.4 2/3] mm: memcontrol: fix swap counter leak on swapout from offline cgroup

[Michal Hocko]

From: Vladimir Davydov 

commit 1f47b61fb4077936465dcde872a4e5cc4fe708da upstream.

An offline memory cgroup might have anonymous memory or shmem left
charged to it and no swap.  Since only swap entries pin the id of an
offline cgroup, such a cgroup will have no id and so an attempt to
swapout its anon/shmem will not store memory cgroup info in the swap
cgroup map.  As a result, memcg->swap or memcg->memsw will never get
uncharged from it and any of its ascendants.

Fix this by always charging swapout to the first ancestor cgroup that
hasn't released its id yet.

[han...@cmpxchg.org: add comment to mem_cgroup_swapout]
[vdavy...@virtuozzo.com: use WARN_ON_ONCE() in mem_cgroup_id_get_online()]
  Link: http://lkml.kernel.org/r/20160803123445.GJ13263@esperanza
Fixes: 73f576c04b941 ("mm: memcontrol: fix cgroup creation failure after many 
small jobs")
Link: 
http://lkml.kernel.org/r/5336daa5c9a32e776067773d9da655d2dc126491.1470219853.git.vdavy...@virtuozzo.com
Signed-off-by: Vladimir Davydov 
Acked-by: Johannes Weiner 
Acked-by: Michal Hocko 
Cc: [3.19+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Michal Hocko 
---
 mm/memcontrol.c | 37 +
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b148c1eecc98..dd6e2d24d9b1 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4141,6 +4141,24 @@ static void mem_cgroup_id_get(struct mem_cgroup *memcg)
atomic_inc(&memcg->id.ref);
 }
 
+static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
+{
+   while (!atomic_inc_not_zero(&memcg->id.ref)) {
+   /*
+* The root cgroup cannot be destroyed, so it's refcount must
+* always be >= 1.
+*/
+   if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
+   VM_BUG_ON(1);
+   break;
+   }
+   memcg = parent_mem_cgroup(memcg);
+   if (!memcg)
+   memcg = root_mem_cgroup;
+   }
+   return memcg;
+}
+
 static void mem_cgroup_id_put(struct mem_cgroup *memcg)
 {
if (atomic_dec_and_test(&memcg->id.ref)) {
@@ -5723,7 +5741,7 @@ subsys_initcall(mem_cgroup_init);
  */
 void mem_cgroup_swapout(struct page *page, swp_entry_t entry)
 {
-   struct mem_cgroup *memcg;
+   struct mem_cgroup *memcg, *swap_memcg;
unsigned short oldid;
 
VM_BUG_ON_PAGE(PageLRU(page), page);
@@ -5738,16 +5756,27 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t 
entry)
if (!memcg)
return;
 
-   mem_cgroup_id_get(memcg);
-   oldid = swap_cgroup_record(entry, mem_cgroup_id(memcg));
+   /*
+* In case the memcg owning these pages has been offlined and doesn't
+* have an ID allocated to it anymore, charge the closest online
+* ancestor for the swap instead and transfer the memory+swap charge.
+*/
+   swap_memcg = mem_cgroup_id_get_online(memcg);
+   oldid = swap_cgroup_record(entry, mem_cgroup_id(swap_memcg));
VM_BUG_ON_PAGE(oldid, page);
-   mem_cgroup_swap_statistics(memcg, true);
+   mem_cgroup_swap_statistics(swap_memcg, true);
 
page->mem_cgroup = NULL;
 
if (!mem_cgroup_is_root(memcg))
page_counter_uncharge(&memcg->memory, 1);
 
+   if (memcg != swap_memcg) {
+   if (!mem_cgroup_is_root(swap_memcg))
+   page_counter_charge(&swap_memcg->memsw, 1);
+   page_counter_uncharge(&memcg->memsw, 1);
+   }
+
/*
 * Interrupts should be disabled here because the caller holds the
 * mapping->tree_lock lock which is taken with interrupts-off. It is
-- 
2.8.1

Re: [PATCH RESEND v2 1/3] dt: bindings: add bindings for Allwinner A64 usb phy

[Kishon Vijay Abraham I]

On Friday 12 August 2016 08:36 AM, Icenowy Zheng wrote:
> Signed-off-by: Icenowy Zheng 

Added "Update sun4i usb phy dt binding documentation to include support for
Allwinner A64 usb phy." and then merged this.

Thanks
Kishon

> ---
>  Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
> b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 95736d7..287150d 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -10,6 +10,7 @@ Required properties:
>* allwinner,sun8i-a23-usb-phy
>* allwinner,sun8i-a33-usb-phy
>* allwinner,sun8i-h3-usb-phy
> +  * allwinner,sun50i-a64-usb-phy
>  - reg : a list of offset + length pairs
>  - reg-names :
>* "phy_ctrl"
> 

Re: [RFCv3 2/2] perf: util: support sysfs supported_cpumask file

[Jiri Olsa]

On Thu, Aug 11, 2016 at 05:36:06PM +0100, Mark Rutland wrote:
> The perf tools can read a cpumask file for a PMU, describing a subset of
> CPUs which that PMU covers. So far this has only been used to cater for
> uncore PMUs, which in practice happen to only have a single CPU
> described in the mask.
> 
> Until recently, the perf tools only correctly handled cpumask containing
> a single CPU, and only when monitoring in system-wide mode. For example,
> prior to commit 00e727bb389359c8 ("perf stat: Balance opening and
> reading events"), a mask with more than a single CPU could cause
> perf stat to hang. When a CPU PMU covers a subset of CPUs, but lacks a
> cpumask, perf record will fail to open events (on the cores the PMU does
> not support), and gives up.
> 
> For systems with heterogeneous CPUs such as ARM big.LITTLE systems, this
> presents a problem. We have a PMU for each microarchitecture (e.g. a big
> PMU and a little PMU), and would like to expose a cpumask for each (so
> as to allow perf record and other tools to do the right thing). However,
> doing so kernel-side will cause old perf binaries to not function (e.g.
> hitting the issue solved by 00e727bb389359c8), and thus commits the
> cardinal sin of breaking (existing) userspace.
> 
> To address this chicken-and-egg problem, this patch adds support got a
> new file, supported_cpumask, which is largely identical to the existing
> cpumask file. A kernel can expose this file, knowing that new perf
> binaries will correctly support it, while old perf binaries will not
> look for it (and thus will not be broken).

I might have asked before, but what's the kernel side state of this?

thanks,
jirka

[PATCH 2/2] be2iscsi: Fix some error messages

[Christophe JAILLET]

This fixes:
   - missing spaces in string split on several lines
   - extra spaces after ':'
   - missing '\n' at the end of some messages
   - too long lines

Signed-off-by: Christophe JAILLET 
---
 drivers/scsi/be2iscsi/be_main.c | 83 +
 1 file changed, 43 insertions(+), 40 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 89ae6390b697..415c21ec6a13 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -268,7 +268,7 @@ static int beiscsi_eh_abort(struct scsi_cmnd *sc)
&nonemb_cmd.dma);
if (nonemb_cmd.va == NULL) {
beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_EH,
-   "BM_%d : Failed to allocate memory for"
+   "BM_%d : Failed to allocate memory for "
"mgmt_invalidate_icds\n");
return FAILED;
}
@@ -278,7 +278,7 @@ static int beiscsi_eh_abort(struct scsi_cmnd *sc)
   cid, &nonemb_cmd);
if (!tag) {
beiscsi_log(phba, KERN_WARNING, BEISCSI_LOG_EH,
-   "BM_%d : mgmt_invalidate_icds could not be"
+   "BM_%d : mgmt_invalidate_icds could not be "
"submitted\n");
pci_free_consistent(phba->ctrl.pdev, nonemb_cmd.size,
nonemb_cmd.va, nonemb_cmd.dma);
@@ -350,7 +350,7 @@ static int beiscsi_eh_device_reset(struct scsi_cmnd *sc)
&nonemb_cmd.dma);
if (nonemb_cmd.va == NULL) {
beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_EH,
-   "BM_%d : Failed to allocate memory for"
+   "BM_%d : Failed to allocate memory for "
"mgmt_invalidate_icds\n");
return FAILED;
}
@@ -1010,7 +1010,7 @@ static int beiscsi_init_irqs(struct beiscsi_hba *phba)
  &phwi_context->be_eq[i]);
if (ret) {
beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_INIT,
-   "BM_%d : beiscsi_init_irqs-Failed 
to"
+   "BM_%d : beiscsi_init_irqs-Failed 
to "
"register msix for i = %d\n",
i);
kfree(phba->msi_name[i]);
@@ -1168,7 +1168,7 @@ free_io_sgl_handle(struct beiscsi_hba *phba, struct 
sgl_handle *psgl_handle)
 * failed in xmit_task or alloc_pdu.
 */
 beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_IO,
-"BM_%d : Double Free in IO SGL 
io_sgl_free_index=%d,"
+"BM_%d : Double Free in IO SGL 
io_sgl_free_index=%d, "
 "value there=%p\n", phba->io_sgl_free_index,
 phba->io_sgl_hndl_base
 [phba->io_sgl_free_index]);
@@ -1256,7 +1256,7 @@ free_wrb_handle(struct beiscsi_hba *phba, struct 
hwi_wrb_context *pwrb_context,
   phba->params.wrbs_per_cxn);
beiscsi_log(phba, KERN_INFO,
BEISCSI_LOG_IO | BEISCSI_LOG_CONFIG,
-   "BM_%d : FREE WRB: pwrb_handle=%p free_index=0x%x"
+   "BM_%d : FREE WRB: pwrb_handle=%p free_index=0x%x "
"wrb_handles_available=%d\n",
pwrb_handle, pwrb_context->free_index,
pwrb_context->wrb_handles_available);
@@ -1293,7 +1293,7 @@ free_mgmt_sgl_handle(struct beiscsi_hba *phba, struct 
sgl_handle *psgl_handle)
 {
spin_lock_bh(&phba->mgmt_sgl_lock);
beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_CONFIG,
-   "BM_%d : In  free_mgmt_sgl_handle,"
+   "BM_%d : In  free_mgmt_sgl_handle, "
"eh_sgl_free_index=%d\n",
phba->eh_sgl_free_index);
 
@@ -1303,7 +1303,7 @@ free_mgmt_sgl_handle(struct beiscsi_hba *phba, struct 
sgl_handle *psgl_handle)
 * failed in xmit_task or alloc_pdu.
 */
beiscsi_log(phba, KERN_WARNING, BEISCSI_LOG_CONFIG,
-   "BM_%d : Double Free in eh SGL ,"
+   "BM_%d : Double Free in eh SGL, "
"eh_sgl_free_index=%d\n",
phba->eh_sgl_free_index);
spin_unlock_bh(&phba->mgmt_sgl_lock);
@@ -1604,7 +1604,7 @@ static void hwi_complete_cmd(struct beiscsi_conn 
*beiscsi_conn,
default:
beiscsi_log(phba, KERN_WARNING,
BEISCSI_LOG_CONFIG | BEISCSI_LOG_IO,
-   "BM_%d : In hwi_complete_cmd, unknown type = %d"
+   "BM_%d : 

Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression

[Dave Chinner]

On Fri, Aug 12, 2016 at 04:51:24PM +0800, Ye Xiaolong wrote:
> On 08/12, Ye Xiaolong wrote:
> >On 08/12, Dave Chinner wrote:
> 
> [snip]
> 
> >>lkp-folk: the patch I've just tested it attached below - can you
> >>feed that through your test and see if it fixes the regression?
> >>
> >
> >Hi, Dave
> >
> >I am verifying your fix patch in lkp environment now, will send the
> >result once I get it.
> >
> 
> Here is the test result.

Which says "no change". Oh well, back to the drawing board...

Can you send me the aim7 config file and command line you are using
for the test?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

[PATCH 1/2] be2iscsi: Fix error return code

[Christophe JAILLET]

We know that 'ret' is not an error code because it has been tested a few
lines above.
So, if one of these function fails, 0 will be returned instead of an error
code.
Return -ENOMEM instead.

Signed-off-by: Christophe JAILLET 
---
 drivers/scsi/be2iscsi/be_main.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index f05e7737107d..89ae6390b697 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -3286,8 +3286,10 @@ static int beiscsi_create_eqs(struct beiscsi_hba *phba,
eq_vaddress = pci_alloc_consistent(phba->pcidev,
 num_eq_pages * PAGE_SIZE,
 &paddr);
-   if (!eq_vaddress)
+   if (!eq_vaddress) {
+   ret = -ENOMEM;
goto create_eq_error;
+   }
 
mem->va = eq_vaddress;
ret = be_fill_queue(eq, phba->params.num_eq_entries,
@@ -3349,8 +3351,11 @@ static int beiscsi_create_cqs(struct beiscsi_hba *phba,
cq_vaddress = pci_alloc_consistent(phba->pcidev,
 num_cq_pages * PAGE_SIZE,
 &paddr);
-   if (!cq_vaddress)
+   if (!cq_vaddress) {
+   ret = -ENOMEM;
goto create_cq_error;
+   }
+
ret = be_fill_queue(cq, phba->params.num_cq_entries,
sizeof(struct sol_cqe), cq_vaddress);
if (ret) {
@@ -5635,6 +5640,7 @@ static int beiscsi_dev_probe(struct pci_dev *pcidev,
if (!phba) {
dev_err(&pcidev->dev,
"beiscsi_dev_probe - Failed in beiscsi_hba_alloc\n");
+   ret = -ENOMEM;
goto disable_pci;
}
 
@@ -5754,6 +5760,7 @@ static int beiscsi_dev_probe(struct pci_dev *pcidev,
beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_INIT,
"BM_%d : beiscsi_dev_probe-"
"Failed to allocate work queue\n");
+   ret = -ENOMEM;
goto free_twq;
}
 
-- 
2.7.4


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: [PATCH 07/11 v2] phy: qcom-ufs: use of_property_read_bool

[Kishon Vijay Abraham I]

On Friday 05 August 2016 04:55 PM, Julia Lawall wrote:
> Use of_property_read_bool to check for the existence of a property.
> 
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> expression e1,e2,x;
> @@
> - if (of_get_property(e1,e2,NULL))
> - x = true;
> - else
> - x = false;
> + x = of_property_read_bool(e1,e2);
> // 
> 
> Signed-off-by: Julia Lawall 

merged, thanks.

-Kishon
> 
> ---
> v2: special case for propagating true and false
> 
>  drivers/phy/phy-qcom-ufs.c |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
> index 107cb57..18a5b49 100644
> --- a/drivers/phy/phy-qcom-ufs.c
> +++ b/drivers/phy/phy-qcom-ufs.c
> @@ -283,10 +283,8 @@ static int __ufs_qcom_phy_init_vreg(struct phy *phy,
>   err = 0;
>   }
>   snprintf(prop_name, MAX_PROP_NAME, "%s-always-on", name);
> - if (of_get_property(dev->of_node, prop_name, NULL))
> - vreg->is_always_on = true;
> - else
> - vreg->is_always_on = false;
> + vreg->is_always_on = of_property_read_bool(dev->of_node,
> +prop_name);
>   }
> 
>   if (!strcmp(name, "vdda-pll")) {
> 

Re: kmemleak: Cannot insert 0xff7f1000 into the object search tree (overlaps existing)

[Catalin Marinas]

On Fri, Aug 12, 2016 at 09:45:05AM +0530, Vignesh R wrote:
> On Thursday 11 August 2016 10:38 PM, Catalin Marinas wrote:
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 483197ef613f..7d3361d53ac2 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -723,7 +723,8 @@ int __init_memblock memblock_free(phys_addr_t base, 
> > phys_addr_t size)
> >  (unsigned long long)base + size - 1,
> >  (void *)_RET_IP_);
> >  
> > -   kmemleak_free_part(__va(base), size);
> > +   if (base < __pa(high_memory))
> > +   kmemleak_free_part(__va(base), size);
> > return memblock_remove_range(&memblock.reserved, base, size);
> >  }
> >  
> > @@ -1152,7 +1153,8 @@ static phys_addr_t __init 
> > memblock_alloc_range_nid(phys_addr_t size,
> >  * The min_count is set to 0 so that memblock allocations are
> >  * never reported as leaks.
> >  */
> > -   kmemleak_alloc(__va(found), size, 0, 0);
> > +   if (found < __pa(high_memory))
> > +   kmemleak_alloc(__va(found), size, 0, 0);
> > return found;
> > }
> > return 0;
> > @@ -1399,7 +1401,8 @@ void __init __memblock_free_early(phys_addr_t base, 
> > phys_addr_t size)
> > memblock_dbg("%s: [%#016llx-%#016llx] %pF\n",
> >  __func__, (u64)base, (u64)base + size - 1,
> >  (void *)_RET_IP_);
> > -   kmemleak_free_part(__va(base), size);
> > +   if (base < __pa(high_memory))
> > +   kmemleak_free_part(__va(base), size);
> > memblock_remove_range(&memblock.reserved, base, size);
> >  }
> >  
> > @@ -1419,7 +1422,8 @@ void __init __memblock_free_late(phys_addr_t base, 
> > phys_addr_t size)
> > memblock_dbg("%s: [%#016llx-%#016llx] %pF\n",
> >  __func__, (u64)base, (u64)base + size - 1,
> >  (void *)_RET_IP_);
> > -   kmemleak_free_part(__va(base), size);
> > +   if (base < __pa(high_memory))
> > +   kmemleak_free_part(__va(base), size);
> > cursor = PFN_UP(base);
> > end = PFN_DOWN(base + size);
> 
> With above change on 4.8-rc1, I see a different warning from kmemleak:
> 
> [0.002918] kmemleak: Trying to color unknown object at 0xfe80 as
> Black
> [0.002943] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 4.8.0-rc1-00121-g4b9eaf33d83d-dirty #59
> [0.002955] Hardware name: Generic AM33XX (Flattened Device Tree)
> [0.003000] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [0.003027] [] (show_stack) from [] 
> (dump_stack+0xac/0xe0)
> [0.003052] [] (dump_stack) from [] 
> (paint_ptr+0x78/0x9c)
> [0.003074] [] (paint_ptr) from [] 
> (kmemleak_init+0x1cc/0x284)
> [0.003104] [] (kmemleak_init) from [] 
> (start_kernel+0x2d8/0x3b4)
> [0.003122] [] (start_kernel) from [<8000807c>] (0x8000807c)
> [0.003133] kmemleak: Early log backtrace:
> [0.003146][] dma_contiguous_reserve+0x80/0x94
> [0.003170][] arm_memblock_init+0x130/0x184
> [0.003191][] setup_arch+0x58c/0xc00
> [0.003208][] start_kernel+0x58/0x3b4
> [0.003224][<8000807c>] 0x8000807c
> [0.003239][] 0x

That's because I missed the CMA kmemleak call:

diff --git a/mm/cma.c b/mm/cma.c
index bd0e1412475e..7c0ef3037415 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -336,7 +336,8 @@ int __init cma_declare_contiguous(phys_addr_t base,
 * kmemleak scans/reads tracked objects for pointers to other
 * objects but this address isn't mapped and accessible
 */
-   kmemleak_ignore(phys_to_virt(addr));
+   if (addr < __pa(high_memory))
+   kmemleak_ignore(phys_to_virt(addr));
base = addr;
}
 

Anyway, a better workaround is to add kmemleak_*_phys() static inline
functions and do the __pa(high_memory) check in there:

-8<---
>From b8b9141fffc1fd3c73583c1fd50a724c4a6452e1 Mon Sep 17 00:00:00 2001
From: Catalin Marinas 
Date: Fri, 12 Aug 2016 10:43:06 +0100
Subject: [PATCH] mm: kmemleak: Avoid using __va() on addresses that don't have
 a lowmem mapping

Some of the kmemleak_*() callbacks in memblock, bootmem, CMA convert a
physical address to a virtual one using __va(). However, such physical
addresses may sometimes be located in highmem and using __va() is
incorrect, leading to inconsistent object tracking in kmemleak.

The following functions have been added to the kmemleak API and they
take a physical address as the object pointer. They only perform the
corresponding action if the address has a lowmem mapping:

kmemleak_alloc_phys
kmemleak_free_part_phys
kmemleak_not_leak_phys
kmemleak_ignore_phys

The affected calling placess have been updated to use the new kmemleak
API.

Reported-by: Vignesh R 
Signed-off-by: Catalin Marinas 
---
 Documentation/kmemleak.txt |  9 +
 include/linux/kmemleak.h   | 26 ++
 mm/bootmem.c   |  

[PATCH v1] power: reset: reboot mode: fix build error of missing ioremap/iounmap on UM

[Andy Yan]

commit 4fcd504edbf7 ("power: reset: add reboot mode driver") uses api from
syscon, and syscon uses ioremap/iounmap which depends on HAS_IOMEM, so
let's depend on MFD_SYSCON instead of selecting it directly to avoid the
um-allyesconfig like build error on archs that without iomem:

drivers/mfd/syscon.c: In function 'of_syscon_register':
drivers/mfd/syscon.c:67:9: error: implicit declaration of function 'ioremap' 
[-Werror=implicit-function-declaration]
  base = ioremap(res.start, resource_size(&res));
 ^
drivers/mfd/syscon.c:67:7: warning: assignment makes pointer from integer 
without a cast [-Wint-conversion]
  base = ioremap(res.start, resource_size(&res));
   ^
drivers/mfd/syscon.c:109:2: error: implicit declaration of function 'iounmap' 
[-Werror=implicit-function-declaration]
  iounmap(base);
  ^

Reported-by: Kbuild test robot 
Fixes: 4fcd504edbf7("power: reset: add reboot mode driver")
Signed-off-by: Andy Yan 

---

Changes in v1:
- let this driver depend on MFD_SYSCON
- add Reported-by tag, which suggested by Krzysztof Kozlowski
- add Fixes tag, which suggested by Matthias Brugger

 drivers/power/reset/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 7053abc..10f8ddb 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -190,8 +190,8 @@ config REBOOT_MODE
 config SYSCON_REBOOT_MODE
tristate "Generic SYSCON regmap reboot mode driver"
depends on OF
+   depends on MFD_SYSCON
select REBOOT_MODE
-   select MFD_SYSCON
help
  Say y here will enable reboot mode driver. This will
  get reboot mode arguments and store it in SYSCON mapped
-- 
2.7.4

Re: [PATCH] Documentation: add support for V4L touch devices

[Hans Verkuil]

Hi Nick,

On 07/18/2016 11:11 PM, y...@shmanahar.org wrote:
> From: Nick Dyer 
> 
> Signed-off-by: Nick Dyer 

I'm missing documentation for the new V4L2_CAP_TOUCH capability and the
V4L2_INPUT_TYPE_TOUCH define.

> diff --git a/Documentation/media/uapi/v4l/pixfmt-tch-tu08.rst 
> b/Documentation/media/uapi/v4l/pixfmt-tch-tu08.rst
> new file mode 100644
> index 000..32e21f8
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-tch-tu08.rst
> @@ -0,0 +1,78 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _V4L2-TCH-FMT-DELTA-TU08:

The -DELTA part should be removed here and in tu16.rst.

> +
> +**
> +V4L2_TCH_FMT_DELTA_TU08 ('TU08')
> +**
> +
> +*man V4L2_TCH_FMT_DELTA_TU08(2)*

Ditto.

Regards,

Hans

Re: [PATCH] SAS: use sas_rphy instead of sas_end_device to obtain address.

[Johannes Thumshirn]

On Thu, Aug 11, 2016 at 11:00:07AM -0700, James Bottomley wrote:
> On Thu, 2016-08-11 at 18:43 +0200, Johannes Thumshirn wrote:
> > On Thu, Aug 11, 2016 at 08:09:35AM -0700, James Bottomley wrote:
> > > On Thu, 2016-08-11 at 09:59 +0200, Johannes Thumshirn wrote:
> > > > Since commit 3f8d6f2a0 ('ses: fix discovery of SATA devices in
> > > > SAS
> > > > enclosures') ses_match_to_enclosure() is calling
> > > > sas_get_address(),
> > > > which is coming from commit bcf508c13385 ('scsi_transport_sas:
> > > > add
> > > > function to get SAS endpoint address'). sas_get_address() itself 
> > > > calls sas_sdev_to_rdev() which BUG_ON()s if a given scsi_device's
> > > > rphy is not a SAS_END_DEVICE.
> > > 
> > > Is the BUG_ON the problem?  you're supposed to gate this call with
> > > is_sas_attached().
> > > 
> > > > As SAS Enclosure is a SAS expander device,
> > > 
> > > This isn't necessarily true.  There are several separated enclosure
> > > chips even in the SAS world (although most of the new ones are
> > > integrated).
> > 
> > Maybe change it to "As a SAS enclosure can be a SAS expander device,
> > [..]"
> > 
> > > 
> > > >  we really shouldn't tie the lookup of a SAS address to the SAS
> > > > End
> > > > Device but the sas_rphy, which holds the address information.
> > > 
> > > This is conceptually wrong.  A wide end device may have many rphys
> > > forming a port.  In that case the end device address is likely to
> > > be
> > > only one of the rphy addresses ... how do you know this code picks
> > > the
> > > right one?
> > > 
> > > > Fixes: 3f8d6f2a0 ('ses: fix discovery of SATA devices in SAS
> > > > enclosures')
> > > > Cc: sta...@vger.kernel.org # v4.5+
> > > 
> > > What's the actual bug being fixed here?
> > 
> > This is the callchain I have:
> > 
> > ses_init()
> > `-> scsi_register_interface()
> > `-> class_interface_register()
> > `-> ses_intf_add()
> > `-> ses_match_to_enclosure()
> > `-> sas_get_address()
> > `-> sas_sdev_to_rdev()
> > `-> BUG_ON(rphy->identify.device_type !=
> > SAS_END_DEVICE);
> > `-> KABOOM, Bug report, yelling release
> > manager, etc..
> 
> So what is at the end?  is_sas_attached() indicates the transport class
> attached to something and that something generated an sdev ... that can
> only happen I think if that something is an end device.

sas_get_address() in ses_match_to_enclosure() _is_ guarded by
is_sas_attached(), so it probably can not only happen if that
something is an end device or the BUG_ON() wouldn't fire.

> 
> > Unfortunately I do not have a SAS enclosure here so all I could do 
> > was read the spec and code and have the customer test the patch.
> > 
> > But from my git archeology:
> > Since 3f8d6f2a0 sas_match_to_enclosure() is calling
> > sas_get_address(). Which in turn is calling sas_sdev_to_rdev() and so
> > on...
> > 
> > The thing is, in sas_get_address() we want to get the address of a 
> > sas device, don't we? And looking at the UML diagram in the SAS spec, 
> > we see an enclosure as well as an end device do have a rphy attached 
> > to it, which in turn has a SAS address.
> 
> Because, as I said in the previous reply, the rphy is only the sas
> address for non-wide ports.  They phy layer is just above the physical
> layer.  The end device sits at the application layer, which is four
> layers above that. Whatever diagram you're looking at is probably
> showing port layer connections.  The way the transport class works is
> that each rphy, even when part of a formed wide port, is individually
> addressable, so we can send SMP phy controls to it, but the device is
> separately addressable by its own SAS address.

Ok, we can't use the rphy because of wide-ports. We can't fix it to an
end device either, as this makes some peoples systems unbootable. Now
let's find a third option satisfying the needs of SAS wide-ports and
my customers (and others running 4.5+ with a SAS enclosure).

I'm digging...

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[PATCH] befs: return BEFS_ERR if validation of ag_shift fails

[Salah Triki]

ag_shift is used by blockno2iaddr() to get allocation group number
from block. If ag_shift is inconsistent with block_per_ag, an out of
bounds allocation group may occur [1]. So add return BEFS_ERR and update
comment and error message to reflect this change.

[1] https://lkml.org/lkml/2016/8/12/42

Signed-off-by: Salah Triki 
---
 fs/befs/super.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/fs/befs/super.c b/fs/befs/super.c
index 7c50025..2e3a3fd 100644
--- a/fs/befs/super.c
+++ b/fs/befs/super.c
@@ -101,10 +101,13 @@ befs_check_sb(struct super_block *sb)
 
 
/* ag_shift also encodes the same information as blocks_per_ag in a
-* different way, non-fatal consistency check
+* different way as a consistency check.
 */
-   if ((1 << befs_sb->ag_shift) != befs_sb->blocks_per_ag)
-   befs_error(sb, "ag_shift disagrees with blocks_per_ag.");
+   if ((1 << befs_sb->ag_shift) != befs_sb->blocks_per_ag) {
+   befs_error(sb, "ag_shift disagrees with blocks_per_ag. "
+  "Corruption likely.");
+   return BEFS_ERR;
+   }
 
if (befs_sb->log_start != befs_sb->log_end ||
befs_sb->flags == BEFS_DIRTY) {
-- 
1.9.1

Re: [PATCH 2/2] KVM: nVMX: postpone VMCS changes on MSR_IA32_APICBASE write

[Wanpeng Li]

2016-08-12 17:44 GMT+08:00 Radim Krčmář :
> 2016-08-12 14:07+0800, Wanpeng Li:
>> 2016-08-09 2:16 GMT+08:00 Radim Krčmář :
>>> If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the
>>> write with vmcs02 as the current VMCS.
>>> This will incorrectly apply modifications intended for vmcs01 to vmcs02
>>> and L2 can use it to gain access to L0's x2APIC registers by disabling
>>> virtualized x2APIC while using msr bitmap that assumes enabled.
>>>
>>> Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the
>>> current VMCS.  An alternative solution would temporarily make vmcs01 the
>>> current VMCS, but it requires more care.
>>
>> There is a scenario both L1 and L2 are running on x2apic mode, L1
>> don't own the APIC_BASE writes, then L2 is intended to disable x2apic
>> mode, however, your logic will also disable x2apic mode for L1.
>
> You mean a case where L1 does intercept APIC_BASE?
>
> That case is not affected, because it should cause a nested VM exit, so
> vmx_set_virtual_x2apic_mode() won't be called in the first place.

I mean L1 doesn't intercept APIC_BASE.

Regards,
Wanpeng Li

Re: [PATCH 1/4] befs: check allocation_group number before use

[Salah Triki]

On Fri, Aug 12, 2016 at 10:38:58AM +0100, Luis de Bethencourt wrote:
> On 12/08/16 08:26, Salah Triki wrote:
> > On Thu, Aug 11, 2016 at 11:56:16AM +0100, Luis de Bethencourt wrote:
> >> On 10/08/16 23:12, Salah Triki wrote:
> >>> Check that the allocation group number is not greater or equal to the
> >>> number of allocations group in the file system and return BEF_ERR in the
> >>> case of error.
> >>>
> >>> Signed-off-by: Salah Triki 
> >>> ---
> >>>  fs/befs/befs.h | 5 +
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/fs/befs/befs.h b/fs/befs/befs.h
> >>> index 55f3ea2..6daf4c4 100644
> >>> --- a/fs/befs/befs.h
> >>> +++ b/fs/befs/befs.h
> >>> @@ -121,6 +121,11 @@ BEFS_I(const struct inode *inode)
> >>>  static inline befs_blocknr_t
> >>>  iaddr2blockno(struct super_block *sb, const befs_inode_addr *iaddr)
> >>>  {
> >>> + if (iaddr->allocation_group >= BEFS_SB(sb)->num_ags) {
> >>> + befs_error(sb, "BEFS: Invalid allocation group %u, max is %u",
> >>> +iaddr->allocation_group, BEFS_SB(sb)->num_ags);
> >>> + return BEFS_ERR;
> >>> + }
> >>>   return ((iaddr->allocation_group << BEFS_SB(sb)->ag_shift) +
> >>>   iaddr->start);
> >>>  }
> >>>
> >>
> >> Hi Salah,
> >>
> >> To understand why would we check for this. When can this error happen? I 
> >> mean,
> >> when can iaddr2blockno() be called with an out of bounds allocation group?
> >>
> >> Thanks,
> >> Luis
> > 
> > Hi Luis,
> > 
> > allocation group number is set to blockno >> BEFS_SB(sb)->ag_shift by 
> > blockno2iaddr(), so if ag_shift is not valid, an out of bound may occur. 
> > By now, thanx to your question ;), I think it's better to check the 
> > validity 
> > of ag_shift when the superblock is loaded.
> > 
> > Nack.
> > 
> > Thanx for the question :)
> > Salah 
> > 
> 
> No problem :)
> 
> I will assume the Nack covers patch 1 to 3. Since they are all related.
> 
> Enjoy the weekend,
> Luis

You too.
Salah

Re: [PATCH v9 2/4] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

[Kishon Vijay Abraham I]

Hi,

On Friday 22 July 2016 12:30 PM, Frank Wang wrote:
> The newer SoCs (rk3366, rk3399) take a different usb-phy IP block
> than rk3288 and before, and most of phy-related registers are also
> different from the past, so a new phy driver is required necessarily.
> 
> Signed-off-by: Frank Wang 
> Suggested-by: Heiko Stuebner 
> Suggested-by: Guenter Roeck 
> Suggested-by: Doug Anderson 
> Reviewed-by: Heiko Stuebner 
> Reviewed-by: Guenter Roeck 
> ---
> 
> Changes in v9:
>  - Add "Reviewed-by" info.
> 
> Changes in v8:
>  - Added support for rk3399 SoC.
>  - Prepare input clock of phy at probe time.
>  - Improved sm_work function to handle phy-port state more clearly.
> 
> Changes in v7:
>  - renamed functions *usb2phy_resume/*usb2phy_suspend to 
> *usb2phy_power_on/usb2phy_power_off.
> 
> Changes in v6:
>  - Fixed the output clock would be disabled more than once while phy-port was 
> going to suspend.
>  - Improved the driver to avoid the currently empty otg-port would cause 
> null-pointer dereferences.
> 
> Changes in v5:
>  - Added 'reg' in the data block to match the different phy-blocks in dt.
> 
> Changes in v4:
>  - Removed some processes related to 'vbus_host-supply'.
> 
> Changes in v3:
>  - Resolved the mapping defect between fixed value in driver and the property
>in devicetree.
>  - Optimized 480m output clock register function.
>  - Code cleanup.
> 
> Changes in v2:
>  - Changed vbus_host operation from gpio to regulator in *_probe.
>  - Improved the fault treatment relate to 480m clock register.
>  - Cleaned up some meaningless codes in *_clk480m_disable.
>  - made more clear the comment of *_sm_work.
> 
>  drivers/phy/Kconfig  |7 +
>  drivers/phy/Makefile |1 +
>  drivers/phy/phy-rockchip-inno-usb2.c |  707 
> ++
>  3 files changed, 715 insertions(+)
>  create mode 100644 drivers/phy/phy-rockchip-inno-usb2.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index b869b98..29ef15c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -347,6 +347,13 @@ config PHY_ROCKCHIP_USB
>   help
> Enable this to support the Rockchip USB 2.0 PHY.
>  
> +config PHY_ROCKCHIP_INNO_USB2
> + tristate "Rockchip INNO USB2PHY Driver"
> + depends on ARCH_ROCKCHIP && OF

changed this to
depends on (ARCH_ROCKCHIP || COMPILE_TEST) && OF
and merged it.

Thanks
Kishon

> + select GENERIC_PHY
> + help
> +   Support for Rockchip USB2.0 PHY with Innosilicon IP block.
> +
>  config PHY_ROCKCHIP_EMMC
>   tristate "Rockchip EMMC PHY Driver"
>   depends on ARCH_ROCKCHIP && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 9c3e73c..4963fbc 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -38,6 +38,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)  += 
> phy-s5pv210-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>  obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)  += phy-qcom-apq8064-sata.o
>  obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o
>  obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o
>  obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
>  obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)  += phy-qcom-ipq806x-sata.o
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c 
> b/drivers/phy/phy-rockchip-inno-usb2.c
> new file mode 100644
> index 000..ac20310
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -0,0 +1,707 @@
> +/*
> + * Rockchip USB2.0 PHY with Innosilicon IP block driver
> + *
> + * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define BIT_WRITEABLE_SHIFT  16
> +#define SCHEDULE_DELAY   (60 * HZ)
> +
> +enum rockchip_usb2phy_port_id {
> + USB2PHY_PORT_OTG,
> + USB2PHY_PORT_HOST,
> + USB2PHY_NUM_PORTS,
> +};
> +
> +enum rockchip_usb2phy_host_state {
> + PHY_STATE_HS_ONLINE = 0,
> + PHY_STATE_DISCONNECT= 1,
> + PHY_STATE_CONNECT   = 2,
> + PHY_STATE_FS_LS_ONLINE  = 4,
> +};
> +
> +struct usb2phy_reg {
> + unsigned intoffset;
> + unsigned intbitend;
> + unsigned intbitstart;
> +

Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons

[Marc Zyngier]

On Thu, 11 Aug 2016 14:23:53 -0700
Bjorn Andersson  wrote:

Hi Bjorn,

> On Thu 11 Aug 05:46 PDT 2016, Marc Zyngier wrote:
> 
> > On 11/08/16 10:47, Jon Hunter wrote:  
> > > 
> > > On 11/08/16 09:37, Marc Zyngier wrote:  
> > >> On 08/08/16 22:48, Linus Walleij wrote:  
> > >>> On Sat, Aug 6, 2016 at 1:45 AM, John Stultz  
> > >>> wrote:
> > >>>  
> >  @@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct
> >  irq_fwspec *fwspec)
> >   * it now and return the interrupt number.
> >   */
> >  if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
> >  -   irq_set_irq_type(virq, type);
> >  +   irq_data = irq_get_irq_data(virq);
> >  +   if (!irq_data)
> >  +   return 0;
> >  +
> >  +   irqd_set_trigger_type(irq_data, type);
> >  return virq;
> >  }
> > 
> >  If I revert just that, it works again.  
> > >>>
> > >>> This makes my platform work too.
> > >>> Tested-by: Linus Walleij   
> > >>
> > >> Hmmm. I'm now booting your kernel on the APQ8060, and reverting this
> > >> hunk doesn't fix it for me. I'm confused...
> > >>
> > >> The interesting part is this:
> > >> 109: 10  0   msmgpio  88 Level (null)  
> > > 
> > > 88 is the pm8058 parent interrupt and so I am surprised you would even
> > > see this in /proc/interrupts as it should be a chained interrupt, right?
> > > 
> > > Are you seeing this with all the ethernet updates for the APQ8060 in
> > > Linus' branch? I am curious what you see with stock v4.8-rc1 and if
> > > interrupts work ok with the change I had proposed. Hard to tell if there
> > > is more than one issue here.  
> > 
> > Nailed the sucker:
> > 
> > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> > index b4c1bc7..9d7284a 100644
> > --- a/kernel/irq/chip.c
> > +++ b/kernel/irq/chip.c
> > @@ -820,6 +820,18 @@ __irq_do_set_handler(struct irq_desc *desc, 
> > irq_flow_handler_t handle,
> > desc->name = name;
> >  
> > if (handle != handle_bad_irq && is_chained) {
> > +   int ret;
> > +
> > +   ret = __irq_set_trigger(desc,
> > +   irqd_get_trigger_type(&desc->irq_data));
> > +   WARN_ON(ret);
> > +   /*
> > +* This is beyond ugly: .set_type may have overridden
> > +* the flow, not not knowing that we're dealing with a
> > +* chained handler. Reset it here because we know
> > +* better.
> > +*/  
> 
> Thanks for this Marc!
> 
> But it makes me (author of pinctrl-msm) wonder, am I supposed to not
> implement .set_type like this for handling the transition between edge
> and level handlers?

You definitely need to implement .set_type and set the flow handler
the way you do it, and there is hardly anything an irqchip driver can do
to detect that case.

The main issue is that as far as the core code is concerned, the
chained handler is just another flow handler. It just happen to be
provided by another irqchip.

We used to call .set_type early, and a driver like yours would set the
flow corresponding to the trigger of the interrupt. Later, the
secondary irqchip would then call irq_set_chained_handler_and_data(),
which would override the flow with the custom one. Now, we call it much
later, after the custom flow handler has been assigned. Kaboom, we
end-up calling the chained_action handler through one of the normal
flows, instead of going into our special flow.

We *could* make irq_set_handler_locked() check for this condition
though (testing for the chained_action pointer), probably at the cost of
un-inlining it.

I'll try to put something together next week, and see what sticks.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.

Re: [PATCH 2/2] be2iscsi: Fix some error messages

[Julia Lawall]

On Fri, 12 Aug 2016, Christophe JAILLET wrote:

> This fixes:
>- missing spaces in string split on several lines
>- extra spaces after ':'
>- missing '\n' at the end of some messages
>- too long lines

I think that the strings should be concatenated, even if they go past 80
chars.  I'm surprised checkpatch didn't complain.

julia

>
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/scsi/be2iscsi/be_main.c | 83 
> +
>  1 file changed, 43 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
> index 89ae6390b697..415c21ec6a13 100644
> --- a/drivers/scsi/be2iscsi/be_main.c
> +++ b/drivers/scsi/be2iscsi/be_main.c
> @@ -268,7 +268,7 @@ static int beiscsi_eh_abort(struct scsi_cmnd *sc)
>   &nonemb_cmd.dma);
>   if (nonemb_cmd.va == NULL) {
>   beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_EH,
> - "BM_%d : Failed to allocate memory for"
> + "BM_%d : Failed to allocate memory for "
>   "mgmt_invalidate_icds\n");
>   return FAILED;
>   }
> @@ -278,7 +278,7 @@ static int beiscsi_eh_abort(struct scsi_cmnd *sc)
>  cid, &nonemb_cmd);
>   if (!tag) {
>   beiscsi_log(phba, KERN_WARNING, BEISCSI_LOG_EH,
> - "BM_%d : mgmt_invalidate_icds could not be"
> + "BM_%d : mgmt_invalidate_icds could not be "
>   "submitted\n");
>   pci_free_consistent(phba->ctrl.pdev, nonemb_cmd.size,
>   nonemb_cmd.va, nonemb_cmd.dma);
> @@ -350,7 +350,7 @@ static int beiscsi_eh_device_reset(struct scsi_cmnd *sc)
>   &nonemb_cmd.dma);
>   if (nonemb_cmd.va == NULL) {
>   beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_EH,
> - "BM_%d : Failed to allocate memory for"
> + "BM_%d : Failed to allocate memory for "
>   "mgmt_invalidate_icds\n");
>   return FAILED;
>   }
> @@ -1010,7 +1010,7 @@ static int beiscsi_init_irqs(struct beiscsi_hba *phba)
> &phwi_context->be_eq[i]);
>   if (ret) {
>   beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_INIT,
> - "BM_%d : beiscsi_init_irqs-Failed 
> to"
> + "BM_%d : beiscsi_init_irqs-Failed 
> to "
>   "register msix for i = %d\n",
>   i);
>   kfree(phba->msi_name[i]);
> @@ -1168,7 +1168,7 @@ free_io_sgl_handle(struct beiscsi_hba *phba, struct 
> sgl_handle *psgl_handle)
>* failed in xmit_task or alloc_pdu.
>*/
>beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_IO,
> -  "BM_%d : Double Free in IO SGL 
> io_sgl_free_index=%d,"
> +  "BM_%d : Double Free in IO SGL 
> io_sgl_free_index=%d, "
>"value there=%p\n", phba->io_sgl_free_index,
>phba->io_sgl_hndl_base
>[phba->io_sgl_free_index]);
> @@ -1256,7 +1256,7 @@ free_wrb_handle(struct beiscsi_hba *phba, struct 
> hwi_wrb_context *pwrb_context,
>  phba->params.wrbs_per_cxn);
>   beiscsi_log(phba, KERN_INFO,
>   BEISCSI_LOG_IO | BEISCSI_LOG_CONFIG,
> - "BM_%d : FREE WRB: pwrb_handle=%p free_index=0x%x"
> + "BM_%d : FREE WRB: pwrb_handle=%p free_index=0x%x "
>   "wrb_handles_available=%d\n",
>   pwrb_handle, pwrb_context->free_index,
>   pwrb_context->wrb_handles_available);
> @@ -1293,7 +1293,7 @@ free_mgmt_sgl_handle(struct beiscsi_hba *phba, struct 
> sgl_handle *psgl_handle)
>  {
>   spin_lock_bh(&phba->mgmt_sgl_lock);
>   beiscsi_log(phba, KERN_INFO, BEISCSI_LOG_CONFIG,
> - "BM_%d : In  free_mgmt_sgl_handle,"
> + "BM_%d : In  free_mgmt_sgl_handle, "
>   "eh_sgl_free_index=%d\n",
>   phba->eh_sgl_free_index);
>
> @@ -1303,7 +1303,7 @@ free_mgmt_sgl_handle(struct beiscsi_hba *phba, struct 
> sgl_handle *psgl_handle)
>* failed in xmit_task or alloc_pdu.
>*/
>   beiscsi_log(phba, KERN_WARNING, BEISCSI_LOG_CONFIG,
> - "BM_%d : Double Free in eh SGL ,"
> + "BM_%d : Double Free in eh SGL, "
>   "eh_sgl_free_index=%d\n",
>   phba->eh_sgl_free_index);
>   spin_unlock_bh(&phba->mgmt_sgl_lock);
> @@ -1604,7 +1604,7 @@ static void hwi_complete_cmd(struct beiscsi_conn 
> *beiscsi_c

Re: [PATCH v2] w1: fix typo in parameter description

[Evgeniy Polyakov]

Hi

11.08.2016, 03:03, "Wei Yongjun" :
> Fix typo in parameter description.
>
> Signed-off-by: Wei Yongjun 

Looks good to me, thank you
Greg, please pull it into your tree

Acked-by: Evgeniy Polyakov 

> ---
> v1 -> v2: make it as one line, comments from Evgeniy Polyakov
> ---
>  drivers/w1/w1.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
> index bb34362..4bd898b 100644
> --- a/drivers/w1/w1.c
> +++ b/drivers/w1/w1.c
> @@ -53,8 +53,7 @@ int w1_max_slave_ttl = 10;
>  module_param_named(timeout, w1_timeout, int, 0);
>  MODULE_PARM_DESC(timeout, "time in seconds between automatic slave 
> searches");
>  module_param_named(timeout_us, w1_timeout_us, int, 0);
> -MODULE_PARM_DESC(timeout, "time in microseconds between automatic slave"
> - " searches");
> +MODULE_PARM_DESC(timeout_us, "time in microseconds between automatic slave 
> searches");
>  /* A search stops when w1_max_slave_count devices have been found in that
>   * search. The next search will start over and detect the same set of devices
>   * on a static 1-wire bus. Memory is not allocated based on this number, just

[PATCH] arm64: defconfig: enable BERLIN_BG4CT pinctrl support

[Jisheng Zhang]

This patch enables pinctrl support required to boot Marvell BG4CT
boards.

Signed-off-by: Jisheng Zhang 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0555b7c..52fff49 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -195,6 +195,7 @@ CONFIG_SPI_QUP=y
 CONFIG_SPI_SPIDEV=m
 CONFIG_SPI_S3C64XX=y
 CONFIG_SPMI=y
+CONFIG_PINCTRL_BERLIN_BG4CT=y
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_PINCTRL_MAX77620=y
 CONFIG_PINCTRL_MSM8916=y
-- 
2.8.1

Re: [PATCH 1/2] genirq: Generic chip: add irq_unmap_generic_chip

[Sebastian Frias]

Hi,

I don't know if somebody has had the time to look at these patches, but if you
have comments (even if related to removing the "fixes" tag if you don't
consider this a fix) please let me know.

Best regards,

Sebastian

On 08/01/2016 04:27 PM, Sebastian Frias wrote:
> Without this patch irq_domain_disassociate() cannot properly release the
> interrupt.
> Indeed, irq_map_generic_chip() checks a bit on 'gc->installed' but said bit
> is never cleared, only set.
> 
> Commit 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
> added irq_map_generic_chip() function and also stated "This lacks a removal
> function for now".
> 
> This commit provides with an implementation of an unmap function that can
> be called by irq_domain_disassociate().
> 
> Fixes: 088f40b7b027 ("genirq: Generic chip: Add linear irq domain support")
> 
> Signed-off-by: Sebastian Frias 
> ---
> 
> This is required by loadable modules requesting IRQs.
> In our case rmmod will perform free_irq() + irq_dispose_mapping().
> Without the unmap call the module cannot request the IRQ after "rmmod"
> because it is marked as "installed" by the first successful "insmod".
> 
> NOTE: While the proposed unmap() function attempts to undo as much things
> as done by the map() function, I did not find a way to undo the following:
> 
> a) irq_gc_init_mask_cache(gc, dgc->gc_flags)
> b) irq_set_lockdep_class(virq, &irq_nested_lock_class)
> c) irq_modify_status(virq, dgc->irq_flags_to_clear, dgc->irq_flags_to_set)
> 
> Feel free to comment on that matter.
> 
> ---
>  kernel/irq/generic-chip.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
> index abd286a..7b464cd 100644
> --- a/kernel/irq/generic-chip.c
> +++ b/kernel/irq/generic-chip.c
> @@ -411,8 +411,34 @@ int irq_map_generic_chip(struct irq_domain *d, unsigned 
> int virq,
>  }
>  EXPORT_SYMBOL_GPL(irq_map_generic_chip);
>  
> +void irq_unmap_generic_chip(struct irq_domain *d, unsigned int virq)
> +{
> + struct irq_data *data = irq_domain_get_irq_data(d, virq);
> + struct irq_domain_chip_generic *dgc = d->gc;
> + struct irq_chip_generic *gc;
> + unsigned int hw_irq = data->hwirq;
> + int chip_idx, irq_idx;
> +
> + if (!d->gc)
> + return;
> +
> + chip_idx = hw_irq / dgc->irqs_per_chip;
> + if (chip_idx >= dgc->num_chips)
> + return;
> + gc = dgc->gc[chip_idx];
> +
> + irq_idx = hw_irq % dgc->irqs_per_chip;
> +
> + clear_bit(irq_idx, &gc->installed);
> + irq_domain_set_info(d, virq, hw_irq,
> + &no_irq_chip, NULL, NULL, NULL, NULL);
> +
> +}
> +EXPORT_SYMBOL_GPL(irq_unmap_generic_chip);
> +
>  struct irq_domain_ops irq_generic_chip_ops = {
>   .map= irq_map_generic_chip,
> + .unmap  = irq_unmap_generic_chip,
>   .xlate  = irq_domain_xlate_onetwocell,
>  };
>  EXPORT_SYMBOL_GPL(irq_generic_chip_ops);
> 

Re: [PATCH v8 10/10] Input: sur40 - use new V4L2 touch input type

[Nick Dyer]

Signed-off-by: Nick Dyer 

On 12 August 2016 10:41:08 BST, Hans Verkuil  wrote:
>Hi Nick,
>
>On 07/18/2016 11:10 PM, Nick Dyer wrote:
>> Support both V4L2_TCH_FMT_TU08 and V4L2_PIX_FMT_GREY for backwards
>> compatibility.
>> 
>> Note: I have not tested these changes (I have no access to the
>hardware)
>> so not signing off.
>
>I can't merge this without your Signed-off. The Signed-off has nothing
>to do with
>whether or not you have tested the code. I'm leaving this out of the
>pull request
>for now.
>
>Regards,
>
>   Hans
>
>> ---
>>  drivers/input/touchscreen/sur40.c |  122
>+++--
>>  1 file changed, 89 insertions(+), 33 deletions(-)
>> 
>> diff --git a/drivers/input/touchscreen/sur40.c
>b/drivers/input/touchscreen/sur40.c
>> index 4ea4757..fc275cb 100644
>> --- a/drivers/input/touchscreen/sur40.c
>> +++ b/drivers/input/touchscreen/sur40.c
>> @@ -139,6 +139,27 @@ struct sur40_image_header {
>>  #define SUR40_GET_STATE   0xc5 /*  4 bytes state (?) */
>>  #define SUR40_GET_SENSORS 0xb1 /*  8 bytes sensors   */
>>  
>> +static const struct v4l2_pix_format sur40_pix_format[] = {
>> +{
>> +.pixelformat = V4L2_TCH_FMT_TU08,
>> +.width  = SENSOR_RES_X / 2,
>> +.height = SENSOR_RES_Y / 2,
>> +.field = V4L2_FIELD_NONE,
>> +.colorspace = V4L2_COLORSPACE_SRGB,
>> +.bytesperline = SENSOR_RES_X / 2,
>> +.sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
>> +},
>> +{
>> +.pixelformat = V4L2_PIX_FMT_GREY,
>> +.width  = SENSOR_RES_X / 2,
>> +.height = SENSOR_RES_Y / 2,
>> +.field = V4L2_FIELD_NONE,
>> +.colorspace = V4L2_COLORSPACE_SRGB,
>> +.bytesperline = SENSOR_RES_X / 2,
>> +.sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
>> +}
>> +};
>> +
>>  /* master device state */
>>  struct sur40_state {
>>  
>> @@ -149,6 +170,7 @@ struct sur40_state {
>>  struct v4l2_device v4l2;
>>  struct video_device vdev;
>>  struct mutex lock;
>> +struct v4l2_pix_format pix_fmt;
>>  
>>  struct vb2_queue queue;
>>  struct list_head buf_list;
>> @@ -169,7 +191,6 @@ struct sur40_buffer {
>>  
>>  /* forward declarations */
>>  static const struct video_device sur40_video_device;
>> -static const struct v4l2_pix_format sur40_video_format;
>>  static const struct vb2_queue sur40_queue;
>>  static void sur40_process_video(struct sur40_state *sur40);
>>  
>> @@ -420,7 +441,7 @@ static void sur40_process_video(struct
>sur40_state *sur40)
>>  goto err_poll;
>>  }
>>  
>> -if (le32_to_cpu(img->size) != sur40_video_format.sizeimage) {
>> +if (le32_to_cpu(img->size) != sur40->pix_fmt.sizeimage) {
>>  dev_err(sur40->dev, "image size mismatch\n");
>>  goto err_poll;
>>  }
>> @@ -431,7 +452,7 @@ static void sur40_process_video(struct
>sur40_state *sur40)
>>  
>>  result = usb_sg_init(&sgr, sur40->usbdev,
>>  usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), 0,
>> -sgt->sgl, sgt->nents, sur40_video_format.sizeimage, 0);
>> +sgt->sgl, sgt->nents, sur40->pix_fmt.sizeimage, 0);
>>  if (result < 0) {
>>  dev_err(sur40->dev, "error %d in usb_sg_init\n", result);
>>  goto err_poll;
>> @@ -586,13 +607,14 @@ static int sur40_probe(struct usb_interface
>*interface,
>>  if (error)
>>  goto err_unreg_v4l2;
>>  
>> +sur40->pix_fmt = sur40_pix_format[0];
>>  sur40->vdev = sur40_video_device;
>>  sur40->vdev.v4l2_dev = &sur40->v4l2;
>>  sur40->vdev.lock = &sur40->lock;
>>  sur40->vdev.queue = &sur40->queue;
>>  video_set_drvdata(&sur40->vdev, sur40);
>>  
>> -error = video_register_device(&sur40->vdev, VFL_TYPE_GRABBER, -1);
>> +error = video_register_device(&sur40->vdev, VFL_TYPE_TOUCH, -1);
>>  if (error) {
>>  dev_err(&interface->dev,
>>  "Unable to register video subdevice.");
>> @@ -651,10 +673,10 @@ static int sur40_queue_setup(struct vb2_queue
>*q,
>>  *nbuffers = 3 - q->num_buffers;
>>  
>>  if (*nplanes)
>> -return sizes[0] < sur40_video_format.sizeimage ? -EINVAL : 0;
>> +return sizes[0] < sur40->pix_fmt.sizeimage ? -EINVAL : 0;
>>  
>>  *nplanes = 1;
>> -sizes[0] = sur40_video_format.sizeimage;
>> +sizes[0] = sur40->pix_fmt.sizeimage;
>>  
>>  return 0;
>>  }
>> @@ -666,7 +688,7 @@ static int sur40_queue_setup(struct vb2_queue *q,
>>  static int sur40_buffer_prepare(struct vb2_buffer *vb)
>>  {
>>  struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
>> -unsigned long size = sur40_video_format.sizeimage;
>> +unsigned long size = sur40->pix_fmt.sizeimage;
>>  
>>  if (vb2_plane_size(vb, 0) < size) {
>>  dev_err(&sur40->usbdev->dev, "buffer too small (%lu < %lu)\n",
>> @@ -741,7 +763,7 @@ static int sur40_vidioc_querycap(struct 

Re: kmemleak: Cannot insert 0xff7f1000 into the object search tree (overlaps existing)

[Vignesh R]

On Friday 12 August 2016 03:34 PM, Catalin Marinas wrote:
> On Fri, Aug 12, 2016 at 09:45:05AM +0530, Vignesh R wrote:
>> On Thursday 11 August 2016 10:38 PM, Catalin Marinas wrote:
[...]
> From b8b9141fffc1fd3c73583c1fd50a724c4a6452e1 Mon Sep 17 00:00:00 2001
> From: Catalin Marinas 
> Date: Fri, 12 Aug 2016 10:43:06 +0100
> Subject: [PATCH] mm: kmemleak: Avoid using __va() on addresses that don't have
>  a lowmem mapping
> 
> Some of the kmemleak_*() callbacks in memblock, bootmem, CMA convert a
> physical address to a virtual one using __va(). However, such physical
> addresses may sometimes be located in highmem and using __va() is
> incorrect, leading to inconsistent object tracking in kmemleak.
> 
> The following functions have been added to the kmemleak API and they
> take a physical address as the object pointer. They only perform the
> corresponding action if the address has a lowmem mapping:
> 
> kmemleak_alloc_phys
> kmemleak_free_part_phys
> kmemleak_not_leak_phys
> kmemleak_ignore_phys
> 
> The affected calling placess have been updated to use the new kmemleak
> API.
> 
> Reported-by: Vignesh R 
> Signed-off-by: Catalin Marinas 

Thanks, this solves the issue!
I tested on AM335x GP EVM and DRA72 EVM on linux-next with below patch
applied. FWIW,
Tested-by: Vignesh R 

I can see this issue on stable v4.4.17 kernel as well. So, can this
patch be marked for stable backport?


Regards
Vignesh

> ---
>  Documentation/kmemleak.txt |  9 +
>  include/linux/kmemleak.h   | 26 ++
>  mm/bootmem.c   |  6 +++---
>  mm/cma.c   |  2 +-
>  mm/memblock.c  |  8 
>  mm/nobootmem.c |  2 +-
>  6 files changed, 44 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
> index 18e24abb3ecf..35e1a8891e3a 100644
> --- a/Documentation/kmemleak.txt
> +++ b/Documentation/kmemleak.txt
> @@ -155,6 +155,15 @@ kmemleak_erase- erase an old value in a 
> pointer variable
>  kmemleak_alloc_recursive - as kmemleak_alloc but checks the recursiveness
>  kmemleak_free_recursive   - as kmemleak_free but checks the recursiveness
>  
> +The following functions take a physical address as the object pointer
> +and only perform the corresponding action if the address has a lowmem
> +mapping:
> +
> +kmemleak_alloc_phys
> +kmemleak_free_part_phys
> +kmemleak_not_leak_phys
> +kmemleak_ignore_phys
> +
>  Dealing with false positives/negatives
>  --
>  
> diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h
> index 4894c6888bc6..380f72bc3657 100644
> --- a/include/linux/kmemleak.h
> +++ b/include/linux/kmemleak.h
> @@ -21,6 +21,7 @@
>  #ifndef __KMEMLEAK_H
>  #define __KMEMLEAK_H
>  
> +#include 
>  #include 
>  
>  #ifdef CONFIG_DEBUG_KMEMLEAK
> @@ -109,4 +110,29 @@ static inline void kmemleak_no_scan(const void *ptr)
>  
>  #endif   /* CONFIG_DEBUG_KMEMLEAK */
>  
> +static inline void kmemleak_alloc_phys(phys_addr_t phys, size_t size,
> +int min_count, gfp_t gfp)
> +{
> + if (!IS_ENABLED(CONFIG_HIGHMEM) || phys < __pa(high_memory))
> + kmemleak_alloc(__va(phys), size, min_count, gfp);
> +}
> +
> +static inline void kmemleak_free_part_phys(phys_addr_t phys, size_t size)
> +{
> + if (!IS_ENABLED(CONFIG_HIGHMEM) || phys < __pa(high_memory))
> + kmemleak_free_part(__va(phys), size);
> +}
> +
> +static inline void kmemleak_not_leak_phys(phys_addr_t phys)
> +{
> + if (!IS_ENABLED(CONFIG_HIGHMEM) || phys < __pa(high_memory))
> + kmemleak_not_leak(__va(phys));
> +}
> +
> +static inline void kmemleak_ignore_phys(phys_addr_t phys)
> +{
> + if (!IS_ENABLED(CONFIG_HIGHMEM) || phys < __pa(high_memory))
> + kmemleak_ignore(__va(phys));
> +}
> +
>  #endif   /* __KMEMLEAK_H */
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index 0aa7dda52402..80f1d70bad2d 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -158,7 +158,7 @@ void __init free_bootmem_late(unsigned long physaddr, 
> unsigned long size)
>  {
>   unsigned long cursor, end;
>  
> - kmemleak_free_part(__va(physaddr), size);
> + kmemleak_free_part_phys(physaddr, size);
>  
>   cursor = PFN_UP(physaddr);
>   end = PFN_DOWN(physaddr + size);
> @@ -402,7 +402,7 @@ void __init free_bootmem_node(pg_data_t *pgdat, unsigned 
> long physaddr,
>  {
>   unsigned long start, end;
>  
> - kmemleak_free_part(__va(physaddr), size);
> + kmemleak_free_part_phys(physaddr, size);
>  
>   start = PFN_UP(physaddr);
>   end = PFN_DOWN(physaddr + size);
> @@ -423,7 +423,7 @@ void __init free_bootmem(unsigned long physaddr, unsigned 
> long size)
>  {
>   unsigned long start, end;
>  
> - kmemleak_free_part(__va(physaddr), size);
> + kmemleak_free_part_phys(physaddr, size);
>  
>   start = PFN_UP(physaddr);
>   end = PFN_DOWN(physaddr + size);
> diff --g