date:20150506

Re: [PATCH v4 0/3] tracing: add trace event for memory-failure

2015-05-06 Thread Xie XiuQi

On 2015/5/7 9:12, Naoya Horiguchi wrote:
> On Wed, Apr 29, 2015 at 07:14:27PM +0800, Xie XiuQi wrote:
>> Hi Naoya,
>>
>> Could you help to review and applied this series if possible.
> 
> Sorry for late response, I was offline for several days due to national
> holidays.

It doesn't matter, wish you have a good holiday ;-)

> 
> This patchset is good to me, but I'm not sure which path it should go through.
> Ordinarily, memory-failure patches go to linux-mm, but patch 3 depends on
> TRACE_DEFINE_ENUM patches, so this can go to linux-next directly, or go to
> linux-mm with depending patches.

TRACE_DEFINE_ENUM patches has been merged into mainline. I'll correct patch 3's 
typo
and rebase them on top of latest mainline in v5.

Thanks,
Xie XiuQi

> 
> Steven, Andrew, which way do you like?
> 
> Thanks,
> Naoya Horiguchi
> 
>> Thanks,
>> Xie XiuQi
>>
>> On 2015/4/20 16:44, Xie XiuQi wrote:
>>> RAS user space tools like rasdaemon which base on trace event, could
>>> receive mce error event, but no memory recovery result event. So, I
>>> want to add this event to make this scenario complete.
>>>
>>> This patchset add a event at ras group for memory-failure.
>>>
>>> The output like below:
>>> #  tracer: nop
>>> #
>>> #  entries-in-buffer/entries-written: 2/2   #P:24
>>> #
>>> #   _-=> irqs-off
>>> #  / _=> need-resched
>>> # | / _---=> hardirq/softirq
>>> # || / _--=> preempt-depth
>>> # ||| / delay
>>> #TASK-PID   CPU#  TIMESTAMP  FUNCTION
>>> #   | |   |      | |
>>>mce-inject-13150 [001]    277.019359: memory_failure_event: pfn 
>>> 0x19869: recovery action for free buddy page: Delayed
>>>
>>> --
>>> v3->v4:
>>>  - rebase on top of latest linux-next
>>>  - update comments as Naoya's suggestion
>>>  - add #ifdef CONFIG_MEMORY_FAILURE for this trace event
>>>  - change type of action_result's param 3 to enum
>>>
>>> v2->v3:
>>>  - rebase on top of linux-next
>>>  - based on Steven Rostedt's "tracing: Add TRACE_DEFINE_ENUM() macro
>>>to map enums to their values" patch set v1.
>>>
>>> v1->v2:
>>>  - Comment update
>>>  - Just passing 'result' instead of 'action_name[result]',
>>>suggested by Steve. And hard coded there because trace-cmd
>>>and perf do not have a way to process enums.
>>>
>>> Xie XiuQi (3):
>>>   memory-failure: export page_type and action result
>>>   memory-failure: change type of action_result's param 3 to enum
>>>   tracing: add trace event for memory-failure
>>>
>>>  include/linux/mm.h  |  34 ++
>>>  include/ras/ras_event.h |  85 
>>>  mm/memory-failure.c | 172 
>>> 
>>>  3 files changed, 190 insertions(+), 101 deletions(-)
>>>
>>
>> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> .
> 


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

RE: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

2015-05-06 Thread Oza (Pawandeep) Oza

Yes.
But dying kernel doesn’t mean it CAN NOT INCREMENT jiffies.
do_timer should do the job until kernel takes its last breathe and more 
precisely CPU0 take its last breathe by halting itself as its last instruction.

Regards,
-Oza


-Original Message-
From: Mike Galbraith [mailto:umgwanakikb...@gmail.com] 
Sent: Thursday, May 07, 2015 11:25 AM
To: Oza (Pawandeep) Oza
Cc: pawandeep oza; linux-kernel@vger.kernel.org; malayasen rout
Subject: Re: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

On Thu, 2015-05-07 at 05:12 +, Oza (Pawandeep) Oza wrote:

> But after Crash, jiffies do not increment.

Your kernel said "I'M DEAD", that's a good reason to believe it.

-Mike

Re: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

2015-05-06 Thread Mike Galbraith

On Thu, 2015-05-07 at 05:12 +, Oza (Pawandeep) Oza wrote:

> But after Crash, jiffies do not increment.

Your kernel said "I'M DEAD", that's a good reason to believe it.

-Mike

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

[EDT][Patch 1/1] socket family check in netlabel APIs

2015-05-06 Thread Maninder Singh

EP-E68D5E24548545C9BBB607A98ADD61E6

Hi Paul,

>On Monday, March 30, 2015 11:09:00 AM Maninder Singh wrote:
>> Dear All,
>> we found One Kernel Crash issue in cipso_v4_sock_delattr :-
>> As Cipso supports only inet sockets so cipso_v4_sock_delattr will crash when
>> try to access any other socket type.  cipso_v4_sock_delattr access
>> sk_inet->inet_opt which may contain not NULL but invalid address. we found
>> this issue with netlink socket.(reproducible by trinity using sendto system
>> call .) 

>Hello,

>First, please go read the Documentation/SubmittingPatches from the kernel 
>sources; your patch needs to be resubmitted and the instructions in that file 
>will show you how to do it correctly next time.

>Second, this appears to only affect Smack based systems, yes?  SELinux based 
>systems should have the proper checking in place to prevent this (the checks 
>are handled in the LSM).  That said, it probably wouldn't hurt to add the 
>extra checking to netlbl_sock_delattr().  If you properly resubmit your patch 
>I'll ACK it.

>-Paul

>-- 
>paul moore
>www.paul-moore.com

As suggested resubmitting the patch .

Subject : socket family check in netlabel APIs

Adding check for socket family in netlbl_sock_delattr and netlbl_req_delattr as 
check present
 in netlbl_sock_setattr and netlbl_req_setattr respectively.

as we faced crash in cipso_v4_sock_delattr due to other socket type.
Crash Logs :
[0-182.2400] [] (cipso_v4_sock_delattr+0x0/0x74) from [] 
(netlbl_sock_delattr+0x18/0x1c)
[0-182.2497]  r4: r3:c07872f8
[0-182.2531] [] (netlbl_sock_delattr+0x0/0x1c) from [] 
(smack_netlabel+0x88/0x9c)
[0-182.2622] [] (smack_netlabel+0x0/0x9c) from [] 
(smack_netlabel_send+0x12c/0x144)
[0-182.2714]  r7 9ce9500 r6 7b67ef4 r5:c076f408 r4 8903dc0
[0-182.2770] [] (smack_netlabel_send+0x0/0x144) from [] 
(smack_socket_sendmsg+0x54/0x60)
[0-182.2866] [] (smack_socket_sendmsg+0x0/0x60) from [] 
(security_socket_sendmsg+0x28/0x2c)
[0-182.2966] [] (security_socket_sendmsg+0x0/0x2c) from [] 
(sock_sendmsg+0x68/0xc0)
[0-182.3058] [] (sock_sendmsg+0x0/0xc0) from [] 
(SyS_sendto+0xd8/0x110)

Signed-off-by: Vaneet Narang 
Signed-off-by: Maninder Singh 
Reviewed-by : Ajeet Yadav 
---
 net/netlabel/netlabel_kapi.c |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 28cddc8..606a5ce 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -824,7 +824,13 @@ socket_setattr_return:
  */
 void netlbl_sock_delattr(struct sock *sk)
 {
-   cipso_v4_sock_delattr(sk);
+   switch (sk->sk_family) {
+   case AF_INET:
+   cipso_v4_sock_delattr(sk);
+   break;
+   default:
+   }
+   return;
 }
 
 /**
@@ -987,7 +993,13 @@ req_setattr_return:
 */
 void netlbl_req_delattr(struct request_sock *req)
 {
-   cipso_v4_req_delattr(req);
+   switch (req->rsk_ops->family) {
+   case AF_INET:
+   cipso_v4_req_delattr(req);
+   break;
+   default:
+   }
+   return;
 }
 
 /**
-- 
1.7.1

Re: [PATCH v2] Fix the license mismatch and add the resolution setting

2015-05-06 Thread Dmitry Torokhov

Hi Hn,

On Tue, Apr 28, 2015 at 06:35:58PM +0800, HungNien Chen wrote:
> Signed-off-by: HungNien Chen 

Thank you for your submission, please find my comments below.

> ---
>  drivers/input/touchscreen/Kconfig   |   12 +
>  drivers/input/touchscreen/Makefile  |1 +
>  drivers/input/touchscreen/wdt87xx_i2c.c | 1501 
> +++
>  3 files changed, 1514 insertions(+)
>  create mode 100644 drivers/input/touchscreen/wdt87xx_i2c.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 80f6386..0c1a6cc 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -658,6 +658,18 @@ config TOUCHSCREEN_PIXCIR
> To compile this driver as a module, choose M here: the
> module will be called pixcir_i2c_ts.
>  
> +config TOUCHSCREEN_WDT87XX_I2C
> + tristate "Weida HiTech I2C touchscreen"
> + depends on I2C
> + help
> +   Say Y here if you have an Weida WDT87XX I2C touchscreen
> +   connected to your system.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called wdt87xx_i2c.
> +
>  config TOUCHSCREEN_WM831X
>   tristate "Support for WM831x touchscreen controllers"
>   depends on MFD_WM831X
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index 44deea7..fa3d33b 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_TOUCHSCREEN_TSC2007)   += tsc2007.o
>  obj-$(CONFIG_TOUCHSCREEN_UCB1400)+= ucb1400_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)+= wacom_w8001.o
>  obj-$(CONFIG_TOUCHSCREEN_WACOM_I2C)  += wacom_i2c.o
> +obj-$(CONFIG_TOUCHSCREEN_WDT87XX_I2C)+= wdt87xx_i2c.o
>  obj-$(CONFIG_TOUCHSCREEN_WM831X) += wm831x-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_WM97XX) += wm97xx-ts.o
>  wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9705)   += wm9705.o
> diff --git a/drivers/input/touchscreen/wdt87xx_i2c.c 
> b/drivers/input/touchscreen/wdt87xx_i2c.c
> new file mode 100644
> index 000..c79439c
> --- /dev/null
> +++ b/drivers/input/touchscreen/wdt87xx_i2c.c
> @@ -0,0 +1,1501 @@
> +/*
> + * drivers/input/touchscreen/wdt87xx_i2c.c

No need to mention file name in comments.

> + *
> + * Weida HiTech WDT87xx TouchScreen I2C driver
> + *
> + * Copyright (c) 2014  Weida HiTech Ltd.
> + * HN Chen 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * Note: this is a I2C device driver and report touch events througt the
> + *   input device
> + */
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifdef   CONFIG_ACPI

No need to guard, just include.

> +#include 
> +#endif
> +
> +#define WDT87XX_NAME "wdt87xx_i2c"
> +#define  WDT87XX_DRV_VER "0.9.1"
> +#define  WDT87XX_FW_NAME "wdt87xx_fw.bin"
> +
> +#define  WDT87XX_FW  1
> +#define  WDT87XX_CFG 2
> +
> +#define MODE_ACTIVE  0x01
> +#define MODE_READY   0x02
> +#define MODE_IDLE0x03
> +#define MODE_SLEEP   0x04
> +#define  MODE_STOP   0xFF
> +
> +#define WDT_MAX_POINT10
> +#define  WDT_RAW_BUF_COUNT   54
> +
> +#define  PG_SIZE 0x1000
> +#define MAX_RETRIES  3
> +
> +#define  WDT_UNITS_PER_MM60
> +
> +/* the definition for one touch point */
> +struct  wdt_touch_point_event_st {

Please do not put 2 spaces between "struct" and it's name and also
please do not add "_st" suffixes to your structures.

> + unsigned char   id;
> + unsigned short  x;
> + unsigned short  y;
> +} __packed;

Hmm, this is on-wire structure, right? I guess x and y must be
little-endian on wire. You need to convert them to CPU endianness before
using, or the driver will break on big-endian devices. Also, x and y are
likely not naturally aligned so you probably want to use
get_unaligned_le16() when reading them or or may encounter issues on
some boards. Because of that I'd rather you did not define
wdt_touch_point_event_st structure but defined offsets for ID, X and Y
and use them to fetch data from character buffer where you read the data
from the device.

> +
> +
> +/* the definition for a packet */
> +struct  wdt_touch_events_st {
> + unsigned char   report_id;
> + struct  wdt_touch_point_event_sttouch_event[WDT_MAX_POINT];
> + unsigned short  scan_time;
> +

Re: [PATCH] staging: comedi: coding style identation error fix

2015-05-06 Thread Sudip Mukherjee

On Wed, May 06, 2015 at 05:13:41PM -0500, Jaime Arrocha wrote:
> Errors found by checkpatch.pl.
> ERROR: code indent should use tabs where possible
> /drivers/staging/comedi/drivers/das16m1.c:49
> /drivers/staging/comedi/drivers/das16m1.c:50
> 
> Signed-off-by: Jaime Arrocha 
> ---
you are sending this patch second time with different subject.
any reason for that?

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

Re: [PATCH 09/19] clk: emev2: Silence sparse warnings

2015-05-06 Thread Simon Horman

On Wed, May 06, 2015 at 10:17:24PM -0700, Stephen Boyd wrote:
> On 05/07, Simon Horman wrote:
> > On Wed, May 06, 2015 at 12:39:46AM -0700, Stephen Boyd wrote:
> > > drivers/clk/shmobile/clk-emev2.c:37:14: warning: symbol 'smu_base' was 
> > > not declared. Should it be static?
> > > 
> > > Cc: Takashi Yoshii 
> > > Cc: Magnus Damm 
> > > Cc: Simon Horman 
> > > Signed-off-by: Stephen Boyd 
> > 
> > Acked-by: Simon Horman 
> > 
> > Stephen, I'm assuming that you or Mike will merge this.
> 
> Yep we'll take this series through clk-next. Thanks.

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

linux-next: build warning after merge of the drm-intel tree

2015-05-06 Thread Stephen Rothwell

Hi all,

After merging the drm-intel tree, today's linux-next build (i386 defconfig)
produced this warning:

drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_init':
drivers/gpu/drm/i915/i915_gem_gtt.c:954:22: warning: large integer implicitly 
truncated to unsigned type [-Woverflow]
  ppgtt->base.total = 1ULL << 32;
  ^

Introduced by commit 5c5f645773b6 ("drm/i915: Unify aliasing ppgtt
handling").  "total" is a size_t, so unsigned 32 bit on i386.

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


pgp40xfpzrabt.pgp
Description: OpenPGP digital signature

[PATCH] cpuidle: Handle tick_broadcast_enter() failure gracefully

2015-05-06 Thread Preeti U Murthy

When a CPU has to enter an idle state where tick stops, it makes a call
to tick_broadcast_enter(). The call will fail if this CPU is the
broadcast CPU. Today, under such a circumstance, the arch cpuidle code
handles this CPU.  This is not convincing because not only are we not
aware what the arch cpuidle code does, but we also do not account for
the idle state residency time and usage of such a CPU.

This scenario can be handled better by simply asking the cpuidle
governor to choose an idle state where in ticks do not stop. To
accommodate this change move the setting of runqueue idle state from the
core to the cpuidle driver, else the rq->idle_state will be set wrong.

Signed-off-by: Preeti U Murthy 
---
Based on linux-pm/bleeding-edge

 drivers/cpuidle/cpuidle.c  |   21 +
 drivers/cpuidle/governors/ladder.c |   13 ++---
 drivers/cpuidle/governors/menu.c   |6 +-
 include/linux/cpuidle.h|6 +++---
 include/linux/sched.h  |   16 
 kernel/sched/core.c|   17 +
 kernel/sched/fair.c|2 +-
 kernel/sched/idle.c|8 +---
 kernel/sched/sched.h   |   24 
 9 files changed, 70 insertions(+), 43 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 61c417b..8f5657e 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "cpuidle.h"
@@ -167,8 +168,15 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct 
cpuidle_driver *drv,
 * local timer will be shut down.  If a local timer is used from another
 * CPU as a broadcast timer, this call may fail if it is not available.
 */
-   if (broadcast && tick_broadcast_enter())
-   return -EBUSY;
+   if (broadcast && tick_broadcast_enter()) {
+   index = cpuidle_select(drv, dev, !broadcast);
+   if (index < 0)
+   return -EBUSY;
+   target_state = >states[index];
+   }
+
+   /* Take note of the planned idle state. */
+   idle_set_state(smp_processor_id(), target_state);
 
trace_cpu_idle_rcuidle(index, dev->cpu);
time_start = ktime_get();
@@ -178,6 +186,9 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct 
cpuidle_driver *drv,
time_end = ktime_get();
trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
 
+   /* The cpu is no longer idle or about to enter idle. */
+   idle_set_state(smp_processor_id(), NULL);
+
if (broadcast) {
if (WARN_ON_ONCE(!irqs_disabled()))
local_irq_disable();
@@ -213,12 +224,14 @@ int cpuidle_enter_state(struct cpuidle_device *dev, 
struct cpuidle_driver *drv,
  *
  * @drv: the cpuidle driver
  * @dev: the cpuidle device
+ * @timer_stop_valid: allow selection of idle state where tick stops
  *
  * Returns the index of the idle state.
  */
-int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
+int cpuidle_select(struct cpuidle_driver *drv,
+   struct cpuidle_device *dev, int timer_stop_valid)
 {
-   return cpuidle_curr_governor->select(drv, dev);
+   return cpuidle_curr_governor->select(drv, dev, timer_stop_valid);
 }
 
 /**
diff --git a/drivers/cpuidle/governors/ladder.c 
b/drivers/cpuidle/governors/ladder.c
index 401c010..c437322 100644
--- a/drivers/cpuidle/governors/ladder.c
+++ b/drivers/cpuidle/governors/ladder.c
@@ -62,9 +62,10 @@ static inline void ladder_do_selection(struct ladder_device 
*ldev,
  * ladder_select_state - selects the next state to enter
  * @drv: cpuidle driver
  * @dev: the CPU
+ * @timer_stop_valid: allow selection of idle state where tick stops
  */
 static int ladder_select_state(struct cpuidle_driver *drv,
-   struct cpuidle_device *dev)
+   struct cpuidle_device *dev, int 
timer_stop_valid)
 {
struct ladder_device *ldev = this_cpu_ptr(_devices);
struct ladder_device_state *last_state;
@@ -86,6 +87,7 @@ static int ladder_select_state(struct cpuidle_driver *drv,
!drv->states[last_idx + 1].disabled &&
!dev->states_usage[last_idx + 1].disable &&
last_residency > last_state->threshold.promotion_time &&
+   !(!timer_stop_valid && (drv->states[last_idx + 1].flags & 
CPUIDLE_FLAG_TIMER_STOP)) &&
drv->states[last_idx + 1].exit_latency <= latency_req) {
last_state->stats.promotion_count++;
last_state->stats.demotion_count = 0;
@@ -99,11 +101,14 @@ static int ladder_select_state(struct cpuidle_driver *drv,
if (last_idx > CPUIDLE_DRIVER_STATE_START &&
(drv->states[last_idx].disabled ||
dev->states_usage[last_idx].disable ||
+   (!timer_stop_valid &&

Re: [PATCH 3.19 000/177] 3.19.7-stable review

2015-05-06 Thread Tyler Baker

Hi Greg,

On 5 May 2015 at 15:10, Greg Kroah-Hartman  wrote:
> On Sat, May 02, 2015 at 09:00:22PM +0200, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 3.19.7 release.
>> There are 177 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Mon May  4 18:59:31 UTC 2015.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz
>> and the diffstat can be found below.
>
> -rc2 is out now that should work properly:
>
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc2.gz

The kernelci.org robot reported new boot failures in v3.19.7 on a
variety of at91 boards[1][2][3]. I instructed the robot perform a boot
bisection which yielded...

git bisect start
# bad: [7214c55cba9630a4728f86ae6b3c73c962430711] Linux 3.19.7
git bisect bad 7214c55cba9630a4728f86ae6b3c73c962430711
# good: [3c464c73693b6d118c129d7f07dbc1ea26aa6d8a] Linux 3.19.6
git bisect good 3c464c73693b6d118c129d7f07dbc1ea26aa6d8a
# bad: [31064e86b01887a28fa26af528dc5239be384435] ptrace: fix race
between ptrace_resume() and wait_task_stopped()
git bisect bad 31064e86b01887a28fa26af528dc5239be384435
# good: [7595f5425cad83e037639e228ee24d5052510139] md/raid0: fix bug
with chunksize not a power of 2.
git bisect good 7595f5425cad83e037639e228ee24d5052510139
# good: [dc7a0b0a432521d4b40987b344a9b5473a9bd18b] usb: phy: Find the
right match in devm_usb_phy_match
git bisect good dc7a0b0a432521d4b40987b344a9b5473a9bd18b
# good: [dc7507e89e2c67143e5bb51488f4e5c7e0f6d3bd] usb: host: sl811:
use new USB_RESUME_TIMEOUT
git bisect good dc7507e89e2c67143e5bb51488f4e5c7e0f6d3bd
# bad: [92465054d08aa11c32b77969bc3be89d1c229f9f] ALSA: hda/realtek -
Enable the ALC292 dock fixup on the Thinkpad T450
git bisect bad 92465054d08aa11c32b77969bc3be89d1c229f9f
# bad: [c67881fc890916206e723329e774391c6ed354ce] clk: at91: usb:
propagate rate modification to the parent clk
git bisect bad c67881fc890916206e723329e774391c6ed354ce
# good: [d7f24470bf614ff986c9370f5704fa635b448918] usb: core: hub: use
new USB_RESUME_TIMEOUT
git bisect good d7f24470bf614ff986c9370f5704fa635b448918

c67881fc890916206e723329e774391c6ed354ce is the first bad commit
commit c67881fc890916206e723329e774391c6ed354ce
Author: Boris Brezillon 
Date:   Sun Mar 29 03:45:33 2015 +0200

clk: at91: usb: propagate rate modification to the parent clk

commit 4591243102faa8de92da320edea47219901461e9 upstream.

The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate
modification requests to their parents.
This causes a bug when the PLLB is left uninitialized by the bootloader
(PLL multiplier set to 0, or in other words, PLL rate = 0 Hz).

Implement the determinate_rate method and propagate the change rate
request to the parent clk.

Signed-off-by: Boris Brezillon 
Reported-by: Bo Shen 
Tested-by: Bo Shen 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman 

Locally I've reverted c67881fc890916206e723329e774391c6ed354ce on top
of v3.19.7 and confirmed that my at91-sama5d3_xplained boots that
kernel successfully[4].

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

Cheers,

Tyler

[1] http://kernelci.org/boot/?v3.19
[2] https://lists.linaro.org/pipermail/kernel-build-reports/2015-May/008917.html
[3] 
http://storage.kernelci.org/stable/v3.19.7/arm-sama5_defconfig/lab-tbaker/boot-at91-sama5d3_xplained.html
[4] http://lava.kernelci.org/scheduler/job/80240/log_file
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/19] clk: emev2: Silence sparse warnings

2015-05-06 Thread Stephen Boyd

On 05/07, Simon Horman wrote:
> On Wed, May 06, 2015 at 12:39:46AM -0700, Stephen Boyd wrote:
> > drivers/clk/shmobile/clk-emev2.c:37:14: warning: symbol 'smu_base' was not 
> > declared. Should it be static?
> > 
> > Cc: Takashi Yoshii 
> > Cc: Magnus Damm 
> > Cc: Simon Horman 
> > Signed-off-by: Stephen Boyd 
> 
> Acked-by: Simon Horman 
> 
> Stephen, I'm assuming that you or Mike will merge this.

Yep we'll take this series through clk-next. Thanks.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] manpage: update FALLOC_FL_INSERT_RANGE flag in fallocate

2015-05-06 Thread Namjae Jeon

Update FALLOC_FL_INSERT_RANGE flag in fallocate.

Signed-off-by: Namjae Jeon 
Signed-off-by: Ashish Sangwan 
---
 man2/fallocate.2 | 89 
 1 file changed, 84 insertions(+), 5 deletions(-)

diff --git a/man2/fallocate.2 b/man2/fallocate.2
index 0cc1a00..0d31027 100644
--- a/man2/fallocate.2
+++ b/man2/fallocate.2
@@ -228,6 +228,59 @@ ext4, for extent-based files (since Linux 3.15)
 .IP *
 SMB3 (since Linux 3.17)
 .\" commit 30175628bf7f521e9ee31ac98fa6d6fe7441a556
+.SS Increasing file space
+flag (available since Linux 4.1)
+.\" commit dd46c787788d5bf5b974729d43e4c405814a4c7d
+Specifying the
+.BR FALLOC_FL_INSERT_RANGE
+flag in
+.I mode
+will increase the file space by inserting a hole within the file size without
+overwriting any existing data.
+The hole will start at
+.I offset
+and continue for
+.I len
+bytes.
+For inserting hole inside file, the contents of the file starting at
+.I offset
+will be shifted towards right by
+.I len
+bytes.
+Inserting a hole inside the file will increase the file size by
+.I len
+bytes.
+
+This mode has the same limitation as
+.BR FALLOC_FL_COLLAPSE_RANGE
+regarding the
+granularity of the operation.
+If the granularity requirements are not met,
+.BR fallocate ()
+will fail with the error
+.BR EINVAL.
+If the
+.I offset
+overlaps with end of file OR if it is greater than end of file, an error is
+returned.
+For such type of operations, i.e. inserting a hole at the end of file,
+.BR ftruncate(2)
+should be used.
+In case
+.IR offset + len
+exceeds the maximum file size, errno will be set to
+.B EFBIG.
+
+No other flags may be specified in
+.IR mode
+in conjunction with
+.BR FALLOC_FL_INSERT_RANGE .
+
+As of Linux 4.1,
+.B FALLOC_FL_INSERT_RANGE
+is supported by
+XFS.
+.\" commit a904b1ca5751faf5ece8600e18cd3b674afcca1b
 .SH RETURN VALUE
 On success,
 .BR fallocate ()
@@ -245,6 +298,12 @@ is not a valid file descriptor, or is not opened for 
writing.
 .IR offset + len
 exceeds the maximum file size.
 .TP
+.B EFBIG
+.I mode
+is
+.BR FALLOC_FL_INSERT_RANGE ,
+the current file size+len exceeds the maximum file size.
+.TP
 .B EINTR
 A signal was caught during execution.
 .TP
@@ -273,7 +332,17 @@ reaches or passes the end of the file.
 .B EINVAL
 .I mode
 is
-.BR FALLOC_FL_COLLAPSE_RANGE ,
+.BR FALLOC_FL_INSERT_RANGE
+and the range specified by
+.I offset
+reaches or passes the end of the file.
+.TP
+.B EINVAL
+.I mode
+is
+.BR FALLOC_FL_COLLAPSE_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE ,
 but either
 .I offset
 or
@@ -282,18 +351,24 @@ is not a multiple of the filesystem block size.
 .TP
 .B EINVAL
 .I mode
-contains both
+contains either of
 .B FALLOC_FL_COLLAPSE_RANGE
+or
+.B FALLOC_FL_INSERT_RANGE
 and other flags;
 no other flags are permitted with
-.BR FALLOC_FL_COLLAPSE_RANGE .
+.BR FALLOC_FL_COLLAPSE_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE .
 .TP
 .B EINVAL
 .I mode
 is
 .BR FALLOC_FL_COLLAPSE_RANGE
 or
-.BR FALLOC_FL_ZERO_RANGE ,
+.BR FALLOC_FL_ZERO_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE ,
 but the file referred to by
 .I fd
 is not a regular file.
@@ -345,6 +420,8 @@ specifies
 .BR FALLOC_FL_PUNCH_HOLE
 or
 .BR FALLOC_FL_COLLAPSE_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE
 and
 the file referred to by
 .I fd
@@ -363,7 +440,9 @@ refers to a pipe or FIFO.
 .B ETXTBSY
 .I mode
 specifies
-.BR FALLOC_FL_COLLAPSE_RANGE ,
+.BR FALLOC_FL_COLLAPSE_RANGE
+or
+.BR FALLOC_FL_INSERT_RANGE ,
 but the file referred to by
 .IR fd
 is currently being executed.
-- 
1.8.5.5

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

RE: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

2015-05-06 Thread Oza (Pawandeep) Oza

Solution Statement: Fix the UTTERLY DEADLY bug.

Oza: 
that BUG() is LEGAL. Kernel is not a problem there.
Somebody else outside of kernel/ARM (some other HW raises the bug), and send 
indication to kernel that I am not alive.
So kernel choose to CRASH ITSELF.

So that is legal crash and wanted Crash.

But after Crash, jiffies do not increment.

Regards,
-Oza

-Original Message-
From: Mike Galbraith [mailto:umgwanakikb...@gmail.com] 
Sent: Thursday, May 07, 2015 10:39 AM
To: Oza (Pawandeep) Oza
Cc: pawandeep oza; linux-kernel@vger.kernel.org; malayasen rout
Subject: Re: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

On Thu, 2015-05-07 at 04:37 +, Oza (Pawandeep) Oza wrote:
> Problem Statement: the timkeeping is stopped, do_timer is no more a
> job of cpu0.
> 
> The reason: the variable "tick_do_timer_cpu" is not set to correct CPU
> (cpu0)
> And when BUG() happens, the tick_do_timer_cpu variable stay set to 1,
> 2 or 3 (we have 4 cores)

Solution Statement: Fix the UTTERLY DEADLY bug.

-Mike

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

2015-05-06 Thread Mike Galbraith

On Thu, 2015-05-07 at 04:37 +, Oza (Pawandeep) Oza wrote:
> Problem Statement: the timkeeping is stopped, do_timer is no more a
> job of cpu0.
> 
> The reason: the variable "tick_do_timer_cpu" is not set to correct CPU
> (cpu0)
> And when BUG() happens, the tick_do_timer_cpu variable stay set to 1,
> 2 or 3 (we have 4 cores)

Solution Statement: Fix the UTTERLY DEADLY bug.

-Mike

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

Re: [PATCH] tools/vm: fix build failure

2015-05-06 Thread Naoya Horiguchi

On Thu, May 07, 2015 at 04:47:55AM +, Horiguchi Naoya(堀口 直也) wrote:
> libapikfs.a was renamed to libapi.a on commit 285a8f247b08 ("tools lib api:
> Rename libapikfs.a to libapi.a"), but tools/vm/Makefile still refers to the
> old file name, which breaks the build on tools/vm. This patch fixes it.
> 
> Signed-off-by: Naoya Horiguchi 

Ah, this was already posted in https://lkml.org/lkml/2015/3/12/964,
but not merged for some reason.
Could someone pick it, please?

Thanks,
Naoya Horiguchi

> ---
>  tools/vm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git v4.1-rc2.orig/tools/vm/Makefile v4.1-rc2/tools/vm/Makefile
> index ac884b65a072..93aadaf7ff63 100644
> --- v4.1-rc2.orig/tools/vm/Makefile
> +++ v4.1-rc2/tools/vm/Makefile
> @@ -3,7 +3,7 @@
>  TARGETS=page-types slabinfo page_owner_sort
>  
>  LIB_DIR = ../lib/api
> -LIBS = $(LIB_DIR)/libapikfs.a
> +LIBS = $(LIB_DIR)/libapi.a
>  
>  CC = $(CROSS_COMPILE)gcc
>  CFLAGS = -Wall -Wextra -I../lib/
> -- 
> 2.1.0
>

Re: spi-bcm2835 depends GPIOLIB

2015-05-06 Thread Yoshinori Sato

At Mon, 4 May 2015 13:00:46 +0100,
Mark Brown wrote:
> 
> On Mon, May 04, 2015 at 12:16:36AM +0900, Yoshinori Sato wrote:
> > I got following error on CONFIG_GPIOLIB=n.
> 
> Applied, thanks, but please use subject lines reflecting the style for
> the subsystem.

Oh. I'm sorry.
Thanks applied.

-- 
Yoshinori Sato

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

[PATCH] tools/vm: fix build failure

2015-05-06 Thread Naoya Horiguchi

libapikfs.a was renamed to libapi.a on commit 285a8f247b08 ("tools lib api:
Rename libapikfs.a to libapi.a"), but tools/vm/Makefile still refers to the
old file name, which breaks the build on tools/vm. This patch fixes it.

Signed-off-by: Naoya Horiguchi 
---
 tools/vm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git v4.1-rc2.orig/tools/vm/Makefile v4.1-rc2/tools/vm/Makefile
index ac884b65a072..93aadaf7ff63 100644
--- v4.1-rc2.orig/tools/vm/Makefile
+++ v4.1-rc2/tools/vm/Makefile
@@ -3,7 +3,7 @@
 TARGETS=page-types slabinfo page_owner_sort
 
 LIB_DIR = ../lib/api
-LIBS = $(LIB_DIR)/libapikfs.a
+LIBS = $(LIB_DIR)/libapi.a
 
 CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall -Wextra -I../lib/
-- 
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 19/19] h8300: devicetree source

2015-05-06 Thread Yoshinori Sato

At Mon, 04 May 2015 17:09:21 +0200,
Arnd Bergmann wrote:
> 
> On Monday 04 May 2015 19:42:02 Yoshinori Sato wrote:
> > +
> > +   h8intc: intc@0 {
> > +   compatible = "renesas,h8s-intc", "renesas,h8300-intc";
> > +   #interrupt-cells = <1>;
> > +   interrupt-controller;
> > +   };
> 
> The node name should be "interrupt-controller@0", not "intc@0", to follow
> the common conventions.

OK.

> > +   tpu: tpu@e0 {
> > +   compatible = "renesas,tpu";
> > +   reg = <0xe0 16>, <0xf0 12>;
> > +   clocks = <>;
> > +   clock-names = "peripheral_clk";
> > +   };
> > +
> > +   timer8: timer@b0 {
> > +   compatible = "renesas,8bit-timer";
> > +   reg = <0x80 10>;
> > +   interrupts = <72 75>;
> > +   clocks = <>;
> > +   clock-names = "peripheral_clk";
> > +   renesas,mode = ;
> > +   renesas,div = ;
> > +   };
> > +
> 
> The renesas,div property seems odd here. How about defining a
> "clock-frequency" property and figuring out the divider from
> the parent clock in the driver?

Hmm...
It more better idea.
I will fix.

> Your new binding makes it mandatory to have a "fclk" clock, which
> seems better suited than "peripheral_clk", so I'd suggest you
> change the code to match the documentation (rather than the other
> way round). Alternatively, you could make this an anonymous
> clock and not specify the name at all.

OK.

> The renesas,mode property seems odd. Why is that needed? It sounds
> like you are encoding how you expect the device to be used by
> Linux, rather than what it can do in hardware. If you have multiple
> variants of the 8bit-timer hardware that have different features,
> better use separate compatible strings for them, or a boolean
> flag that announces the presence or absence of a feature.

This timer have some mode. But driver using only one mode.
I think it isn't necessary.

> If however, this is just a hint for Linux, maybe you can find a way
> for the driver to take a guess itself, e.g. using the first
> device it finds as a clockevent device, and only use a clocksource
> device if there is more than one?

Many clocks are put in order.

> > +   sci0: serial@78 {
> > +   compatible = "renesas,sci";
> > +   reg = <0x78 8>;
> > +   interrupts = <88 89 90 91>;
> > +   clocks = <>;
> > +   clock-names = "peripheral_clk";
> > +   };
> > +   sci1: serial@80 {
> > +   compatible = "renesas,sci";
> > +   reg = <0x80 8>;
> > +   interrupts = <92 93 94 95>;
> > +   clocks = <>;
> > +   clock-names = "peripheral_clk";
> > +   };
> > +   sci2: serial@88 {
> > +   compatible = "renesas,sci";
> > +   reg = <0x88 8>;
> > +   interrupts = <96 97 98 99>;
> > +   clocks = <>;
> > +   clock-names = "peripheral_clk";
> > +   };
> > +};
> 
> The binding for sci requires the clock to be named "sci_ick",  so please
> use that instead of "peripheral_clk". The driver can handle both.
>

OK.

>   Arnd

Thanks.

-- 
Yoshinori Sato

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

RE: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

2015-05-06 Thread Oza (Pawandeep) Oza

Hi Mike,

Let me explain the problem again.

Problem Statement: the timkeeping is stopped, do_timer is no more a job of cpu0.

The reason: the variable "tick_do_timer_cpu" is not set to correct CPU (cpu0)
And when BUG() happens, the tick_do_timer_cpu variable stay set to 1, 2 or 3 
(we have 4 cores)
And finally any code running on core0 (which relies on jiffies incrementing) 
doesn’t work because there is nobody to increment jiffies.

There is tick_handover_do_timer, and if that is called then things are fine, 
but that is also not getting called because it is tightly coupled with hotplug.
since cpu_down is not getting called, this handover is not happening. and the 
last status of the variable tick_do_timer_cpu is always
pointing to DEAD cpu (1,2 or 3). and core0 waits forever (where if the code 
relies on the increment of jiffies).

Regards,
-Oza

-Original Message-
From: Mike Galbraith [mailto:umgwanakikb...@gmail.com] 
Sent: Thursday, May 07, 2015 8:53 AM
To: pawandeep oza
Cc: linux-kernel@vger.kernel.org; malayasen rout; Oza (Pawandeep) Oza
Subject: Re: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

On Wed, 2015-05-06 at 22:57 +0530, pawandeep oza wrote:

> but when say core0 has raised BUG..
...

> what is the right way to approach this problem

Look at the spot BUG() printed?  BUG() means "Way to go slick, the code
you fed me (file:line) is toxic.  Have a nice day, your ex-buddy core0".

-Mike

Re: [PATCH 09/19] clk: emev2: Silence sparse warnings

2015-05-06 Thread Simon Horman

On Wed, May 06, 2015 at 12:39:46AM -0700, Stephen Boyd wrote:
> drivers/clk/shmobile/clk-emev2.c:37:14: warning: symbol 'smu_base' was not 
> declared. Should it be static?
> 
> Cc: Takashi Yoshii 
> Cc: Magnus Damm 
> Cc: Simon Horman 
> Signed-off-by: Stephen Boyd 

Acked-by: Simon Horman 

Stephen, I'm assuming that you or Mike will merge this.

> ---
>  drivers/clk/shmobile/clk-emev2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/shmobile/clk-emev2.c 
> b/drivers/clk/shmobile/clk-emev2.c
> index 6c7c929c7765..5b60beb7d0eb 100644
> --- a/drivers/clk/shmobile/clk-emev2.c
> +++ b/drivers/clk/shmobile/clk-emev2.c
> @@ -34,7 +34,7 @@
>  static DEFINE_SPINLOCK(lock);
>  
>  /* not pretty, but hey */
> -void __iomem *smu_base;
> +static void __iomem *smu_base;
>  
>  static void __init emev2_smu_write(unsigned long value, int offs)
>  {
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 4/4] MAINTAINERS: add myself as ARM/UniPhier maintainer

2015-05-06 Thread Masahiro Yamada

Signed-off-by: Masahiro Yamada 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b399b34..3f4060f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1525,6 +1525,13 @@ F:   drivers/rtc/rtc-ab3100.c
 F: drivers/rtc/rtc-coh901331.c
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
 
+ARM/UNIPHIER ARCHITECTURE
+M: Masahiro Yamada 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-uniphier/
+N: uniphier
+
 ARM/Ux500 ARM ARCHITECTURE
 M: Linus Walleij 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-- 
1.9.1

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

[PATCH v6 3/4] ARM: dts: UniPhier: add support for UniPhier SoCs and boards

2015-05-06 Thread Masahiro Yamada

Initial device trees for UniPhier SoCs: PH1-sLD3, PH1-LD4, PH1-Pro4,
and PH1-sLD8.

Signed-off-by: Masahiro Yamada 
---

Changes in v6:
  - Remove redundant interrupt-parent property from timer nodes.

Changes in v5: None
Changes in v4:
  - Add system-bus-controller-misc node instead of uniphier-smp-reg node

Changes in v3:
  - License under GPL/X11
  - Drop "earlyprintk" kernel-parameter, add "stdout-path" property
  - Add syscon device for SMP boot support in order not to
hard-code register address in platsmp.c

Changes in v2: None

 arch/arm/boot/dts/Makefile   |   5 ++
 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts   |  79 ++
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi  | 110 +
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts  |  79 ++
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 117 +++
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts  |  80 ++
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 117 +++
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts  |  79 ++
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 110 +
 arch/arm/boot/dts/uniphier-support-card.dtsi |  66 +++
 10 files changed, 842 insertions(+)
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
 create mode 100644 arch/arm/boot/dts/uniphier-support-card.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 86217db..558b787 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -600,6 +600,11 @@ dtb-$(CONFIG_ARCH_U8500) += \
ste-hrefv60plus-tvk.dtb \
ste-ccu8540.dtb \
ste-ccu9540.dtb
+dtb-$(CONFIG_ARCH_UNIPHIER) += \
+   uniphier-ph1-sld3-ref.dtb \
+   uniphier-ph1-ld4-ref.dtb \
+   uniphier-ph1-pro4-ref.dtb \
+   uniphier-ph1-sld8-ref.dtb
 dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
versatile-pb.dtb
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts 
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
new file mode 100644
index 000..200b0c9
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -0,0 +1,79 @@
+/*
+ * Device Tree Source for UniPhier PH1-LD4 Reference Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-ld4.dtsi"
+/include/ "uniphier-support-card.dtsi"
+
+/ {
+   model = "UniPhier PH1-LD4 Reference Board";
+   compatible = "socionext,ph1-ld4-ref", "socionext,ph1-ld4";
+
+   memory {
+   device_type

Re: [PATCH] arm, imx6, dts: add DT for aristainetos2 board

2015-05-06 Thread Heiko Schocher


Hello Sascha,

Am 07.05.2015 06:25, schrieb Sascha Hauer:

On Wed, May 06, 2015 at 10:06:21AM +0200, Heiko Schocher wrote:

This patch add support for the imx6dl based aristainetos2 board
with following configuration:

CPU:   Freescale i.MX6DL rev1.1 at 792 MHz
MReset cause: POR
MBoard: aristaitenos2
DRAM:  1 GiB
NAND:  1024 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total 16 MiB
Display: lb07wv8 (800x480)

As this board can used with 2 different display types, the
differences between them are extracted into 2 DTS files, and
the common settings are collected in a common file.

Signed-off-by: Heiko Schocher 
---

  arch/arm/boot/dts/imx6dl-aristainetos2_4.dts | 124 ++
  arch/arm/boot/dts/imx6dl-aristainetos2_7.dts |  63 +++
  arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi | 631 +++
  3 files changed, 818 insertions(+)
  create mode 100644 arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
  create mode 100644 arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
  create mode 100644 arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi



[...]


+
+ {
+   clock-frequency = <10>;


I wonder why I see so many I2C nodes with this in this and other board
dts files. Are all these buses so slow? Why not 40? Also 10 is
the default anyway.


Good question... I remove the clock-frequency, as 10 is the default.


+
+   gpio {
+   pinctrl_gpio: gpiogrp {
+   fsl,pins = <
+   MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25  0x1b0b0 
/* led enable */
+   MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0x1b0b0 
/* backlight enable */
+   MX6QDL_PAD_NANDF_CS2__GPIO6_IO150x1b0b0 
/* LCD power enable */
+   MX6QDL_PAD_NANDF_CS3__GPIO6_IO160x1b0b0 
/* led yellow */
+   MX6QDL_PAD_EIM_EB0__GPIO2_IO28  0x1b0b0 
/* led red */
+   MX6QDL_PAD_EIM_A24__GPIO5_IO04  0x1b0b0 
/* led green */
+   MX6QDL_PAD_EIM_EB1__GPIO2_IO29  0x1b0b0 
/* led blue */
+   MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1b0b0 
/* Profibus IRQ */
+   MX6QDL_PAD_SD3_DAT6__GPIO6_IO18 0x1b0b0 
/* FPGA IRQ */
+   MX6QDL_PAD_EIM_A23__GPIO6_IO06  0x1b0b0 
/* spi bus #2 SS driver enable */
+   MX6QDL_PAD_GPIO_18__GPIO7_IO13  0x1b0b0 
/* RST_LOC# PHY reset input (has pull-down!)*/
+   MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID   0x1b0b0 
/* USB_OTG_ID = GPIO1_24*/
+   MX6QDL_PAD_SD3_RST__GPIO7_IO08  0x1b0b0 
/* SD2 level shifter output enable */
+   MX6QDL_PAD_ENET_RXD0__GPIO1_IO270x1b0b0 
/* SD1 card detect input */
+   MX6QDL_PAD_DI0_PIN4__GPIO4_IO20 0x1b0b0 
/* SD1 write protect input */
+   MX6QDL_PAD_GPIO_19__GPIO4_IO05  0x1b0b0 
/* SD2 card detect input */
+   MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x1b0b0 
/* SD2 write protect input */


Shouldn't the SD specific pins in the usdhc nodes below? Also backlight
enable, LEDs could also be moved to the corresponding device nodes.


Yep, move them.


+   MX6QDL_PAD_SD4_DAT1__GPIO2_IO09 0x1b0b0 
/* Touchscreen IRQ */
+   MX6QDL_PAD_EIM_A22__GPIO2_IO16  0x1b0b0 
/* PCIe reset */
+   >;
+   };
+   };
+
+   gpmi-nand {
+   pinctrl_gpmi_nand: gpmi-nand {
+   fsl,pins = <
+   MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
+   MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
+   MX6QDL_PAD_NANDF_WP_B__NAND_WP_B   0xb0b1
+   MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
+   MX6QDL_PAD_NANDF_CS0__NAND_CE0_B   0xb0b1
+   MX6QDL_PAD_SD4_CMD__NAND_RE_B  0xb0b1
+   MX6QDL_PAD_SD4_CLK__NAND_WE_B  0xb0b1
+   MX6QDL_PAD_NANDF_D0__NAND_DATA00   0xb0b1
+   MX6QDL_PAD_NANDF_D1__NAND_DATA01   0xb0b1
+   MX6QDL_PAD_NANDF_D2__NAND_DATA02   0xb0b1
+   MX6QDL_PAD_NANDF_D3__NAND_DATA03   0xb0b1
+   MX6QDL_PAD_NANDF_D4__NAND_DATA04   0xb0b1
+   MX6QDL_PAD_NANDF_D5__NAND_DATA05   0xb0b1
+   MX6QDL_PAD_NANDF_D6__NAND_DATA06   0xb0b1
+   MX6QDL_PAD_NANDF_D7__NAND_DATA07   0xb0b1
+   >;
+   };
+   };
+
+

[PATCH v6 2/4] ARM: multi_v7_defconfig: enable UniPhier SoC family

2015-05-06 Thread Masahiro Yamada

Add UniPhier, a new citizen in the ARM multi platform.

Signed-off-by: Masahiro Yamada 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index dca6983..a80ed4e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -83,6 +83,7 @@ CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_ARCH_TEGRA_124_SOC=y
 CONFIG_TEGRA_EMC_SCALING_ENABLE=y
+CONFIG_ARCH_UNIPHIER=y
 CONFIG_ARCH_U8500=y
 CONFIG_MACH_HREFV60=y
 CONFIG_MACH_SNOWBALL=y
-- 
1.9.1

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

[PATCH v6 1/4] ARM: UniPhier: add basic support for UniPhier architecture

2015-05-06 Thread Masahiro Yamada

Initial commit for a new SoC family, UniPhier, developed by
Socionext Inc. (formerly, System LSI Business Division of
Panasonic Corporation).

This commit includes a minimal set of components for booting the
kernel, including SMP support.

Signed-off-by: Masahiro Yamada 
---

Changes in v6: None
Changes in v5:
  - Move syscon_regmap_lookup_by_compatible() call to smp_prepare_cpus handler

Changes in v4:
  - Access to SMP register with base + offset(0x1208).

Changes in v3:
  - Replace  with 
  - Rename uniphier_board_dt_compat to uniphier_dt_compat
  - Move uniphier_secondary_startup into platsmp.c as __naked function
  - Add return before "err:" label (bug fix)
  - Use syscon driver rather than hard-coded register address

Changes in v2:
  - Fix SoC compatible string
"socionext,ph1-proxstream2" -> "socionext,proxstream2"

 arch/arm/Kconfig  |  2 +
 arch/arm/Makefile |  1 +
 arch/arm/mach-uniphier/Kconfig| 11 +
 arch/arm/mach-uniphier/Makefile   |  2 +
 arch/arm/mach-uniphier/platsmp.c  | 90 +++
 arch/arm/mach-uniphier/uniphier.c | 30 +
 6 files changed, 136 insertions(+)
 create mode 100644 arch/arm/mach-uniphier/Kconfig
 create mode 100644 arch/arm/mach-uniphier/Makefile
 create mode 100644 arch/arm/mach-uniphier/platsmp.c
 create mode 100644 arch/arm/mach-uniphier/uniphier.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 45df48b..b2e0d988 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -937,6 +937,8 @@ source "arch/arm/mach-tegra/Kconfig"
 
 source "arch/arm/mach-u300/Kconfig"
 
+source "arch/arm/mach-uniphier/Kconfig"
+
 source "arch/arm/mach-ux500/Kconfig"
 
 source "arch/arm/mach-versatile/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 985227c..fe8f9ef 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -200,6 +200,7 @@ machine-$(CONFIG_ARCH_SUNXI)+= sunxi
 machine-$(CONFIG_ARCH_TEGRA)   += tegra
 machine-$(CONFIG_ARCH_U300)+= u300
 machine-$(CONFIG_ARCH_U8500)   += ux500
+machine-$(CONFIG_ARCH_UNIPHIER)+= uniphier
 machine-$(CONFIG_ARCH_VERSATILE)   += versatile
 machine-$(CONFIG_ARCH_VEXPRESS)+= vexpress
 machine-$(CONFIG_ARCH_VT8500)  += vt8500
diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
new file mode 100644
index 000..a017b1d
--- /dev/null
+++ b/arch/arm/mach-uniphier/Kconfig
@@ -0,0 +1,11 @@
+config ARCH_UNIPHIER
+   bool "Socionext UniPhier SoCs"
+   depends on ARCH_MULTI_V7
+   select ARM_AMBA
+   select ARM_GLOBAL_TIMER
+   select ARM_GIC
+   select HAVE_ARM_SCU
+   select HAVE_ARM_TWD
+   help
+ Support for UniPhier SoC family developed by Socionext Inc.
+ (formerly, System LSI Business Division of Panasonic Corporation)
diff --git a/arch/arm/mach-uniphier/Makefile b/arch/arm/mach-uniphier/Makefile
new file mode 100644
index 000..60bd226
--- /dev/null
+++ b/arch/arm/mach-uniphier/Makefile
@@ -0,0 +1,2 @@
+obj-y  := uniphier.o
+obj-$(CONFIG_SMP)  += platsmp.o
diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
new file mode 100644
index 000..5943e1c
--- /dev/null
+++ b/arch/arm/mach-uniphier/platsmp.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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 
+
+static struct regmap *sbcm_regmap;
+
+static void __init uniphier_smp_prepare_cpus(unsigned int max_cpus)
+{
+   static cpumask_t only_cpu_0 = { CPU_BITS_CPU0 };
+   unsigned long scu_base_phys = 0;
+   void __iomem *scu_base;
+
+   sbcm_regmap = syscon_regmap_lookup_by_compatible(
+   "socionext,uniphier-system-bus-controller-misc");
+   if (IS_ERR(sbcm_regmap)) {
+   pr_err("failed to regmap system-bus-controller-misc\n");
+   goto err;
+   }
+
+   if (scu_a9_has_base())
+   scu_base_phys = scu_a9_get_base();
+
+   if (!scu_base_phys) {
+   pr_err("failed to get scu base\n");
+   goto err;
+   }
+
+   scu_base = ioremap(scu_base_phys, SZ_128);
+   if (!scu_base) {
+   pr_err("failed to remap scu base (0x%08lx)\n", scu_base_phys);
+   goto err;
+   }
+
+   scu_enable(scu_base);
+   iounmap(scu_base);
+
+   return;

[PATCH v6 0/4] ARM: SoC: add a new platform, UniPhier (arch/arm/mach-uniphier)

2015-05-06 Thread Masahiro Yamada


This is an initial series for supporting Socionext UniPhier SoCs,
based on ARM Cortex-A9, mainly used for digital TVs, video recorders, etc.


Masahiro Yamada (4):
  ARM: UniPhier: add basic support for UniPhier architecture
  ARM: multi_v7_defconfig: enable UniPhier SoC family
  ARM: dts: UniPhier: add support for UniPhier SoCs and boards
  MAINTAINERS: add myself as ARM/UniPhier maintainer

 MAINTAINERS  |   7 ++
 arch/arm/Kconfig |   2 +
 arch/arm/Makefile|   1 +
 arch/arm/boot/dts/Makefile   |   5 ++
 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts   |  79 ++
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi  | 110 +
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts  |  79 ++
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 117 +++
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts  |  80 ++
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 117 +++
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts  |  79 ++
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 110 +
 arch/arm/boot/dts/uniphier-support-card.dtsi |  66 +++
 arch/arm/configs/multi_v7_defconfig  |   1 +
 arch/arm/mach-uniphier/Kconfig   |  11 +++
 arch/arm/mach-uniphier/Makefile  |   2 +
 arch/arm/mach-uniphier/platsmp.c |  90 +
 arch/arm/mach-uniphier/uniphier.c|  30 +++
 18 files changed, 986 insertions(+)
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
 create mode 100644 arch/arm/boot/dts/uniphier-support-card.dtsi
 create mode 100644 arch/arm/mach-uniphier/Kconfig
 create mode 100644 arch/arm/mach-uniphier/Makefile
 create mode 100644 arch/arm/mach-uniphier/platsmp.c
 create mode 100644 arch/arm/mach-uniphier/uniphier.c

-- 
1.9.1

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

Re: [PATCH v6 3/4] pwm: kona: Fix incorrect config, disable, and polarity procedures

2015-05-06 Thread Tim Kryger

On Fri, Apr 10, 2015 at 11:58 AM, Jonathan Richardson
 wrote:

> The polarity procedure no longer applies the settings to change the
> output signal because it can't be called when the pwm is enabled anyway.
> The polarity is only updated in the control register. The correct
> polarity will be applied on enable. The old method of applying changes
> would result in no signal when the polarity was changed. The new
> apply_settings function would fix this problem but it isn't required
> anyway.

Why does this bug fix need to alter when polarity changes take effect?

That is an an unrelated change and I don't really agree with it.

> /* If duty_ns or period_ns are not achievable then return */
> -   if (pc < PERIOD_COUNT_MIN || dc < DUTY_CYCLE_HIGH_MIN)
> +   if (pc < PERIOD_COUNT_MIN) {
> +   dev_warn(chip->dev,
> +   "%s: pwm[%d]: period=%d is not achievable, 
> pc=%lu, prescale=%lu\n",
> +   __func__, chan, period_ns, pc, prescale);
> +   return -EINVAL;
> +   }
> +
> +   /* If duty_ns is not achievable then return */
> +   if (dc < DUTY_CYCLE_HIGH_MIN) {
> +   if (0 != duty_ns) {
> +   dev_warn(chip->dev,
> +   "%s: pwm[%d]: duty cycle=%d is not 
> achievable, dc=%lu, prescale=%lu\n",
> +   __func__, chan, duty_ns, dc, 
> prescale);
> +   }
> return -EINVAL;
> +   }
>
> /* If pc and dc are in bounds, the calculation is done */
> if (pc <= PERIOD_COUNT_MAX && dc <= DUTY_CYCLE_HIGH_MAX)
> break;
>
> /* Otherwise, increase prescale and recalculate pc and dc */
> -   if (++prescale > PRESCALE_MAX)
> +   if (++prescale > PRESCALE_MAX) {
> +   dev_warn(chip->dev,
> +   "%s: pwm[%d]: Prescale (=%lu) within max 
> (=%d) for period=%d and duty cycle=%d is not achievable\n",
> +   __func__, chan, prescale, PRESCALE_MAX,
> +   period_ns, duty_ns);
> return -EINVAL;
> +   }
> }

This extra debug output seems helpful but could you put it in its own
commit and keep this focused on fixing the instability you observed?

> +   /*
> +* Clear trigger bit but set smooth bit to maintain old
> +* output.
> +*/
> +   value |= 1 << PWM_CONTROL_SMOOTH_SHIFT(chan);
> +   value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan));
> +   writel(value, kp->base + PWM_CONTROL_OFFSET);
> +

The above lines are duplicated below.  Perhaps a function is in order?

> +   /* Set smooth type to 1 and disable */
> +   value |= 1 << PWM_CONTROL_SMOOTH_SHIFT(chan);
> +   value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan));
> +   writel(value, kp->base + PWM_CONTROL_OFFSET);

It seems like the important parts of the fix could be distilled down
to something like this:

diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
index 02bc048..4ff500c 100644
--- a/drivers/pwm/pwm-bcm-kona.c
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -76,7 +76,8 @@ static inline struct kona_pwmc *to_kona_pwmc(struct
pwm_chip *_chip)
   return container_of(_chip, struct kona_pwmc, chip);
 }

-static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
+static void kona_pwmc_prepare_for_settings(struct kona_pwmc *kp,
+ unsigned int chan)
 {
   unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);

@@ -85,10 +86,19 @@ static void kona_pwmc_apply_settings(struct
kona_pwmc *kp, unsigned int chan)
   value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan));
   writel(value, kp->base + PWM_CONTROL_OFFSET);

+  ndelay(400);
+}
+
+static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
+{
+  unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
+
   /* Set trigger bit and clear smooth bit to apply new settings */
   value &= ~(1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
   value |= 1 << PWM_CONTROL_TRIGGER_SHIFT(chan);
   writel(value, kp->base + PWM_CONTROL_OFFSET);
+
+  ndelay(400);
 }

 static int kona_pwmc_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -135,6 +145,8 @@ static int kona_pwmc_config(struct pwm_chip *chip,
struct pwm_device *pwm,

   /* If the PWM channel is enabled, write the settings to the HW */
   if (test_bit(PWMF_ENABLED, >flags)) {
+kona_pwmc_prepare_for_settings(kp, chan);
+
 value = readl(kp->base + PRESCALE_OFFSET);
 value &= ~PRESCALE_MASK(chan);
 value |= prescale << PRESCALE_SHIFT(chan);
@@

Re: [PATCH] arm, imx6, dts: add DT for aristainetos2 board

2015-05-06 Thread Sascha Hauer

On Wed, May 06, 2015 at 10:06:21AM +0200, Heiko Schocher wrote:
> This patch add support for the imx6dl based aristainetos2 board
> with following configuration:
> 
> CPU:   Freescale i.MX6DL rev1.1 at 792 MHz
> MReset cause: POR
> MBoard: aristaitenos2
> DRAM:  1 GiB
> NAND:  1024 MiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> SF: Detected N25Q128A with page size 256 Bytes, erase size 64 KiB, total 16 
> MiB
> Display: lb07wv8 (800x480)
> 
> As this board can used with 2 different display types, the
> differences between them are extracted into 2 DTS files, and
> the common settings are collected in a common file.
> 
> Signed-off-by: Heiko Schocher 
> ---
> 
>  arch/arm/boot/dts/imx6dl-aristainetos2_4.dts | 124 ++
>  arch/arm/boot/dts/imx6dl-aristainetos2_7.dts |  63 +++
>  arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi | 631 
> +++
>  3 files changed, 818 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-aristainetos2_4.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-aristainetos2_7.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
> 

[...]

> +
> + {
> + clock-frequency = <10>;

I wonder why I see so many I2C nodes with this in this and other board
dts files. Are all these buses so slow? Why not 40? Also 10 is
the default anyway.

> +
> + gpio {
> + pinctrl_gpio: gpiogrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25  0x1b0b0 
> /* led enable */
> + MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0x1b0b0 
> /* backlight enable */
> + MX6QDL_PAD_NANDF_CS2__GPIO6_IO150x1b0b0 
> /* LCD power enable */
> + MX6QDL_PAD_NANDF_CS3__GPIO6_IO160x1b0b0 
> /* led yellow */
> + MX6QDL_PAD_EIM_EB0__GPIO2_IO28  0x1b0b0 
> /* led red */
> + MX6QDL_PAD_EIM_A24__GPIO5_IO04  0x1b0b0 
> /* led green */
> + MX6QDL_PAD_EIM_EB1__GPIO2_IO29  0x1b0b0 
> /* led blue */
> + MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1b0b0 
> /* Profibus IRQ */
> + MX6QDL_PAD_SD3_DAT6__GPIO6_IO18 0x1b0b0 
> /* FPGA IRQ */
> + MX6QDL_PAD_EIM_A23__GPIO6_IO06  0x1b0b0 
> /* spi bus #2 SS driver enable */
> + MX6QDL_PAD_GPIO_18__GPIO7_IO13  0x1b0b0 
> /* RST_LOC# PHY reset input (has pull-down!)*/
> + MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID   0x1b0b0 
> /* USB_OTG_ID = GPIO1_24*/
> + MX6QDL_PAD_SD3_RST__GPIO7_IO08  0x1b0b0 
> /* SD2 level shifter output enable */
> + MX6QDL_PAD_ENET_RXD0__GPIO1_IO270x1b0b0 
> /* SD1 card detect input */
> + MX6QDL_PAD_DI0_PIN4__GPIO4_IO20 0x1b0b0 
> /* SD1 write protect input */
> + MX6QDL_PAD_GPIO_19__GPIO4_IO05  0x1b0b0 
> /* SD2 card detect input */
> + MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x1b0b0 
> /* SD2 write protect input */

Shouldn't the SD specific pins in the usdhc nodes below? Also backlight
enable, LEDs could also be moved to the corresponding device nodes.

> + MX6QDL_PAD_SD4_DAT1__GPIO2_IO09 0x1b0b0 
> /* Touchscreen IRQ */
> + MX6QDL_PAD_EIM_A22__GPIO2_IO16  0x1b0b0 
> /* PCIe reset */
> + >;
> + };
> + };
> +
> + gpmi-nand {
> + pinctrl_gpmi_nand: gpmi-nand {
> + fsl,pins = <
> + MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
> + MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
> + MX6QDL_PAD_NANDF_WP_B__NAND_WP_B   0xb0b1
> + MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
> + MX6QDL_PAD_NANDF_CS0__NAND_CE0_B   0xb0b1
> + MX6QDL_PAD_SD4_CMD__NAND_RE_B  0xb0b1
> + MX6QDL_PAD_SD4_CLK__NAND_WE_B  0xb0b1
> + MX6QDL_PAD_NANDF_D0__NAND_DATA00   0xb0b1
> + MX6QDL_PAD_NANDF_D1__NAND_DATA01   0xb0b1
> + MX6QDL_PAD_NANDF_D2__NAND_DATA02   0xb0b1
> + MX6QDL_PAD_NANDF_D3__NAND_DATA03   0xb0b1
> + MX6QDL_PAD_NANDF_D4__NAND_DATA04   0xb0b1
> + MX6QDL_PAD_NANDF_D5__NAND_DATA05   0xb0b1
> + MX6QDL_PAD_NANDF_D6__NAND_DATA06   0xb0b1
> + MX6QDL_PAD_NANDF_D7__NAND_DATA07   0xb0b1
> + >;
> + };
> + };
> +
> + i2c1 {
> + pinctrl_i2c1: i2c1grp {
> +

Re: [PATCH v10 05/19] Add common asm-offsets.h

2015-05-06 Thread Yoshinori Sato

At Mon, 04 May 2015 16:46:54 +0200,
Arnd Bergmann wrote:
> 
> On Monday 04 May 2015 19:41:48 Yoshinori Sato wrote:
> > Signed-off-by: Yoshinori Sato 
> > ---
> >  include/asm-generic/asm-offsets.h | 1 +
> >  1 file changed, 1 insertion(+)
> >  create mode 100644 include/asm-generic/asm-offsets.h
> > 
> > diff --git a/include/asm-generic/asm-offsets.h 
> > b/include/asm-generic/asm-offsets.h
> > new file mode 100644
> > index 000..d370ee3
> > --- /dev/null
> > +++ b/include/asm-generic/asm-offsets.h
> > @@ -0,0 +1 @@
> > +#include 
> > 
> 
> Please add  a short patch description, and my "Acked-by: Arnd Bergmann
> ", so it can get merged through your tree.
> 
>   Arnd
> 

OK.
I'll add next patch.

-- 
Yoshinori Sato

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

Re: [PATCH v10 00/19] Re-introduce h8300 architecture

2015-05-06 Thread Yoshinori Sato

At Mon, 4 May 2015 19:27:00 -0700,
Guenter Roeck wrote:
> 
> On Mon, May 04, 2015 at 07:41:43PM +0900, Yoshinori Sato wrote:
> > Hello.
> > I will re-introducing h8300.
> > 
> 
> Hi,
> 
> With "make ARCH=h8300 edosk2674_defconfig; make ARCH=h8300",
> I see the following build error:
> 
> scripts/Makefile.build:44: arch/h8300/boot/dtb/Makefile: No such file or 
> directory
> make[1]: *** No rule to make target 'arch/h8300/boot/dtb/Makefile'.  Stop.
> 
> After fixing this up with
> 
> diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile
> index c2b24c9..f547870 100644
> --- a/arch/h8300/Makefile
> +++ b/arch/h8300/Makefile
> @@ -26,7 +26,7 @@ CROSS_COMPILE := h8300-unknown-linux-
> 
>  core-y += arch/$(ARCH)/kernel/ arch/$(ARCH)/mm/ arch/h8300/boot/dts/
>  ifneq '$(CONFIG_H8300_BUILTIN_DTB)' '""'
> -core-y += arch/h8300/boot/dtb/
> +core-y += arch/h8300/boot/dts/
>  endif
>  
>  libs-y += arch/$(ARCH)/lib/
> 
> I get
> 
> arch/h8300/boot/dts/built-in.o: In function `__dtb_edosk2674_end':
> (.dtb.init.rodata+0x8fb): multiple definition of `__dtb_edosk2674_end'
> arch/h8300/boot/dts/built-in.o:(.dtb.init.rodata+0x8fb): first defined here
> arch/h8300/boot/dts/built-in.o: In function `__dtb_edosk2674_begin':
> (.dtb.init.rodata+0x0): multiple definition of `__dtb_edosk2674_begin'
> arch/h8300/boot/dts/built-in.o:(.dtb.init.rodata+0x0): first defined here
> Makefile:932: recipe for target 'vmlinux' failed
> 
> This is with compiler and binutils built as you had provided earlier.
> 
> ---
> 
> Other configurations fail to build with
> 
> h8300-unknown-linux-ld: cannot find arch/h8300/boot/dts/built-in.o: No such 
> file or directory
> Makefile:932: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
> 
> ---
> 
> Switching from edosk2674_defconfig to h8300h-sim_defconfig without "make
> mrproper" results in:
> 
> h8300-unknown-linux-ld: h8300s architecture of input file
> `arch/h8300/boot/dts/built-in.o' is incompatible with h8300h output
> 
> ---
> 
> Results are with git://git.sourceforge.jp/gitroot/uclinux-h8/linux.git,
> branch h8300.
> 
> Guenter

Thanks testing.
It looks Makefile and defconfig problem.

I'll fix next release.

-- 
Yoshinori Sato

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

Re: [PATCH] sched/core: Add empty 'gov_cfs_update_cpu' function definition for NON-SMP systems

2015-05-06 Thread Michael Turquette

Quoting Abel Vesa (2015-05-06 09:50:40)
> If CONFIG_SMP is not defined the build will fail due to
> function 'gov_cfs_update_cpu' definition missing.
> Added empty static inline definition for NON-SMP systems.
> 
> This patch applies to:
> https://git.linaro.org/people/mike.turquette/linux.git sched-freq
> 
> Signed-off-by: Abel Vesa 

Thanks Abel. I'll fold this change in.

Regards,
Mike

> ---
>  kernel/sched/sched.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index ec23523..3d0996e 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -1413,6 +1413,7 @@ static inline void sched_rt_avg_update(struct rq *rq, 
> u64 rt_delta)
>  #else
>  static inline void sched_rt_avg_update(struct rq *rq, u64 rt_delta) { }
>  static inline void sched_avg_update(struct rq *rq) { }
> +static inline void gov_cfs_update_cpu(int cpu) {}
>  #endif
>  
>  extern void start_bandwidth_timer(struct hrtimer *period_timer, ktime_t 
> period);
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build warning after merge of the tegra tree

2015-05-06 Thread Stephen Rothwell

Hi all,

After merging the tegra tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/clk/tegra/clk-emc.c: In function 'tegra_clk_register_emc':
drivers/clk/tegra/clk-emc.c:519:20: warning: assignment discards 'const' 
qualifier from pointer target type
  init.parent_names = emc_parent_clk_names;
^

Introduced by commit dc9fdb640b9f ("clk: tegra: Add EMC clock driver").

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


pgpcZ1uoPP0qA.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the rcu tree with the tip tree

2015-05-06 Thread Stephen Rothwell

Hi Paul,

Today's linux-next merge of the rcu tree got conflicts in
include/linux/rcupdate.h, include/linux/rcutree.h and
kernel/rcu/tree_plugin.h between commit c1ad348b452a ("tick: Nohz:
Rework next timer evaluation") from the tip tree and commit
f49f794683d6 ("rcu: Eliminate a few CONFIG_RCU_NOCB_CPU_ALL #ifdefs")
from the rcu tree.

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

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

diff --cc include/linux/rcupdate.h
index 0627a447c589,03a899aabd17..
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@@ -1155,13 -1099,13 +1101,13 @@@ static inline notrace void rcu_read_unl
  #define kfree_rcu(ptr, rcu_head)  \
__kfree_rcu(&((ptr)->rcu_head), offsetof(typeof(*(ptr)), rcu_head))
  
- #if defined(CONFIG_TINY_RCU) || defined(CONFIG_RCU_NOCB_CPU_ALL)
+ #ifdef CONFIG_TINY_RCU
 -static inline int rcu_needs_cpu(unsigned long *delta_jiffies)
 +static inline int rcu_needs_cpu(u64 basemono, u64 *nextevt)
  {
 -  *delta_jiffies = ULONG_MAX;
 +  *nextevt = KTIME_MAX;
return 0;
  }
- #endif /* #if defined(CONFIG_TINY_RCU) || defined(CONFIG_RCU_NOCB_CPU_ALL) */
+ #endif /* #ifdef CONFIG_TINY_RCU */
  
  #if defined(CONFIG_RCU_NOCB_CPU_ALL)
  static inline bool rcu_is_nocb_cpu(int cpu) { return true; }
diff --cc include/linux/rcutree.h
index db2e31beaae7,3fa4a43ab415..
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@@ -31,9 -31,7 +31,7 @@@
  #define __LINUX_RCUTREE_H
  
  void rcu_note_context_switch(void);
- #ifndef CONFIG_RCU_NOCB_CPU_ALL
 -int rcu_needs_cpu(unsigned long *delta_jiffies);
 +int rcu_needs_cpu(u64 basem, u64 *nextevt);
- #endif /* #ifndef CONFIG_RCU_NOCB_CPU_ALL */
  void rcu_cpu_stall_reset(void);
  
  /*
diff --cc kernel/rcu/tree_plugin.h
index 0ef80a0bbabb,a2f64e4fdb57..
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@@ -1367,13 -1375,12 +1375,12 @@@ static void rcu_prepare_kthreads(int cp
   * Because we not have RCU_FAST_NO_HZ, just check whether this CPU needs
   * any flavor of RCU.
   */
- #ifndef CONFIG_RCU_NOCB_CPU_ALL
 -int rcu_needs_cpu(unsigned long *delta_jiffies)
 +int rcu_needs_cpu(u64 basemono, u64 *nextevt)
  {
 -  *delta_jiffies = ULONG_MAX;
 +  *nextevt = KTIME_MAX;
-   return rcu_cpu_has_callbacks(NULL);
+   return IS_ENABLED(CONFIG_RCU_NOCB_CPU_ALL)
+  ? 0 : rcu_cpu_has_callbacks(NULL);
  }
- #endif /* #ifndef CONFIG_RCU_NOCB_CPU_ALL */
  
  /*
   * Because we do not have RCU_FAST_NO_HZ, don't bother cleaning up
@@@ -1480,12 -1487,15 +1487,16 @@@ static bool __maybe_unused rcu_try_adva
   *
   * The caller must have disabled interrupts.
   */
- #ifndef CONFIG_RCU_NOCB_CPU_ALL
 -int rcu_needs_cpu(unsigned long *dj)
 +int rcu_needs_cpu(u64 basemono, u64 *nextevt)
  {
struct rcu_dynticks *rdtp = this_cpu_ptr(_dynticks);
 +  unsigned long dj;
  
+   if (IS_ENABLED(CONFIG_RCU_NOCB_CPU_ALL)) {
 -  *dj = ULONG_MAX;
++  *nextevt = KTIME_MAX;
+   return 0;
+   }
+ 
/* Snapshot to detect later posting of non-lazy callback. */
rdtp->nonlazy_posted_snap = rdtp->nonlazy_posted;
  
@@@ -1505,15 -1515,13 +1516,14 @@@
  
/* Request timer delay depending on laziness, and round. */
if (!rdtp->all_lazy) {
 -  *dj = round_up(rcu_idle_gp_delay + jiffies,
 +  dj = round_up(rcu_idle_gp_delay + jiffies,
   rcu_idle_gp_delay) - jiffies;
} else {
 -  *dj = round_jiffies(rcu_idle_lazy_gp_delay + jiffies) - jiffies;
 +  dj = round_jiffies(rcu_idle_lazy_gp_delay + jiffies) - jiffies;
}
 +  *nextevt = basemono + dj * TICK_NSEC;
return 0;
  }
- #endif /* #ifndef CONFIG_RCU_NOCB_CPU_ALL */
  
  /*
   * Prepare a CPU for idle from an RCU perspective.  The first major task


pgpjQtI4u7f0E.pgp
Description: OpenPGP digital signature

RE: [PATCH v5 1/6] x86/mm/pat: use pr_info() and friends

2015-05-06 Thread Elliott, Robert (Server Storage)

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> Sent: Thursday, April 30, 2015 3:25 PM
> Subject: [PATCH v5 1/6] x86/mm/pat: use pr_info() and friends
> 
...
> - printk(KERN_ERR "%s:%d map pfn expected mapping
> type %s"
> - " for [mem %#010Lx-%#010Lx], got %s\n",
> - current->comm, current->pid,
> - cattr_name(want_pcm),
> - (unsigned long long)paddr,
> - (unsigned long long)(paddr + size - 1),
> - cattr_name(pcm));
> + pr_err("%s:%d map pfn expected mapping type %s"
> +" for [mem %#010Lx-%#010Lx], got %s\n",

Since the patch joins some other print format strings split across 
lines (which checkpatch allows), you might want to join this one too.

...
> diff --git a/arch/x86/mm/pat_rbtree.c b/arch/x86/mm/pat_rbtree.c
...
>  failure:
> - printk(KERN_INFO "%s:%d conflicting memory types "
> + pr_info("%s:%d conflicting memory types "
>   "%Lx-%Lx %s<->%s\n", current->comm, current->pid, start,
>   end, cattr_name(found_type), cattr_name(match->type));

and that one.


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

Re: [HPDD-discuss] [PATCH] staging: lustre: code cleanup - variable declaration spacing

2015-05-06 Thread Dilger, Andreas

On 2015/05/06, 6:02 AM, "Mike Shuey"  wrote:

>Clean up spacing in some variable declarations, to be more consistent.
>
>It's small, but I need to start somewhere.  Please let me know if I'm not
>adhering to proper procedure for trivial cleanups.

It's actually Lustre coding style to align the variable declarations.
Is this something that causes checkpatch.pl to complain?  If not, I'd
prefer not to change all of these declarations, since it causes a lot
of code churn for very little benefit.

Cheers, Andreas

>Signed-off-by: Mike Shuey 
>---
> drivers/staging/lustre/lnet/lnet/acceptor.c |   32 ++--
> drivers/staging/lustre/lnet/lnet/api-ni.c   |  198 +++---
> drivers/staging/lustre/lnet/lnet/config.c   |  238
>+-
> drivers/staging/lustre/lnet/lnet/lib-eq.c   |   42 +++---
> 4 files changed, 255 insertions(+), 255 deletions(-)
>
>diff --git a/drivers/staging/lustre/lnet/lnet/acceptor.c
>b/drivers/staging/lustre/lnet/lnet/acceptor.c
>index 72fd1bf..69d4b19 100644
>--- a/drivers/staging/lustre/lnet/lnet/acceptor.c
>+++ b/drivers/staging/lustre/lnet/lnet/acceptor.c
>@@ -143,10 +143,10 @@ lnet_connect(struct socket **sockp, lnet_nid_t
>peer_nid,
>   __u32 local_ip, __u32 peer_ip, int peer_port)
> {
>   lnet_acceptor_connreq_t cr;
>-  struct socket  *sock;
>-  int  rc;
>-  int  port;
>-  int  fatal;
>+  struct socket *sock;
>+  int rc;
>+  int port;
>+  int fatal;
> 
>   CLASSERT(sizeof(cr) <= 16); /* not too big to be on the stack */
> 
>@@ -211,12 +211,12 @@ static int
> lnet_accept(struct socket *sock, __u32 magic)
> {
>   lnet_acceptor_connreq_t cr;
>-  __u32  peer_ip;
>-  int  peer_port;
>-  int  rc;
>-  int  flip;
>-  lnet_ni_t *ni;
>-  char   *str;
>+  __u32 peer_ip;
>+  int peer_port;
>+  int rc;
>+  int flip;
>+  lnet_ni_t *ni;
>+  char *str;
> 
>   LASSERT(sizeof(cr) <= 16);   /* not too big for the stack */
> 
>@@ -333,11 +333,11 @@ static int
> lnet_acceptor(void *arg)
> {
>   struct socket *newsock;
>-  int rc;
>-  __u32 magic;
>-  __u32 peer_ip;
>-  int peer_port;
>-  int secure = (int)((long_ptr_t)arg);
>+  int rc;
>+  __u32 magic;
>+  __u32 peer_ip;
>+  int peer_port;
>+  int secure = (int)((long_ptr_t)arg);
> 
>   LASSERT(lnet_acceptor_state.pta_sock == NULL);
> 
>@@ -444,7 +444,7 @@ accept2secure(const char *acc, long *sec)
> int
> lnet_acceptor_start(void)
> {
>-  int  rc;
>+  int rc;
>   long rc2;
>   long secure;
> 
>diff --git a/drivers/staging/lustre/lnet/lnet/api-ni.c
>b/drivers/staging/lustre/lnet/lnet/api-ni.c
>index 4a14e51..6910f56 100644
>--- a/drivers/staging/lustre/lnet/lnet/api-ni.c
>+++ b/drivers/staging/lustre/lnet/lnet/api-ni.c
>@@ -41,7 +41,7 @@
> 
> #define D_LNI D_CONSOLE
> 
>-lnet_t  the_lnet;/* THE state of the network */
>+lnet_t the_lnet; /* THE state of the network */
> EXPORT_SYMBOL(the_lnet);
> 
> 
>@@ -70,8 +70,8 @@ lnet_get_routes(void)
> static char *
> lnet_get_networks(void)
> {
>-  char   *nets;
>-  int rc;
>+  char *nets;
>+  int rc;
> 
>   if (*networks != 0 && *ip2nets != 0) {
>   LCONSOLE_ERROR_MSG(0x101, "Please specify EITHER 'networks' or
>'ip2nets' but not both at once\n");
>@@ -107,8 +107,8 @@ lnet_fini_locks(void)
> static int
> lnet_create_remote_nets_table(void)
> {
>-  int i;
>-  struct list_head*hash;
>+  int i;
>+  struct list_head *hash;
> 
>   LASSERT(the_lnet.ln_remote_nets_hash == NULL);
>   LASSERT(the_lnet.ln_remote_nets_hbits > 0);
>@@ -273,8 +273,8 @@ static void lnet_assert_wire_constants(void)
> static lnd_t *
> lnet_find_lnd_by_type(int type)
> {
>-  lnd_t *lnd;
>-  struct list_head *tmp;
>+  lnd_t *lnd;
>+  struct list_head *tmp;
> 
>   /* holding lnd mutex */
>   list_for_each(tmp, _lnet.ln_lnds) {
>@@ -325,7 +325,7 @@ void
> lnet_counters_get(lnet_counters_t *counters)
> {
>   lnet_counters_t *ctr;
>-  int i;
>+  int i;
> 
>   memset(counters, 0, sizeof(*counters));
> 
>@@ -353,7 +353,7 @@ void
> lnet_counters_reset(void)
> {
>   lnet_counters_t *counters;
>-  int i;
>+  int i;
> 
>   lnet_net_lock(LNET_LOCK_EX);
> 
>@@ -396,8 +396,8 @@ lnet_freelist_init(lnet_freelist_t *fl, int n, int
>size)
> void
> lnet_freelist_fini(lnet_freelist_t *fl)
> {
>-  struct list_head   *el;
>-  intcount;
>+  struct list_head *el;
>+  int count;
> 
>   if (fl->fl_nobjs == 0)
>   return;
>@@ -441,7 +441,7 @@ lnet_res_type2str(int type)
> static void
> lnet_res_container_cleanup(struct

[PATCH v2] powerpc/dts: Add and fix 1588 timer node for eTSEC

2015-05-06 Thread Yangbo Lu

Add 1588 timer node in files:
arch/powerpc/boot/dts/bsc9131rdb.dtsi
arch/powerpc/boot/dts/bsc9132qds.dtsi
arch/powerpc/boot/dts/p1010rdb.dtsi
arch/powerpc/boot/dts/p1020rdb-pd.dts
arch/powerpc/boot/dts/p1021rdb-pc.dtsi
arch/powerpc/boot/dts/p1022ds.dtsi
arch/powerpc/boot/dts/p1025twr.dtsi
Fix 1588 timer node in file:
arch/powerpc/boot/dts/p2020rdb-pc.dtsi

Signed-off-by: Yangbo Lu 
---
Changes for v2:
- Changed hex value to decimal value in dts
- Modified commit message
- Modified 1588 node in p2020rdb-pc.dtsi
---
 arch/powerpc/boot/dts/bsc9131rdb.dtsi  | 12 
 arch/powerpc/boot/dts/bsc9132qds.dtsi  | 12 
 arch/powerpc/boot/dts/p1010rdb.dtsi| 12 
 arch/powerpc/boot/dts/p1020rdb-pd.dts  | 12 
 arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 12 
 arch/powerpc/boot/dts/p1022ds.dtsi | 12 
 arch/powerpc/boot/dts/p1025twr.dtsi| 12 
 arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 12 ++--
 8 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi 
b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
index 45efcba..a6d533e 100644
--- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
+++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
@@ -80,6 +80,18 @@
status = "disabled";
};
 
+   ptp_clock@b0e00 {
+   compatible = "fsl,etsec-ptp";
+   reg = <0xb0e00 0xb0>;
+   interrupts = <68 2 0 0 69 2 0 0>;
+   fsl,tclk-period = <5>;
+   fsl,tmr-prsc= <2>;
+   fsl,tmr-add = <3435973837>;
+   fsl,tmr-fiper1  = <5>;
+   fsl,tmr-fiper2  = <0>;
+   fsl,max-adj = <24999>;
+   };
+
enet0: ethernet@b {
phy-handle = <>;
phy-connection-type = "rgmii-id";
diff --git a/arch/powerpc/boot/dts/bsc9132qds.dtsi 
b/arch/powerpc/boot/dts/bsc9132qds.dtsi
index af8e888..ef75804 100644
--- a/arch/powerpc/boot/dts/bsc9132qds.dtsi
+++ b/arch/powerpc/boot/dts/bsc9132qds.dtsi
@@ -87,6 +87,18 @@
};
};
 
+   ptp_clock@b0e00 {
+   compatible = "fsl,etsec-ptp";
+   reg = <0xb0e00 0xb0>;
+   interrupts = <68 2 0 0 69 2 0 0>;
+   fsl,tclk-period = <5>;
+   fsl,tmr-prsc= <2>;
+   fsl,tmr-add = <3435973837>;
+   fsl,tmr-fiper1  = <5>;
+   fsl,tmr-fiper2  = <0>;
+   fsl,max-adj = <24999>;
+   };
+
enet0: ethernet@b {
phy-handle = <>;
tbi-handle = <>;
diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi 
b/arch/powerpc/boot/dts/p1010rdb.dtsi
index ea534ef..1613678 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
@@ -186,6 +186,18 @@
};
};
 
+   ptp_clock@b0e00 {
+   compatible = "fsl,etsec-ptp";
+   reg = <0xb0e00 0xb0>;
+   interrupts = <68 2 0 0 69 2 0 0>;
+   fsl,tclk-period = <10>;
+   fsl,tmr-prsc= <2>;
+   fsl,tmr-add = <2147483670>;
+   fsl,tmr-fiper1  = <0>;
+   fsl,tmr-fiper2  = <0>;
+   fsl,max-adj = <1>;
+   };
+
enet0: ethernet@b {
phy-handle = <>;
phy-connection-type = "rgmii-id";
diff --git a/arch/powerpc/boot/dts/p1020rdb-pd.dts 
b/arch/powerpc/boot/dts/p1020rdb-pd.dts
index 987017e..52e8fe8 100644
--- a/arch/powerpc/boot/dts/p1020rdb-pd.dts
+++ b/arch/powerpc/boot/dts/p1020rdb-pd.dts
@@ -225,6 +225,18 @@
};
};
 
+   ptp_clock@b0e00 {
+   compatible = "fsl,etsec-ptp";
+   reg = <0xb0e00 0xb0>;
+   interrupts = <68 2 0 0 69 2 0 0>;
+   fsl,tclk-period = <10>;
+   fsl,tmr-prsc= <2>;
+   fsl,tmr-add = <2147483670>;
+   fsl,tmr-fiper1  = <0>;
+   fsl,tmr-fiper2  = <0>;
+   fsl,max-adj = <1>;
+   };
+
enet0: ethernet@b {
fixed-link = <1 1 1000 0 0>;
phy-connection-type = "rgmii-id";
diff --git a/arch/powerpc/boot/dts/p1021rdb-pc.dtsi 
b/arch/powerpc/boot/dts/p1021rdb-pc.dtsi
index d6274c5..a29c84a 100644
--- a/arch/powerpc/boot/dts/p1021rdb-pc.dtsi
+++ b/arch/powerpc/boot/dts/p1021rdb-pc.dtsi
@@ -224,6 +224,18 @@
};
};
 
+   ptp_clock@b0e00 {
+   compatible = "fsl,etsec-ptp";
+   reg = <0xb0e00 0xb0>;
+   interrupts = <68 2 0 0 69 2 0 0>;
+   fsl,tclk-period = <10>;
+   fsl,tmr-prsc= <2>;
+   fsl,tmr-add =

Re: [PATCH] mtd: Introduce CONFIG_MTD_RESERVE_END

2015-05-06 Thread Brian Norris

On Fri, May 01, 2015 at 01:57:13PM +0200, Jonas Gorski wrote:
> On Thu, Apr 30, 2015 at 7:36 PM, Ben Shelton  wrote:
> > The reason for doing this as a Kconfig option rather than with an additional
> > partition is that we use the same .itb boot image (and kernel arguments) for
> > a series of embedded controllers that have different NAND flash sizes, and 
> > we
> > use the '-' command line parameter to give the root partition all the 
> > available
> > space after the other partitions.
> 
> Wouldn't it make more sense to make cmdlineparts to recognize if it is
> run on a nand flash that has on-flash BBT enabled, and then reduce the
> SIZE_REMAINING partition's size by the amount of nand_bbt_descr's
> maxblocks * erase block size?

That's a possibility, but that seems like a bit too much hidden policy
to add on top of the cmdlineparts format, which is pretty precise.

A better improvement, if you're dead set on using cmdlineparts rather
than some other better parser, might be to support something like:

  mtdparts=name:-(main),bbt(1M)

So the "remaining space" partition will allow for following partitions.
IOW, you would need to handle this case, which is currently an error:

/* test if more partitions are following */
if (*s == ',') {
if (size == SIZE_REMAINING) {
printk(KERN_ERR ERRP "no partitions allowed after a 
fill-up partition\n");
return ERR_PTR(-EINVAL);
}
...
}

> Currently your proposed solution would break if boards have differing
> erase block sizes, or if some have NOR flash, which makes it an option
> for a rather narrow use case IMHO.

Yeah, consider this a NAK for the current patch.

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

Re: [KERNEL BUG] do_timer/tick_handover_do_timer 3.10.17

2015-05-06 Thread Mike Galbraith

On Wed, 2015-05-06 at 22:57 +0530, pawandeep oza wrote:

> but when say core0 has raised BUG..
...

> what is the right way to approach this problem

Look at the spot BUG() printed?  BUG() means "Way to go slick, the code
you fed me (file:line) is toxic.  Have a nice day, your ex-buddy core0".

-Mike

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

[PATCH v3 6/8] powernv/elog: Convert elog to opal irq domain

2015-05-06 Thread Alistair Popple

This patch converts the elog code to use the opal irq domain instead
of notifier events.

Signed-off-by: Alistair Popple 
---
 arch/powerpc/platforms/powernv/opal-elog.c | 32 +++---
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-elog.c 
b/arch/powerpc/platforms/powernv/opal-elog.c
index 38ce757..4949ef0 100644
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -10,6 +10,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -276,24 +277,15 @@ static void elog_work_fn(struct work_struct *work)
 
 static DECLARE_WORK(elog_work, elog_work_fn);
 
-static int elog_event(struct notifier_block *nb,
-   unsigned long events, void *change)
+static irqreturn_t elog_event(int irq, void *data)
 {
-   /* check for error log event */
-   if (events & OPAL_EVENT_ERROR_LOG_AVAIL)
-   schedule_work(_work);
-   return 0;
+   schedule_work(_work);
+   return IRQ_HANDLED;
 }
 
-static struct notifier_block elog_nb = {
-   .notifier_call  = elog_event,
-   .next   = NULL,
-   .priority   = 0
-};
-
 int __init opal_elog_init(void)
 {
-   int rc = 0;
+   int rc = 0, irq;
 
/* ELOG not supported by firmware */
if (!opal_check_token(OPAL_ELOG_READ))
@@ -305,10 +297,18 @@ int __init opal_elog_init(void)
return -1;
}
 
-   rc = opal_notifier_register(_nb);
+   irq = opal_event_request(ilog2(OPAL_EVENT_ERROR_LOG_AVAIL));
+   if (!irq) {
+   pr_err("%s: Can't register OPAL event irq (%d)\n",
+  __func__, irq);
+   return irq;
+   }
+
+   rc = request_irq(irq, elog_event,
+   IRQ_TYPE_LEVEL_HIGH, "opal-elog", NULL);
if (rc) {
-   pr_err("%s: Can't register OPAL event notifier (%d)\n",
-   __func__, rc);
+   pr_err("%s: Can't request OPAL event irq (%d)\n",
+  __func__, rc);
return rc;
}
 
-- 
1.8.3.2

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

[PATCH v3 8/8] opal: Remove events notifier

2015-05-06 Thread Alistair Popple

All users of the old opal events notifier have been converted over to
the irq domain so remove the event notifier functions.

Signed-off-by: Alistair Popple 
---
 arch/powerpc/platforms/powernv/opal-irqchip.c | 16 ++---
 arch/powerpc/platforms/powernv/opal.c | 84 +--
 arch/powerpc/platforms/powernv/powernv.h  |  1 -
 arch/powerpc/platforms/powernv/setup.c|  2 +-
 4 files changed, 8 insertions(+), 95 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c 
b/arch/powerpc/platforms/powernv/opal-irqchip.c
index 4b6f951..8c17d81 100644
--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -100,21 +100,17 @@ void opal_handle_events(uint64_t events)
 {
int virq, hwirq = 0;
u64 mask = opal_event_irqchip.mask;
-   u64 notifier_mask = 0;
 
-   while (events) {
+   while (events & mask) {
hwirq = fls64(events) - 1;
-   virq = irq_find_mapping(opal_event_irqchip.domain,
-   hwirq);
-   if (virq) {
-   if (BIT_ULL(hwirq) & mask)
+   if (BIT_ULL(hwirq) & mask) {
+   virq = irq_find_mapping(opal_event_irqchip.domain,
+   hwirq);
+   if (virq)
generic_handle_irq(virq);
-   } else
-   notifier_mask |= BIT_ULL(hwirq);
+   }
events &= ~BIT_ULL(hwirq);
}
-
-   opal_do_notifier(notifier_mask);
 }
 
 static irqreturn_t opal_interrupt(int irq, void *data)
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 0196220..a5e48cd 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -53,11 +53,7 @@ static int mc_recoverable_range_len;
 
 struct device_node *opal_node;
 static DEFINE_SPINLOCK(opal_write_lock);
-static ATOMIC_NOTIFIER_HEAD(opal_notifier_head);
 static struct atomic_notifier_head opal_msg_notifier_head[OPAL_MSG_TYPE_MAX];
-static DEFINE_SPINLOCK(opal_notifier_lock);
-static uint64_t last_notified_mask = 0x0ul;
-static atomic_t opal_notifier_hold = ATOMIC_INIT(0);
 static uint32_t opal_heartbeat;
 
 static void opal_reinit_cores(void)
@@ -223,82 +219,6 @@ static int __init opal_register_exception_handlers(void)
 }
 machine_early_initcall(powernv, opal_register_exception_handlers);
 
-int opal_notifier_register(struct notifier_block *nb)
-{
-   if (!nb) {
-   pr_warning("%s: Invalid argument (%p)\n",
-  __func__, nb);
-   return -EINVAL;
-   }
-
-   atomic_notifier_chain_register(_notifier_head, nb);
-   return 0;
-}
-EXPORT_SYMBOL_GPL(opal_notifier_register);
-
-int opal_notifier_unregister(struct notifier_block *nb)
-{
-   if (!nb) {
-   pr_warning("%s: Invalid argument (%p)\n",
-  __func__, nb);
-   return -EINVAL;
-   }
-
-   atomic_notifier_chain_unregister(_notifier_head, nb);
-   return 0;
-}
-EXPORT_SYMBOL_GPL(opal_notifier_unregister);
-
-void opal_do_notifier(uint64_t events)
-{
-   unsigned long flags;
-   uint64_t changed_mask;
-
-   if (atomic_read(_notifier_hold))
-   return;
-
-   spin_lock_irqsave(_notifier_lock, flags);
-   changed_mask = last_notified_mask ^ events;
-   last_notified_mask = events;
-   spin_unlock_irqrestore(_notifier_lock, flags);
-
-   /*
-* We feed with the event bits and changed bits for
-* enough information to the callback.
-*/
-   atomic_notifier_call_chain(_notifier_head,
-  events, (void *)changed_mask);
-}
-
-void opal_notifier_update_evt(uint64_t evt_mask,
- uint64_t evt_val)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(_notifier_lock, flags);
-   last_notified_mask &= ~evt_mask;
-   last_notified_mask |= evt_val;
-   spin_unlock_irqrestore(_notifier_lock, flags);
-}
-
-void opal_notifier_enable(void)
-{
-   int64_t rc;
-   __be64 evt = 0;
-
-   atomic_set(_notifier_hold, 0);
-
-   /* Process pending events */
-   rc = opal_poll_events();
-   if (rc == OPAL_SUCCESS && evt)
-   opal_do_notifier(be64_to_cpu(evt));
-}
-
-void opal_notifier_disable(void)
-{
-   atomic_set(_notifier_hold, 1);
-}
-
 /*
  * Opal message notifier based on message type. Allow subscribers to get
  * notified for specific messgae type.
@@ -571,10 +491,8 @@ int opal_handle_hmi_exception(struct pt_regs *regs)
 
local_paca->hmi_event_available = 0;
rc = opal_poll_events();
-   if (rc == OPAL_SUCCESS && evt) {
-   opal_do_notifier(be64_to_cpu(evt));
+   if (rc == OPAL_SUCCESS && evt)

[PATCH v3 1/8] powerpc/powernv: Add a virtual irqchip for opal events

2015-05-06 Thread Alistair Popple

Whenever an interrupt is received for opal the linux kernel gets a
bitfield indicating certain events that have occurred and need handling
by the various device drivers. Currently this is handled using a
notifier interface where we call every device driver that has
registered to receive opal events.

This approach has several drawbacks. For example each driver has to do
its own checking to see if the event is relevant as well as event
masking. There is also no easy method of recording the number of times
we receive particular events.

This patch solves these issues by exposing opal events via the
standard interrupt APIs by adding a new interrupt chip and
domain. Drivers can then register for the appropriate events using
standard kernel calls such as irq_of_parse_and_map().

Signed-off-by: Alistair Popple 
---

Changes from v2:
 - Addressed comments by Neelesh Gupta
 - Fixed soft-lockup bug reported by Neelesh in the opal-dump driver
 - Rebased on v4.1-rc1

 arch/powerpc/include/asm/opal.h   |   2 +
 arch/powerpc/platforms/powernv/Makefile   |   2 +-
 arch/powerpc/platforms/powernv/opal-irqchip.c | 248 ++
 arch/powerpc/platforms/powernv/opal.c |  70 +---
 arch/powerpc/platforms/powernv/powernv.h  |   4 +
 5 files changed, 260 insertions(+), 66 deletions(-)
 create mode 100644 arch/powerpc/platforms/powernv/opal-irqchip.c

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 042af1a..9ffd113 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -250,6 +250,8 @@ extern int opal_resync_timebase(void);

 extern void opal_lpc_init(void);

+extern int opal_event_request(unsigned int opal_event_nr);
+
 struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
 unsigned long vmalloc_size);
 void opal_free_sg_list(struct opal_sg_list *sg);
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index 33e44f3..f1d7de2 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,7 +1,7 @@
 obj-y  += setup.o opal-wrappers.o opal.o opal-async.o
 obj-y  += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
 obj-y  += rng.o opal-elog.o opal-dump.o opal-sysparam.o 
opal-sensor.o
-obj-y  += opal-msglog.o opal-hmi.o opal-power.o
+obj-y  += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o

 obj-$(CONFIG_SMP)  += smp.o subcore.o subcore-asm.o
 obj-$(CONFIG_PCI)  += pci.o pci-p5ioc2.o pci-ioda.o
diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c 
b/arch/powerpc/platforms/powernv/opal-irqchip.c
new file mode 100644
index 000..4b6f951
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -0,0 +1,248 @@
+/*
+ * This file implements an irqchip for OPAL events. Whenever there is
+ * an interrupt that is handled by OPAL we get passed a list of events
+ * that Linux needs to do something about. These basically look like
+ * interrupts to Linux so we implement an irqchip to handle them.
+ *
+ * Copyright Alistair Popple, IBM Corporation 2014.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "powernv.h"
+
+/* Maximum number of events supported by OPAL firmware */
+#define MAX_NUM_EVENTS 64
+
+struct opal_event_irqchip {
+   struct irq_chip irqchip;
+   struct irq_domain *domain;
+   unsigned long mask;
+};
+static struct opal_event_irqchip opal_event_irqchip;
+
+static unsigned int opal_irq_count;
+static unsigned int *opal_irqs;
+
+static void opal_handle_irq_work(struct irq_work *work);
+static __be64 last_outstanding_events;
+static struct irq_work opal_event_irq_work = {
+   .func = opal_handle_irq_work,
+};
+
+static void opal_event_mask(struct irq_data *d)
+{
+   clear_bit(d->hwirq, _event_irqchip.mask);
+}
+
+static void opal_event_unmask(struct irq_data *d)
+{
+   set_bit(d->hwirq, _event_irqchip.mask);
+
+   opal_poll_events(_outstanding_events);
+   if (last_outstanding_events & opal_event_irqchip.mask)
+   /* Need to retrigger the interrupt */
+   irq_work_queue(_event_irq_work);
+}
+
+static int opal_event_set_type(struct irq_data *d, unsigned int flow_type)
+{
+   /*
+* For now we only support level triggered events. The irq
+* handler will be called continuously until the event has
+* been cleared in OPAL.
+*/
+   if (flow_type != IRQ_TYPE_LEVEL_HIGH)
+   return

[PATCH v3 2/8] ipmi/powernv: Convert to irq event interface

2015-05-06 Thread Alistair Popple

Convert the opal ipmi driver to use the new irq interface for events.

Signed-off-by: Alistair Popple 
Cc: Corey Minyard 
Cc: openipmi-develo...@lists.sourceforge.net
---

Corey,

If this looks ok can you please ack it? Michael Ellerman will then take
the whole series via the powerpc tree. Thanks.

 drivers/char/ipmi/ipmi_powernv.c | 39 ++-
 1 file changed, 22 insertions(+), 17 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_powernv.c b/drivers/char/ipmi/ipmi_powernv.c
index 8753b0f..9b409c0 100644
--- a/drivers/char/ipmi/ipmi_powernv.c
+++ b/drivers/char/ipmi/ipmi_powernv.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 

@@ -23,8 +25,7 @@ struct ipmi_smi_powernv {
u64 interface_id;
struct ipmi_device_id   ipmi_id;
ipmi_smi_t  intf;
-   u64 event;
-   struct notifier_block   event_nb;
+   unsigned intirq;

/**
 * We assume that there can only be one outstanding request, so
@@ -197,15 +198,12 @@ static struct ipmi_smi_handlers ipmi_powernv_smi_handlers 
= {
.poll   = ipmi_powernv_poll,
 };

-static int ipmi_opal_event(struct notifier_block *nb,
- unsigned long events, void *change)
+static irqreturn_t ipmi_opal_event(int irq, void *data)
 {
-   struct ipmi_smi_powernv *smi = container_of(nb,
-   struct ipmi_smi_powernv, event_nb);
+   struct ipmi_smi_powernv *smi = data;

-   if (events & smi->event)
-   ipmi_powernv_recv(smi);
-   return 0;
+   ipmi_powernv_recv(smi);
+   return IRQ_HANDLED;
 }

 static int ipmi_powernv_probe(struct platform_device *pdev)
@@ -240,13 +238,16 @@ static int ipmi_powernv_probe(struct platform_device 
*pdev)
goto err_free;
}

-   ipmi->event = 1ull << prop;
-   ipmi->event_nb.notifier_call = ipmi_opal_event;
+   ipmi->irq = irq_of_parse_and_map(dev->of_node, 0);
+   if (!ipmi->irq) {
+   dev_info(dev, "Unable to map irq from device tree\n");
+   ipmi->irq = opal_event_request(prop);
+   }

-   rc = opal_notifier_register(>event_nb);
-   if (rc) {
-   dev_warn(dev, "OPAL notifier registration failed (%d)\n", rc);
-   goto err_free;
+   if (request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
+   "opal-ipmi", ipmi)) {
+   dev_warn(dev, "Unable to request irq\n");
+   goto err_dispose;
}

ipmi->opal_msg = devm_kmalloc(dev,
@@ -271,7 +272,9 @@ static int ipmi_powernv_probe(struct platform_device *pdev)
 err_free_msg:
devm_kfree(dev, ipmi->opal_msg);
 err_unregister:
-   opal_notifier_unregister(>event_nb);
+   free_irq(ipmi->irq, ipmi);
+err_dispose:
+   irq_dispose_mapping(ipmi->irq);
 err_free:
devm_kfree(dev, ipmi);
return rc;
@@ -282,7 +285,9 @@ static int ipmi_powernv_remove(struct platform_device *pdev)
struct ipmi_smi_powernv *smi = dev_get_drvdata(>dev);

ipmi_unregister_smi(smi->intf);
-   opal_notifier_unregister(>event_nb);
+   free_irq(smi->irq, smi);
+   irq_dispose_mapping(smi->irq);
+
return 0;
 }

--
1.8.3.2

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

[PATCH v3 7/8] powernv/opal-dump: Convert to irq domain

2015-05-06 Thread Alistair Popple

Convert the opal dump driver to the new opal irq domain.

Signed-off-by: Alistair Popple 
---
 arch/powerpc/platforms/powernv/opal-dump.c | 56 +-
 1 file changed, 17 insertions(+), 39 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal-dump.c 
b/arch/powerpc/platforms/powernv/opal-dump.c
index 5aa9c1c..2ee9643 100644
--- a/arch/powerpc/platforms/powernv/opal-dump.c
+++ b/arch/powerpc/platforms/powernv/opal-dump.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -60,7 +61,7 @@ static ssize_t dump_type_show(struct dump_obj *dump_obj,
  struct dump_attribute *attr,
  char *buf)
 {
-   
+
return sprintf(buf, "0x%x %s\n", dump_obj->type,
   dump_type_to_string(dump_obj->type));
 }
@@ -363,7 +364,7 @@ static struct dump_obj *create_dump_obj(uint32_t id, size_t 
size,
return dump;
 }
 
-static int process_dump(void)
+static irqreturn_t process_dump(int irq, void *data)
 {
int rc;
uint32_t dump_id, dump_size, dump_type;
@@ -387,45 +388,13 @@ static int process_dump(void)
if (!dump)
return -1;
 
-   return 0;
-}
-
-static void dump_work_fn(struct work_struct *work)
-{
-   process_dump();
+   return IRQ_HANDLED;
 }
 
-static DECLARE_WORK(dump_work, dump_work_fn);
-
-static void schedule_process_dump(void)
-{
-   schedule_work(_work);
-}
-
-/*
- * New dump available notification
- *
- * Once we get notification, we add sysfs entries for it.
- * We only fetch the dump on demand, and create sysfs asynchronously.
- */
-static int dump_event(struct notifier_block *nb,
- unsigned long events, void *change)
-{
-   if (events & OPAL_EVENT_DUMP_AVAIL)
-   schedule_process_dump();
-
-   return 0;
-}
-
-static struct notifier_block dump_nb = {
-   .notifier_call  = dump_event,
-   .next   = NULL,
-   .priority   = 0
-};
-
 void __init opal_platform_dump_init(void)
 {
int rc;
+   int dump_irq;
 
/* ELOG not supported by firmware */
if (!opal_check_token(OPAL_DUMP_READ))
@@ -445,10 +414,19 @@ void __init opal_platform_dump_init(void)
return;
}
 
-   rc = opal_notifier_register(_nb);
+   dump_irq = opal_event_request(ilog2(OPAL_EVENT_DUMP_AVAIL));
+   if (!dump_irq) {
+   pr_err("%s: Can't register OPAL event irq (%d)\n",
+  __func__, dump_irq);
+   return;
+   }
+
+   rc = request_threaded_irq(dump_irq, NULL, process_dump,
+   IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+   "opal-dump", NULL);
if (rc) {
-   pr_warn("%s: Can't register OPAL event notifier (%d)\n",
-   __func__, rc);
+   pr_err("%s: Can't request OPAL event irq (%d)\n",
+  __func__, rc);
return;
}
 
-- 
1.8.3.2

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

[PATCH v3 4/8] powernv/eeh: Update the EEH code to use the opal irq domain

2015-05-06 Thread Alistair Popple

The eeh code currently uses the old notifier method to get eeh events
from OPAL. It also contains some logic to filter opal events which has
been moved into the virtual irqchip. This patch converts the eeh code
to the new event interface which simplifies event handling.

Signed-off-by: Alistair Popple 
---
 arch/powerpc/platforms/powernv/eeh-powernv.c | 58 +++-
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index ce738ab..ca825ec 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,7 @@
 #include "pci.h"
 
 static bool pnv_eeh_nb_init = false;
+static int eeh_event_irq = -EINVAL;
 
 /**
  * pnv_eeh_init - EEH platform dependent initialization
@@ -88,34 +90,22 @@ static int pnv_eeh_init(void)
return 0;
 }
 
-static int pnv_eeh_event(struct notifier_block *nb,
-unsigned long events, void *change)
+static irqreturn_t pnv_eeh_event(int irq, void *data)
 {
-   uint64_t changed_evts = (uint64_t)change;
-
/*
-* We simply send special EEH event if EEH has
-* been enabled, or clear pending events in
-* case that we enable EEH soon
+* We simply send a special EEH event if EEH has been
+* enabled. We don't care about EEH events until we've
+* finished processing the outstanding ones. Event processing
+* gets unmasked in next_error() if EEH is enabled.
 */
-   if (!(changed_evts & OPAL_EVENT_PCI_ERROR) ||
-   !(events & OPAL_EVENT_PCI_ERROR))
-   return 0;
+   disable_irq_nosync(irq);
 
if (eeh_enabled())
eeh_send_failure_event(NULL);
-   else
-   opal_notifier_update_evt(OPAL_EVENT_PCI_ERROR, 0x0ul);
 
-   return 0;
+   return IRQ_HANDLED;
 }
 
-static struct notifier_block pnv_eeh_nb = {
-   .notifier_call  = pnv_eeh_event,
-   .next   = NULL,
-   .priority   = 0
-};
-
 #ifdef CONFIG_DEBUG_FS
 static ssize_t pnv_eeh_ei_write(struct file *filp,
const char __user *user_buf,
@@ -237,16 +227,28 @@ static int pnv_eeh_post_init(void)
 
/* Register OPAL event notifier */
if (!pnv_eeh_nb_init) {
-   ret = opal_notifier_register(_eeh_nb);
-   if (ret) {
-   pr_warn("%s: Can't register OPAL event notifier (%d)\n",
-   __func__, ret);
+   eeh_event_irq = opal_event_request(ilog2(OPAL_EVENT_PCI_ERROR));
+   if (eeh_event_irq < 0) {
+   pr_err("%s: Can't register OPAL event interrupt (%d)\n",
+  __func__, eeh_event_irq);
+   return eeh_event_irq;
+   }
+
+   ret = request_irq(eeh_event_irq, pnv_eeh_event,
+   IRQ_TYPE_LEVEL_HIGH, "opal-eeh", NULL);
+   if (ret < 0) {
+   irq_dispose_mapping(eeh_event_irq);
+   pr_err("%s: Can't request OPAL event interrupt (%d)\n",
+  __func__, eeh_event_irq);
return ret;
}
 
pnv_eeh_nb_init = true;
}
 
+   if (!eeh_enabled())
+   disable_irq(eeh_event_irq);
+
list_for_each_entry(hose, _list, list_node) {
phb = hose->private_data;
 
@@ -1303,12 +1305,10 @@ static int pnv_eeh_next_error(struct eeh_pe **pe)
int state, ret = EEH_NEXT_ERR_NONE;
 
/*
-* While running here, it's safe to purge the event queue.
-* And we should keep the cached OPAL notifier event sychronized
-* between the kernel and firmware.
+* While running here, it's safe to purge the event queue. The
+* event should still be masked.
 */
eeh_remove_event(NULL, false);
-   opal_notifier_update_evt(OPAL_EVENT_PCI_ERROR, 0x0ul);
 
list_for_each_entry(hose, _list, list_node) {
/*
@@ -1477,6 +1477,10 @@ static int pnv_eeh_next_error(struct eeh_pe **pe)
break;
}
 
+   /* Unmask the event */
+   if (eeh_enabled())
+   enable_irq(eeh_event_irq);
+
return ret;
 }
 
-- 
1.8.3.2

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

[PATCH v3 5/8] powernv/opal: Convert opal message events to opal irq domain

2015-05-06 Thread Alistair Popple

This patch converts the opal message event to use the new opal irq
domain.

Signed-off-by: Alistair Popple 
---
 arch/powerpc/platforms/powernv/opal.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 4399ff2..0196220 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -362,33 +362,34 @@ static void opal_handle_message(void)
opal_message_do_notify(type, (void *));
 }
 
-static int opal_message_notify(struct notifier_block *nb,
- unsigned long events, void *change)
+static irqreturn_t opal_message_notify(int irq, void *data)
 {
-   if (events & OPAL_EVENT_MSG_PENDING)
-   opal_handle_message();
-   return 0;
+   opal_handle_message();
+   return IRQ_HANDLED;
 }
 
-static struct notifier_block opal_message_nb = {
-   .notifier_call  = opal_message_notify,
-   .next   = NULL,
-   .priority   = 0,
-};
-
 static int __init opal_message_init(void)
 {
-   int ret, i;
+   int ret, i, irq;
 
for (i = 0; i < OPAL_MSG_TYPE_MAX; i++)
ATOMIC_INIT_NOTIFIER_HEAD(_msg_notifier_head[i]);
 
-   ret = opal_notifier_register(_message_nb);
+   irq = opal_event_request(ilog2(OPAL_EVENT_MSG_PENDING));
+   if (!irq) {
+   pr_err("%s: Can't register OPAL event irq (%d)\n",
+  __func__, irq);
+   return irq;
+   }
+
+   ret = request_irq(irq, opal_message_notify,
+   IRQ_TYPE_LEVEL_HIGH, "opal-msg", NULL);
if (ret) {
-   pr_err("%s: Can't register OPAL event notifier (%d)\n",
+   pr_err("%s: Can't request OPAL event irq (%d)\n",
   __func__, ret);
return ret;
}
+
return 0;
 }
 machine_early_initcall(powernv, opal_message_init);
-- 
1.8.3.2

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

[PATCH v3 3/8] hvc: Convert to using interrupts instead of opal events

2015-05-06 Thread Alistair Popple

Convert the opal hvc driver to use the new irqchip to register for
opal events. As older firmware versions may not have device tree
bindings for the interrupt parent we just use a hardcoded hwirq based
on the event number.

Signed-off-by: Alistair Popple 
---
 drivers/tty/hvc/hvc_opal.c | 33 ++---
 1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c
index 543b234..47b54c6 100644
--- a/drivers/tty/hvc/hvc_opal.c
+++ b/drivers/tty/hvc/hvc_opal.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -61,7 +62,6 @@ static struct hvc_opal_priv 
*hvc_opal_privs[MAX_NR_HVC_CONSOLES];
 /* For early boot console */
 static struct hvc_opal_priv hvc_opal_boot_priv;
 static u32 hvc_opal_boot_termno;
-static bool hvc_opal_event_registered;
 
 static const struct hv_ops hvc_opal_raw_ops = {
.get_chars = opal_get_chars,
@@ -162,28 +162,15 @@ static const struct hv_ops hvc_opal_hvsi_ops = {
.tiocmset = hvc_opal_hvsi_tiocmset,
 };
 
-static int hvc_opal_console_event(struct notifier_block *nb,
- unsigned long events, void *change)
-{
-   if (events & OPAL_EVENT_CONSOLE_INPUT)
-   hvc_kick();
-   return 0;
-}
-
-static struct notifier_block hvc_opal_console_nb = {
-   .notifier_call  = hvc_opal_console_event,
-};
-
 static int hvc_opal_probe(struct platform_device *dev)
 {
const struct hv_ops *ops;
struct hvc_struct *hp;
struct hvc_opal_priv *pv;
hv_protocol_t proto;
-   unsigned int termno, boot = 0;
+   unsigned int termno, irq, boot = 0;
const __be32 *reg;
 
-
if (of_device_is_compatible(dev->dev.of_node, "ibm,opal-console-raw")) {
proto = HV_PROTOCOL_RAW;
ops = _opal_raw_ops;
@@ -227,18 +214,18 @@ static int hvc_opal_probe(struct platform_device *dev)
dev->dev.of_node->full_name,
boot ? " (boot console)" : "");
 
-   /* We don't do IRQ ... */
-   hp = hvc_alloc(termno, 0, ops, MAX_VIO_PUT_CHARS);
+   irq = opal_event_request(ilog2(OPAL_EVENT_CONSOLE_INPUT));
+   if (!irq) {
+   pr_err("hvc_opal: Unable to map interrupt for device %s\n",
+   dev->dev.of_node->full_name);
+   return irq;
+   }
+
+   hp = hvc_alloc(termno, irq, ops, MAX_VIO_PUT_CHARS);
if (IS_ERR(hp))
return PTR_ERR(hp);
dev_set_drvdata(>dev, hp);
 
-   /* ...  but we use OPAL event to kick the console */
-   if (!hvc_opal_event_registered) {
-   opal_notifier_register(_opal_console_nb);
-   hvc_opal_event_registered = true;
-   }
-
return 0;
 }
 
-- 
1.8.3.2

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

Re: [PATCH 10/10] drivers/crypto/nx: add hardware 842 crypto comp alg

2015-05-06 Thread Herbert Xu

On Wed, May 06, 2015 at 12:51:06PM -0400, Dan Streetman wrote:
> Add crypto compression alg for 842 hardware compression and decompression.
> 
> This crypto compression alg is named "nx842" to indicate it uses hardware
> to perform the compression and decompression, while the software 842
> compression alg is named "sw842".  However, since before this split there
> was only one 842 compression alg named "842" which only used hardware,
> this is also aliased "842" for backwards compatibility.

This should still be called 842.  You can set the driver name to
nx842 or 842-nx.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC 4/4] PCI: Introduce helpers to manage pci_dev->irq and pci_dev->irq_managed

2015-05-06 Thread Jiang Liu

Introduce three helpers to manage pci_dev->irq and pci_dev->irq_managed,
which helps to improve maintenance.

Signed-off-by: Jiang Liu 
---
 arch/x86/pci/intel_mid_pci.c |4 ++--
 arch/x86/pci/irq.c   |   10 --
 drivers/acpi/pci_irq.c   |   10 --
 include/linux/pci.h  |   17 +
 4 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index fb7a1f96d80c..22aaefb4f1ca 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -211,7 +211,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
struct irq_alloc_info info;
int polarity;
 
-   if (dev->irq_managed && dev->irq > 0)
+   if (pci_has_managed_irq(dev))
return 0;
 
if (intel_mid_identify_cpu() == INTEL_MID_CPU_CHIP_TANGIER)
@@ -234,7 +234,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (dev->irq_managed && dev->irq > 0) {
+   if (pci_has_managed_irq(dev)) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
/*
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index e71b3dbd87b8..a51079a96ded 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1201,7 +1201,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
struct pci_dev *temp_dev;
int irq;
 
-   if (dev->irq_managed && dev->irq > 0)
+   if (pci_has_managed_irq(dev))
return 0;
 
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
@@ -1229,8 +1229,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
}
dev = temp_dev;
if (irq >= 0) {
-   dev->irq_managed = 1;
-   dev->irq = irq;
+   pci_set_managed_irq(dev, irq);
dev_info(>dev, "PCI->APIC IRQ transform: "
 "INT %c -> IRQ %d\n", 'A' + pin - 1, 
irq);
return 0;
@@ -1258,9 +1257,8 @@ static int pirq_enable_irq(struct pci_dev *dev)
 
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
+   if (io_apic_assign_pci_irqs && pci_has_managed_irq(dev)) {
mp_unmap_irq(dev->irq);
-   dev->irq = 0;
-   dev->irq_managed = 0;
+   pci_reset_managed_irq(dev);
}
 }
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index e7f718d6918a..9d6343d02f7e 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -413,7 +413,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
 
-   if (dev->irq_managed && dev->irq > 0)
+   if (pci_has_managed_irq(dev))
return 0;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -458,8 +458,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
kfree(entry);
return rc;
}
-   dev->irq = rc;
-   dev->irq_managed = 1;
+   pci_set_managed_irq(dev, rc);
 
if (link)
snprintf(link_desc, sizeof(link_desc), " -> Link[%s]", link);
@@ -482,7 +481,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
u8 pin;
 
pin = dev->pin;
-   if (!pin || !dev->irq_managed || dev->irq <= 0)
+   if (!pin || !pci_has_managed_irq(dev))
return;
 
entry = acpi_pci_irq_lookup(dev, pin);
@@ -504,7 +503,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
dev_dbg(>dev, "PCI INT %c disabled\n", pin_name(pin));
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
-   dev->irq_managed = 0;
-   dev->irq = 0;
+   pci_reset_managed_irq(dev);
}
 }
diff --git a/include/linux/pci.h b/include/linux/pci.h
index f50d16a04abc..4bc640eef76f 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -958,6 +958,23 @@ static inline int pci_is_managed(struct pci_dev *pdev)
return pdev->is_managed;
 }
 
+static inline void pci_set_managed_irq(struct pci_dev *pdev, unsigned int irq)
+{
+   pdev->irq = irq;
+   pdev->irq_managed = 1;
+}
+
+static inline void pci_reset_managed_irq(struct pci_dev *pdev)
+{
+   pdev->irq = 0;
+   pdev->irq_managed = 0;
+}
+
+static inline bool pci_has_managed_irq(struct pci_dev *pdev)
+{
+   return pdev->irq_managed && pdev->irq > 0;
+}
+
 void pci_disable_device(struct pci_dev *dev);
 
 extern unsigned int pcibios_max_latency;
-- 
1.7.10.4

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

[RFC 1/4] PCI: Add hooks to allocate/free IRQ resources when binding/unbinding driver

2015-05-06 Thread Jiang Liu

Add two hook points pcibios_{alloc|free}_irq() into PCI core, which will
be called when binding/unbinding PCI device drivers. Then PCI arch code
may hook into these two points to allocate IRQ resources on demand and
free them when not used anymore.

Signed-off-by: Jiang Liu 
---
 drivers/pci/pci-driver.c |   33 +++--
 include/linux/pci.h  |2 ++
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 3cb2210de553..8af4a671686f 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -388,18 +388,30 @@ static int __pci_device_probe(struct pci_driver *drv, 
struct pci_dev *pci_dev)
return error;
 }
 
-static int pci_device_probe(struct device *dev)
+int __weak pcibios_alloc_irq(struct pci_dev *dev)
 {
-   int error = 0;
-   struct pci_driver *drv;
-   struct pci_dev *pci_dev;
+   return dev->irq;
+}
 
-   drv = to_pci_driver(dev->driver);
-   pci_dev = to_pci_dev(dev);
-   pci_dev_get(pci_dev);
-   error = __pci_device_probe(drv, pci_dev);
-   if (error)
-   pci_dev_put(pci_dev);
+void __weak pcibios_free_irq(struct pci_dev *dev)
+{
+}
+
+static int pci_device_probe(struct device *dev)
+{
+   int error;
+   struct pci_dev *pci_dev = to_pci_dev(dev);
+   struct pci_driver *drv = to_pci_driver(dev->driver);
+
+   error = pcibios_alloc_irq(pci_dev);
+   if (error >= 0) {
+   pci_dev_get(pci_dev);
+   error = __pci_device_probe(drv, pci_dev);
+   if (error) {
+   pcibios_free_irq(pci_dev);
+   pci_dev_put(pci_dev);
+   }
+   }
 
return error;
 }
@@ -415,6 +427,7 @@ static int pci_device_remove(struct device *dev)
drv->remove(pci_dev);
pm_runtime_put_noidle(dev);
}
+   pcibios_free_irq(pci_dev);
pci_dev->driver = NULL;
}
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8dc4c6e..f50d16a04abc 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1656,6 +1656,8 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
 int pcibios_add_device(struct pci_dev *dev);
 void pcibios_release_device(struct pci_dev *dev);
 void pcibios_penalize_isa_irq(int irq, int active);
+int pcibios_alloc_irq(struct pci_dev *dev);
+void pcibios_free_irq(struct pci_dev *dev);
 
 #ifdef CONFIG_HIBERNATE_CALLBACKS
 extern struct dev_pm_ops pcibios_pm_ops;
-- 
1.7.10.4

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

[RFC 3/4] PCI, x86: Allocate PCI IRQ on demand and free it when not used anymore

2015-05-06 Thread Jiang Liu

To support IOAPIC hotplug, we need to correctly manage IOAPIC pin usage,
which is to allocate IRQs on demand and free them when not used anymore.
So use pcibios_alloc_irq() and pcibios_free_irq() to dynamically allocate
and free PCI IRQs.

Also remove obseleted code mp_should_keep_irq().

Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/pci_x86.h |2 --
 arch/x86/pci/common.c  |   20 +---
 arch/x86/pci/intel_mid_pci.c   |7 +--
 arch/x86/pci/irq.c |   15 +--
 drivers/acpi/pci_irq.c |9 +
 5 files changed, 16 insertions(+), 37 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 164e3f8d3c3d..fa1195dae425 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -93,8 +93,6 @@ extern raw_spinlock_t pci_config_lock;
 extern int (*pcibios_enable_irq)(struct pci_dev *dev);
 extern void (*pcibios_disable_irq)(struct pci_dev *dev);
 
-extern bool mp_should_keep_irq(struct device *dev);
-
 struct pci_raw_ops {
int (*read)(unsigned int domain, unsigned int bus, unsigned int devfn,
int reg, int len, u32 *val);
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 8fd6f44aee83..dc78a4a9a466 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -673,24 +673,22 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
 }
 
-int pcibios_enable_device(struct pci_dev *dev, int mask)
+int pcibios_alloc_irq(struct pci_dev *dev)
 {
-   int err;
-
-   if ((err = pci_enable_resources(dev, mask)) < 0)
-   return err;
-
-   if (!pci_dev_msi_enabled(dev))
-   return pcibios_enable_irq(dev);
-   return 0;
+   return pcibios_enable_irq(dev);
 }
 
-void pcibios_disable_device (struct pci_dev *dev)
+void pcibios_free_irq(struct pci_dev *dev)
 {
-   if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
+   if (pcibios_disable_irq)
pcibios_disable_irq(dev);
 }
 
+int pcibios_enable_device(struct pci_dev *dev, int mask)
+{
+   return pci_enable_resources(dev, mask);
+}
+
 int pci_ext_cfg_avail(void)
 {
if (raw_pci_ext_ops)
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 27062303c881..fb7a1f96d80c 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -234,10 +234,13 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (!mp_should_keep_irq(>dev) && dev->irq_managed &&
-   dev->irq > 0) {
+   if (dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq_managed = 0;
+   /*
+* Don't reset dev->irq here, otherwise
+* intel_mid_pci_irq_enable() will fail on next call.
+*/
}
 }
 
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 5dc6ca5e1741..e71b3dbd87b8 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1256,22 +1256,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
return 0;
 }
 
-bool mp_should_keep_irq(struct device *dev)
-{
-   if (dev->power.is_prepared)
-   return true;
-#ifdef CONFIG_PM
-   if (dev->power.runtime_status == RPM_SUSPENDING)
-   return true;
-#endif
-
-   return false;
-}
-
 static void pirq_disable_irq(struct pci_dev *dev)
 {
-   if (io_apic_assign_pci_irqs && !mp_should_keep_irq(>dev) &&
-   dev->irq_managed && dev->irq) {
+   if (io_apic_assign_pci_irqs && dev->irq_managed && dev->irq) {
mp_unmap_irq(dev->irq);
dev->irq = 0;
dev->irq_managed = 0;
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index b1def411c0b8..e7f718d6918a 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -485,14 +485,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
if (!pin || !dev->irq_managed || dev->irq <= 0)
return;
 
-   /* Keep IOAPIC pin configuration when suspending */
-   if (dev->dev.power.is_prepared)
-   return;
-#ifdef CONFIG_PM
-   if (dev->dev.power.runtime_status == RPM_SUSPENDING)
-   return;
-#endif
-
entry = acpi_pci_irq_lookup(dev, pin);
if (!entry)
return;
@@ -513,5 +505,6 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
if (gsi >= 0) {
acpi_unregister_gsi(gsi);
dev->irq_managed = 0;
+   dev->irq = 0;
}
 }
-- 
1.7.10.4

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

[RFC 2/4] PCI, MSI: Optionally free legacy PCI IRQ when enabling MSI/MSI-X

2015-05-06 Thread Jiang Liu

Once PCI MSI/MSI-X is enabled by the device driver, PCI device won't
make use of legacy PCI IRQ until PCI MSI/MSI-X is disabled again.
So optionally free legacy PCI IRQ when enabling MSI/MSI-X and reallocate
when disabling MSI/MSI-X.

Signed-off-by: Jiang Liu 
---
 drivers/pci/msi.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index c3e7dfcf9ff5..47cf72c669f0 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -686,6 +686,7 @@ static int msi_capability_init(struct pci_dev *dev, int 
nvec)
msi_set_enable(dev, 1);
dev->msi_enabled = 1;
 
+   pcibios_free_irq(dev);
dev->irq = entry->irq;
return 0;
 }
@@ -813,9 +814,10 @@ static int msix_capability_init(struct pci_dev *dev,
/* Set MSI-X enabled bits and unmask the function */
pci_intx_for_msi(dev, 0);
dev->msix_enabled = 1;
-
msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);
 
+   pcibios_free_irq(dev);
+
return 0;
 
 out_avail:
@@ -930,6 +932,7 @@ void pci_msi_shutdown(struct pci_dev *dev)
 
/* Restore dev->irq to its default pin-assertion irq */
dev->irq = desc->msi_attrib.default_irq;
+   pcibios_alloc_irq(dev);
 }
 
 void pci_disable_msi(struct pci_dev *dev)
@@ -1030,6 +1033,7 @@ void pci_msix_shutdown(struct pci_dev *dev)
msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
pci_intx_for_msi(dev, 1);
dev->msix_enabled = 0;
+   pcibios_alloc_irq(dev);
 }
 
 void pci_disable_msix(struct pci_dev *dev)
-- 
1.7.10.4

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

[RFC 0/4] Introduce a mechanism to allocate PCI IRQ on demand

2015-05-06 Thread Jiang Liu

This patch set introduces a mechanism to allocate PCI IRQ on demand and
free it when not used anymore by hooking pci_device_probe() and
pci_device_remove().

It will be used to track IOAPIC pin usage on x86 so we could support
IOAPIC hot-removal.

The patch set passes Fengguang's 0day test suite and is available at:
https://github.com/jiangliu/linux.git pci_irq_v1

Thanks!
Gerry

Jiang Liu (4):
  PCI: Add hooks to allocate/free IRQ resources when binding/unbinding
driver
  PCI, MSI: Optionally free legacy PCI IRQ when enabling MSI/MSI-X
  PCI, x86: Allocate PCI IRQ on demand and free it when not used
anymore
  PCI: Introduce helpers to manage pci_dev->irq and
pci_dev->irq_managed

 arch/x86/include/asm/pci_x86.h |2 --
 arch/x86/pci/common.c  |   20 +---
 arch/x86/pci/intel_mid_pci.c   |9 ++---
 arch/x86/pci/irq.c |   23 ---
 drivers/acpi/pci_irq.c |   17 -
 drivers/pci/msi.c  |6 +-
 drivers/pci/pci-driver.c   |   33 +++--
 include/linux/pci.h|   19 +++
 8 files changed, 70 insertions(+), 59 deletions(-)

-- 
1.7.10.4

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

Re: [PATCH] staging: rtl8192u: ieee80211: Silence sparse warning

2015-05-06 Thread Gaston Gonzalez

On 27/04/15 07:12, Dan Carpenter wrote:
> Can't we just export the tkip.c function?
>
> regards,
> dan carpenter
>
Hi Dan,

(sorry for the delayed response)

The inputs of the two implementations of tkip_mixing_phase2() differ in
one parameter:

 - ieee80211_crypt_tkip.c expects 'const u16 *TTAK'
 - tkip.c expects 'struct tkip_ctx *ctx'

tkip_mixing_phase2() is called two times in ieee80211_crypt_tkip.c:

git grep tkip_mixing_phase2  drivers/staging/rtl8192u/ieee80211/

drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c:static void
tkip_mixing_phase2(u8 *WEPSeed, const u8 *TK, const u16 *TTAK,

drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c: 
tkip_mixing_phase2(rc4key, tkey->key, tkey->tx_ttak, tkey->tx_iv16);

drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c: 
tkip_mixing_phase2(rc4key, tkey->key, tkey->rx_ttak, iv16);

tkey is a 'struct ieee80211_tkip_data', which differs from tkip_ctx
structure. So in the case of exporting the tkip.c function, we would
need to add 'struct tkip_ctx' definition, and not just change the
function input definition.

The only member of tkip_ctx structure used in tkip_mixing_phase2() is
p1k, which is the equivalent of TTAK array in ieee80211_crypt_tkip.c .
Thus - I'm new to this so I may be missing something - one way would be
to just add the tkip_ctx structure definition in ieee80211_crypt_tkip.c.
The down side of doing this is that there would be some parameters
defined twice in two different structures: u32 iv32, u16 iv16, u16
p1k[5], u32 p1k_iv32

Another way would be split ieee80211_tkip_data structure in struct
tkip_ctx on one side, and leave the rest of the members on the original
structure. This would avoid to duplicate the members definitions, but I
guess that approach could broke other things...

As I said, I'm new to this so I may be missing something, maybe a
different approach?

One detail: although not used in the function, 'enum
ieee80211_internal_tkip_state state' is not defined in 'struct
ieee80211_tkip_data', thus in any case that definition would have to be
added.

regards,

Gaston

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

Re: [PATCH] qxl: rewrite framebuffer support

2015-05-06 Thread Dave Airlie

On 5 May 2015 at 21:52, Gerd Hoffmann  wrote:
> Completely different approach:  Instead of encoding each and every
> framebuffer update as spice operation simply update the shadow
> framebuffer and maintain a dirty rectangle.  Also schedule a worker
> to push an update for the dirty rectangle as spice operation.  Usually
> a bunch of dirty rectangle updates are collected before the worker
> actually runs.
>
> What changes:  Updates get batched now.  Instead of sending tons of
> small updates a few large ones are sent.  When the same region is
> updated multiple times within a short timeframe (scrolling multiple
> lines for example) we send a single update only.  Spice server has an
> easier job now:  The dependency tree for display operations which spice
> server maintains for lazy rendering is alot smaller now.  Spice server's
> image compression probably works better too with the larger image blits.
>
> Net effect:  framebuffer console @ qxldrmfb is an order of magnitude
> faster now.
>
> Signed-off-by: Gerd Hoffmann 

Looks good, I often wondered if we should have done this, spice
protocol overhead
seemed quite high.

I'll merge this into drm-next.

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

Re: [PATCH 04/10] crypto: change 842 alg to use software

2015-05-06 Thread Herbert Xu

On Wed, May 06, 2015 at 12:51:00PM -0400, Dan Streetman wrote:
> Change the crypto 842 compression alg to use the software 842 compression
> and decompression library.  Change the name of this crypto alg to "sw842".
> Remove the fallback to LZO compression.

That's not how the name works.  All implementations of 842 should
bear that name.  They should differentiate themselves based on
cra_driver_name.  For example, we generally call the software
implementation of foo "foo-generic".

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/7] crypto: add new driver for Marvell CESA

2015-05-06 Thread Herbert Xu

On Mon, May 04, 2015 at 02:27:01PM +0200, Boris Brezillon wrote:
> The existing mv_cesa driver supports some features of the CESA IP but is
> quite limited, and reworking it to support new features (like involving the
> TDMA engine to offload the CPU) is almost impossible.
> This driver has been rewritten from scratch to take those new features into
> account.
> 
> This new driver adds support for:
> - new armada SoCs (up to 38x) while keeping support for older ones (Orion
>   and Kirkwood)
> - DMA mode to offload the CPU in case of intensive crypto usage
> - new algorithms: SHA256, DES and 3DES
> 
> The existing CESA driver is kept around to ease transition to this new
> driver (take some time to audit the code and/or wait for users feedback).
> 
> Signed-off-by: Boris Brezillon 
> Signed-off-by: Arnaud Ebalard 

This patch is too big for the mailing list.  Please provide a
URL for people to download and review.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [1/2] RTC: Add core rtc support for Gemini Soc devices

2015-05-06 Thread Hans Ulli Kroll

Hello

On Wed, 6 May 2015, Arnd Bergmann wrote:

> On Saturday 02 May 2015 01:42:14 Alexandre Belloni wrote:
> > Hi,
> > 
> > On 14/12/2010 at 16:08:26 +0100, Hans Ulli Kroll wrote :
> > > driver for the rtc device
> > > on Cortina Systems CS3516 or StormlinkSemi SL3516 aka Gemini SoC
> > > 
> > > Signed-off-by: Hans Ulli Kroll 
> > 
> > This driver has never been merged and the platform doesn't seem to be
> > active anymore. Is there still any interest in getting this driver
> > mainlined?
> > 
> > Only tree wide cleanups happened in mach-gemini since end of 2010, the
> > listed git repository (git://git.berlios.de/gemini-board) was on berliOS
> > (closed since 2011) and the sourceforge mirror seems empty. Is there
> > still interest in keeping that platform in the mainline?
> 
> As far as I know, the platform is still used by a number of people,
> and is supported by OpenWRT. The reason we haven't seen updates is that
> Ulli has been mostly absent from upstream development, and we haven't
> had any other person step up as maintainer.
> 
> I have a patch to convert the platform to ARCH_MULTIPLATFORM, and
> the code doesn't really get in the way otherwise.
> 
> As far as I'm concerned, we should just merge all the patches from
> http://git.openwrt.org/?p=openwrt.git;a=tree;f=target/linux/gemini/patches-3.18
y> 
> We should also try to find a maintainer that can respond to patches
> in a timely manner. If Ulli has time for that again, that would be great,
> otherwise I think we should find someone from OpenWRT to take over.
> 
>   Arnd
> 

I'm back in busyness.
Currently me dev device is right next to me.
I moved some time ago and haav to find it in some 'hidden' box.


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

RE: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC

2015-05-06 Thread yangbo...@freescale.com

Thanks.
Pls see my comments below.

-Original Message-
From: Wood Scott-B07421 
Sent: Thursday, May 07, 2015 4:44 AM
To: Lu Yangbo-B47093
Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC

On Wed, 2015-05-06 at 17:40 +0800, Yangbo Lu wrote:
> Add 1588 timer node in files:
> arch/powerpc/boot/dts/bsc9131rdb.dtsi
> arch/powerpc/boot/dts/bsc9132qds.dtsi
> arch/powerpc/boot/dts/p1010rdb.dtsi
> arch/powerpc/boot/dts/p1020rdb-pd.dts
> arch/powerpc/boot/dts/p1021rdb-pc.dtsi
> arch/powerpc/boot/dts/p1022ds.dtsi
> arch/powerpc/boot/dts/p1025twr.dtsi
> arch/powerpc/boot/dts/p2020rdb-pc.dtsi
> 
> Signed-off-by: Yangbo Lu 
> ---
>  arch/powerpc/boot/dts/bsc9131rdb.dtsi  | 12   
> arch/powerpc/boot/dts/bsc9132qds.dtsi  | 12 
>  arch/powerpc/boot/dts/p1010rdb.dtsi| 12 
>  arch/powerpc/boot/dts/p1020rdb-pd.dts  | 12   
> arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 12 
>  arch/powerpc/boot/dts/p1022ds.dtsi | 12 
>  arch/powerpc/boot/dts/p1025twr.dtsi| 12 
>  arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 15 +--
>  8 files changed, 93 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi 
> b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> index 45efcba..629cc03 100644
> --- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> +++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> @@ -80,6 +80,18 @@
>   status = "disabled";
>   };
>  
> + ptp_clock@b0e00 {
> + compatible = "fsl,etsec-ptp";
> + reg = <0xb0e00 0xb0>;
> + interrupts = <68 2 0 0 69 2 0 0>;
> + fsl,tclk-period = <5>;
> + fsl,tmr-prsc= <2>;
> + fsl,tmr-add = <0xcccd>;
> + fsl,tmr-fiper1  = <0x3b9ac9fb>;
> + fsl,tmr-fiper2  = <0x00018696>;
> + fsl,max-adj = <24999>;

Please don't use hex for numbers that make more sense as decimal.
[Lu Yangbo-B47093] The hex value is register value, I think it's better to use 
hex.

> --- a/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
> +++ b/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
> @@ -215,12 +215,15 @@
>   };
>  
>   ptp_clock@24e00 {
> - fsl,tclk-period = <5>;
> - fsl,tmr-prsc = <200>;
> - fsl,tmr-add = <0xCCCD>;
> - fsl,tmr-fiper1 = <0x3B9AC9FB>;
> - fsl,tmr-fiper2 = <0x0001869B>;
> - fsl,max-adj = <24999>;
> + compatible = "fsl,etsec-ptp";
> + reg = <0x24e00 0xb0>;
> + interrupts = <68 2 0 0 69 2 0 0>;
> + fsl,tclk-period = <5>;
> + fsl,tmr-prsc= <2>;
> + fsl,tmr-add = <0xaaab>;
> + fsl,tmr-fiper1  = <0x3b9ac9fb>;
> + fsl,tmr-fiper2  = <0x00018696>;
> + fsl,max-adj = <2>;
>   };

This isn't adding a node -- it's changing values.  If the old ones were wrong, 
explain that in the changelog.

Also, p2020si-post.dtsi already adds interrupts to this node (and it contains 
one more interrupt than the above), and it includes pq3-etsec1-timer-0.dtsi 
which contains the compatible and reg (and interrupts with two specifiers).  
Probably all of these should be using pq3-etsec1-timer-0.dtsi and only 
specifying the board-specific values.

[Lu Yangbo-B47093] I will modify according your comments here.

-Scott

RE: [BUG] ThinkPad T520 overheating with P-State driver

2015-05-06 Thread Doug Smythies

On 2015.05.06 13:37 Martin Steigerwald wrote:

> I get frequencies like:
>
> 3080566
> 3068945
> 3009082
> 202 

Please know that the intel_pstate driver reports actual CPU frequencies
over the last sample interval. In terms of heat, they don't mean anything,
you would have to look at how much time the CPU spent in the C0 and other 
states.

> Yet with acpi-cpufreq without limiting maximum performance at all, I get the 
> following with the *same* workload:

> 2501000
> 2501000
> 100
> 100

Please know that the acpi-cpufreq driver reports what frequency (pstate)
It is asking for, not what might actually be happening.
If your CPU 2 and 3 were ever active during that sample time
They would be at the same frequency as your turbostate CPU 0 or 1,
which ever is higher.

> There is also some other bug report about this:
> Please change intel_pstate default to disable 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1188647
> appears to be quite old, but still seems unresolved.

That bug report is very old, and is closed.
I made a late entry on that bug report on 2014.06.08,
and have submitted a patch set to deal with, among other things,
the long duration issue. 

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

Re: tools: Consolidate types.h

2015-05-06 Thread Andy Lutomirski

On Wed, May 6, 2015 at 10:37 AM, Borislav Petkov  wrote:
> On Wed, May 06, 2015 at 07:30:35PM +0200, Oleg Nesterov wrote:
>> On 05/06, Borislav Petkov wrote:
>> >
>> > On Wed, May 06, 2015 at 06:54:00PM +0200, Oleg Nesterov wrote:
>> > > Hi,
>> > >
>> > > I can't build the kernel after "git pull",
>> >
>> > You mean, you can't build perf tool...?
>>
>> No, make bzImage fails, it can't compile arch/x86/vdso/vdso2c
>
> Wow, so this commit is a year old and this is the first time I see a it
> causing a failure. You must have a really ooold distro :-)
>
>> > > diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
>> > > index 275a3a8..e970320 100644
>> > > --- a/arch/x86/vdso/Makefile
>> > > +++ b/arch/x86/vdso/Makefile
>> > > @@ -51,7 +51,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 
>> > > -Wl,-soname=linux-vdso.so.1 \
>> > >  $(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
>> > >   $(call if_changed,vdso)
>> > >
>> > > -HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi
>> > > +HOST_EXTRACFLAGS += -I$(srctree)/tools/include 
>> > > -I$(srctree)/include/uapi -I$(srctree)/arch/x86/include/uapi
>> >
>> > Do you have kernel-headers installed on your distro?
>>
>> I have no idea ;) but I guess they were installed. many years ago.
>>
>> > That's
>> > basically those uapi headers packaged separately. There's also "make
>> > headers_install" which should probably do that (haven't tried it
>> > though).
>>
>> Perhaps. but still, if HOST_EXTRACFLAGS has -I$(srctree)/include/uapi, why
>> it doesn't add arch/x86/include/uapi? This doesn't look consistent in any
>> case.
>
> Yeah, I guess it wouldn't hurt. Andy, see quoted hunk above ^^.

I'd be fine with adding the extra -I.  Want to send a pach?  I'll get
to it eventually if you don't beat me to it.

--Andy

>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --



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

Re: [PATCH RFC 0/3] simple copy offloading system call

2015-05-06 Thread Andy Lutomirski

On May 6, 2015 11:45 AM, "Michael Kerrisk"  wrote:
>
> [CC += linux-...@vger.kernel.org]
>
> Zach,
>
> Since this is a kernel-user-space API change, please CC linux-api@.
> The kernel source file Documentation/SubmitChecklist notes that all
> Linux kernel patches that change userspace interfaces should be CCed
> to linux-...@vger.kernel.org, so that the various parties who are
> interested in API changes are informed. For further information, see
> https://www.kernel.org/doc/man-pages/linux-api-ml.html
>
> Thanks,
>
> Michael
>
>
>
>
> On Sat, Apr 11, 2015 at 12:00 AM, Zach Brown  wrote:
> > Hello everyone!
> >
> > Here's my current attempt at the most basic system call interface for
> > offloading copying between files.  The system call and vfs function
> > are relatively light wrappers around the file_operation method that
> > does the heavy lifting.
> >
> > There was interest at LSF in getting the basic infrastructure merged
> > before worrying about adding behavioural flags and more complicated
> > implementations.  This series only offers a refactoring of the btrfs
> > clone ioctl as an example of an implementation of the file
> > copy_file_range method.
> >
> > I've added support for copy_file_range() to xfs_io in xfsprogs and
> > have the start of an xfstest that tests the system call.  I'll send
> > those to fstests@.
> >
> > So how does this look?
> >
> > Do we want to merge this and let the NFS and block XCOPY patches add
> > their changes when they're ready?

This sounds enough like splice that I'm wondering why the API isn't splice.

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

Re: [PATCH 207/208] x86/fpu: Add FPU performance measurement subsystem

2015-05-06 Thread Andy Lutomirski

On May 6, 2015 10:22 AM, "Ingo Molnar"  wrote:
>
>
> * Andy Lutomirski  wrote:
>
> > On May 5, 2015 11:30 PM, "Ingo Molnar"  wrote:
> > >
> > > Add a short FPU performance suite that runs once during bootup.
> > >
> > > It can be enabled via CONFIG_X86_DEBUG_FPU_PERFORMANCE=y.
> >
> > Neat!
> >
> > Can you change "cycles" to "TSC ticks"?  They're not quite the same thing.
>
> Yeah, with constant TSC we have the magic TSC frequency that is used
> by RDTSC.
>
> I'm torn: 'TSC ticks' will mean very little to most people reading
> that output. We could convert it to nsecs with a little bit of
> calibration - but that makes it depend on small differences in CPU
> model frequencies, while the (cached) cycle costs are typically
> constant per microarchitecture.

Isn't it dependent on the ratio of max turbo frequency to TSC freq?
Typical non-ultra-mobile systems should be at or near max turbo
frequency during bootup.

>
> I suspect we could snatch a performance counter temporarily, to get
> the real cycles count, and maybe even add a uops column. Most of this
> needs to run in kernel space, so it's not a tooling project.

This will suck under KVM without extra care.  I know, because I'm
working on a similar userspace tool that uses RDPMC.

Another option would be rdmsr(MSR_IA32_APERF), but that isn't
available under KVM either.

>
> I also wanted to add cache-cold numbers which are very interesting as
> well, just awfully hard to measure in a stable fashion. For cache-cold
> numbers the natural unit would be memory bus cycles.

Yeah, maybe it's worth wiring up perf counters at some point.

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

[Patch v3] x86, irq: Allocate CPU vectors from device local CPUs if possible

2015-05-06 Thread Jiang Liu

On NUMA systems, an IO device may be associated with a NUMA node.
It may improve IO performance to allocate resources, such as memory
and interrupts, from device local node.

This patch introduces a mechanism to support CPU vector allocation
policies. It tries to allocate CPU vectors from CPUs on device local
node first, and then fallback to all online(global) CPUs.

This mechanism may be used to support NumaConnect systems to allocate
CPU vectors from device local node.

Signed-off-by: Jiang Liu 
Cc: Daniel J Blueman 
---
Hi Thomas,
I feel this should be simpliest version now:)
Thanks!
Gerry
---
 arch/x86/kernel/apic/vector.c |   23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 1c7dd42b98c1..eb65c6b98de0 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -210,6 +210,18 @@ static int assign_irq_vector(int irq, struct 
apic_chip_data *data,
return err;
 }
 
+static int assign_irq_vector_policy(int irq, int node,
+   struct apic_chip_data *data,
+   struct irq_alloc_info *info)
+{
+   if (info && info->mask)
+   return assign_irq_vector(irq, data, info->mask);
+   if (node != NUMA_NO_NODE &&
+   assign_irq_vector(irq, data, cpumask_of_node(node)) == 0)
+   return 0;
+   return assign_irq_vector(irq, data, apic->target_cpus());
+}
+
 static void clear_irq_vector(int irq, struct apic_chip_data *data)
 {
int cpu, vector;
@@ -258,12 +270,6 @@ void copy_irq_alloc_info(struct irq_alloc_info *dst, 
struct irq_alloc_info *src)
memset(dst, 0, sizeof(*dst));
 }
 
-static inline const struct cpumask *
-irq_alloc_info_get_mask(struct irq_alloc_info *info)
-{
-   return (!info || !info->mask) ? apic->target_cpus() : info->mask;
-}
-
 static void x86_vector_free_irqs(struct irq_domain *domain,
 unsigned int virq, unsigned int nr_irqs)
 {
@@ -289,7 +295,6 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, 
unsigned int virq,
 {
struct irq_alloc_info *info = arg;
struct apic_chip_data *data;
-   const struct cpumask *mask;
struct irq_data *irq_data;
int i, err;
 
@@ -300,7 +305,6 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, 
unsigned int virq,
if ((info->flags & X86_IRQ_ALLOC_CONTIGUOUS_VECTORS) && nr_irqs > 1)
return -ENOSYS;
 
-   mask = irq_alloc_info_get_mask(info);
for (i = 0; i < nr_irqs; i++) {
irq_data = irq_domain_get_irq_data(domain, virq + i);
BUG_ON(!irq_data);
@@ -318,7 +322,8 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, 
unsigned int virq,
irq_data->chip = _controller;
irq_data->chip_data = data;
irq_data->hwirq = virq + i;
-   err = assign_irq_vector(virq, data, mask);
+   err = assign_irq_vector_policy(virq, irq_data->node, data,
+  info);
if (err)
goto error;
}
-- 
1.7.10.4

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

Re: [PATCH v18 for v4.1-rc2 1/3] sys_membarrier(): system-wide memory barrier (generic, x86)

2015-05-06 Thread Andy Lutomirski

On Wed, May 6, 2015 at 1:39 PM, Linus Torvalds
 wrote:
> On Wed, May 6, 2015 at 1:33 PM, Mathieu Desnoyers
>  wrote:
>>
>> Will try moving those parts under a "---" in the commit
>> message, and hope it does what I intend.
>
> Yeah, that should do it for anybody who then uses "git am" to apply
> the patches you send out. It's kind of hacky, and I've always worried
> a bit that somebody uses "^---$' for real in a commit message and
> things get lost, but it is *such* a useful way to add notes to emails
> that aren't fit for actually committing, that the risk has never
> outweighed the benefits.

There's also 'git format-patch --notes', which is less hacky but more
complicated.

--Andy

>
>   Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

RE: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC

2015-05-06 Thread yangbo...@freescale.com



-Original Message-
From: Wood Scott-B07421 
Sent: Thursday, May 07, 2015 10:35 AM
To: Lu Yangbo-B47093
Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC

On Wed, 2015-05-06 at 21:26 -0500, Lu Yangbo-B47093 wrote:
> Thanks.
> Pls see my comments below.
> 
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, May 07, 2015 4:44 AM
> To: Lu Yangbo-B47093
> Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC
> 
> On Wed, 2015-05-06 at 17:40 +0800, Yangbo Lu wrote:
> > Add 1588 timer node in files:
> > arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > arch/powerpc/boot/dts/bsc9132qds.dtsi
> > arch/powerpc/boot/dts/p1010rdb.dtsi
> > arch/powerpc/boot/dts/p1020rdb-pd.dts
> > arch/powerpc/boot/dts/p1021rdb-pc.dtsi
> > arch/powerpc/boot/dts/p1022ds.dtsi
> > arch/powerpc/boot/dts/p1025twr.dtsi
> > arch/powerpc/boot/dts/p2020rdb-pc.dtsi
> > 
> > Signed-off-by: Yangbo Lu 
> > ---
> >  arch/powerpc/boot/dts/bsc9131rdb.dtsi  | 12  
> > arch/powerpc/boot/dts/bsc9132qds.dtsi  | 12 
> >  arch/powerpc/boot/dts/p1010rdb.dtsi| 12 
> >  arch/powerpc/boot/dts/p1020rdb-pd.dts  | 12  
> > arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 12 
> >  arch/powerpc/boot/dts/p1022ds.dtsi | 12 
> >  arch/powerpc/boot/dts/p1025twr.dtsi| 12 
> >  arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 15 +--
> >  8 files changed, 93 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > index 45efcba..629cc03 100644
> > --- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > +++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > @@ -80,6 +80,18 @@
> > status = "disabled";
> > };
> >  
> > +   ptp_clock@b0e00 {
> > +   compatible = "fsl,etsec-ptp";
> > +   reg = <0xb0e00 0xb0>;
> > +   interrupts = <68 2 0 0 69 2 0 0>;
> > +   fsl,tclk-period = <5>;
> > +   fsl,tmr-prsc= <2>;
> > +   fsl,tmr-add = <0xcccd>;
> > +   fsl,tmr-fiper1  = <0x3b9ac9fb>;
> > +   fsl,tmr-fiper2  = <0x00018696>;
> > +   fsl,max-adj = <24999>;
> 
> Please don't use hex for numbers that make more sense as decimal.
> [Lu Yangbo-B47093] The hex value is register value, I think it's better to 
> use hex.

Whether it goes into a register doesn't matter.  Hex values are useful for 
values which are subdivided into various bitfields, or whose hex representation 
is simpler than decimal.  I'm not familiar with the details of this hardware, 
but I doubt the former is the case for 0x3b9ac9fb == 95 or 0x18696 == 
0.
[Lu Yangbo-B47093] Thanks Scott. I got it. The hex value here is not for 
various bitfields but a value calculated manually. I will modify to decimalism.

-Scott

Re: [PATCH] sysrq : restore console_loglevel back to orig_log_level

2015-05-06 Thread tyeon


if check_mask is true and sysrq_on_maks returns false,
then, the code go through the 'else' statement.
if (!check_mask || sysrq_on_maks(..)) {
...
} else {
pr_cont("This sysrq operation is disabled.\n");
}
...
So, console_loglevel remains CONSOLE_LOGLEVEL_DEFAULT

Signed-off-by: Tom(JeHyeon) Yeon 
---
 drivers/tty/sysrq.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 259a4d5..68d5295 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -537,6 +537,7 @@ void __handle_sysrq(int key, bool check_mask)
op_p->handler(key);
} else {
pr_cont("This sysrq operation is disabled.\n");
+   console_loglevel = orig_log_level;
}
} else {
pr_cont("HELP : ");
--
1.7.9.5

sorry to bother you.

if check_mask is true and sysrq_on_maks returns false,
then, the code go through the 'else' statement.
 if (!check_mask || sysrq_on_maks(..)) {
 ...
 } else {
 pr_cont("This sysrq operation is disabled.\n");
 }
 ...
So, console_loglevel remains CONSOLE_LOGLEVEL_DEFAULT

Signed-off-by: Tom(JeHyeon) Yeon 
---
  drivers/tty/sysrq.c |1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 259a4d5..68d5295 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -537,6 +537,7 @@ void __handle_sysrq(int key, bool check_mask)
  op_p->handler(key);
  } else {
  pr_cont("This sysrq operation is disabled.\n");
+console_loglevel = orig_log_level;
  }
  } else {
  pr_cont("HELP : ");


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

[PATCH V8 2/8] perf, x86: introduce setup_pebs_sample_data()

2015-05-06 Thread Kan Liang

From: Yan, Zheng 

move codes that setup PEBS sample data to separate function.

Signed-off-by: Yan, Zheng 
Signed-off-by: Kan Liang 
---
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 95 +--
 1 file changed, 52 insertions(+), 43 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index f856f73..f26c8b4 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -853,8 +853,10 @@ static inline u64 intel_hsw_transaction(struct 
pebs_record_hsw *pebs)
return txn;
 }
 
-static void __intel_pmu_pebs_event(struct perf_event *event,
-  struct pt_regs *iregs, void *__pebs)
+static void setup_pebs_sample_data(struct perf_event *event,
+  struct pt_regs *iregs, void *__pebs,
+  struct perf_sample_data *data,
+  struct pt_regs *regs)
 {
 #define PERF_X86_EVENT_PEBS_HSW_PREC \
(PERF_X86_EVENT_PEBS_ST_HSW | \
@@ -866,30 +868,25 @@ static void __intel_pmu_pebs_event(struct perf_event 
*event,
 */
struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
struct pebs_record_hsw *pebs = __pebs;
-   struct perf_sample_data data;
-   struct pt_regs regs;
u64 sample_type;
int fll, fst, dsrc;
int fl = event->hw.flags;
 
-   if (!intel_pmu_save_and_restart(event))
-   return;
-
sample_type = event->attr.sample_type;
dsrc = sample_type & PERF_SAMPLE_DATA_SRC;
 
fll = fl & PERF_X86_EVENT_PEBS_LDLAT;
fst = fl & (PERF_X86_EVENT_PEBS_ST | PERF_X86_EVENT_PEBS_HSW_PREC);
 
-   perf_sample_data_init(, 0, event->hw.last_period);
+   perf_sample_data_init(data, 0, event->hw.last_period);
 
-   data.period = event->hw.last_period;
+   data->period = event->hw.last_period;
 
/*
 * Use latency for weight (only avail with PEBS-LL)
 */
if (fll && (sample_type & PERF_SAMPLE_WEIGHT))
-   data.weight = pebs->lat;
+   data->weight = pebs->lat;
 
/*
 * data.data_src encodes the data source
@@ -902,7 +899,7 @@ static void __intel_pmu_pebs_event(struct perf_event *event,
val = precise_datala_hsw(event, pebs->dse);
else if (fst)
val = precise_store_data(pebs->dse);
-   data.data_src.val = val;
+   data->data_src.val = val;
}
 
/*
@@ -915,58 +912,70 @@ static void __intel_pmu_pebs_event(struct perf_event 
*event,
 * PERF_SAMPLE_IP and PERF_SAMPLE_CALLCHAIN to function properly.
 * A possible PERF_SAMPLE_REGS will have to transfer all regs.
 */
-   regs = *iregs;
-   regs.flags = pebs->flags;
-   set_linear_ip(, pebs->ip);
-   regs.bp = pebs->bp;
-   regs.sp = pebs->sp;
+   *regs = *iregs;
+   regs->flags = pebs->flags;
+   set_linear_ip(regs, pebs->ip);
+   regs->bp = pebs->bp;
+   regs->sp = pebs->sp;
 
if (sample_type & PERF_SAMPLE_REGS_INTR) {
-   regs.ax = pebs->ax;
-   regs.bx = pebs->bx;
-   regs.cx = pebs->cx;
-   regs.dx = pebs->dx;
-   regs.si = pebs->si;
-   regs.di = pebs->di;
-   regs.bp = pebs->bp;
-   regs.sp = pebs->sp;
-
-   regs.flags = pebs->flags;
+   regs->ax = pebs->ax;
+   regs->bx = pebs->bx;
+   regs->cx = pebs->cx;
+   regs->dx = pebs->dx;
+   regs->si = pebs->si;
+   regs->di = pebs->di;
+   regs->bp = pebs->bp;
+   regs->sp = pebs->sp;
+
+   regs->flags = pebs->flags;
 #ifndef CONFIG_X86_32
-   regs.r8 = pebs->r8;
-   regs.r9 = pebs->r9;
-   regs.r10 = pebs->r10;
-   regs.r11 = pebs->r11;
-   regs.r12 = pebs->r12;
-   regs.r13 = pebs->r13;
-   regs.r14 = pebs->r14;
-   regs.r15 = pebs->r15;
+   regs->r8 = pebs->r8;
+   regs->r9 = pebs->r9;
+   regs->r10 = pebs->r10;
+   regs->r11 = pebs->r11;
+   regs->r12 = pebs->r12;
+   regs->r13 = pebs->r13;
+   regs->r14 = pebs->r14;
+   regs->r15 = pebs->r15;
 #endif
}
 
if (event->attr.precise_ip > 1 && x86_pmu.intel_cap.pebs_format >= 2) {
-   regs.ip = pebs->real_ip;
-   regs.flags |= PERF_EFLAGS_EXACT;
-   } else if (event->attr.precise_ip > 1 && intel_pmu_pebs_fixup_ip())
-   regs.flags |= PERF_EFLAGS_EXACT;
+   regs->ip = pebs->real_ip;
+   regs->flags |= PERF_EFLAGS_EXACT;
+   } else if (event->attr.precise_ip > 1 && intel_pmu_pebs_fixup_ip(regs))
+

[PATCH V8 3/8] perf, x86: handle multiple records in PEBS buffer

2015-05-06 Thread Kan Liang

From: Yan, Zheng 

When the PEBS interrupt threshold is larger than one record and the
machine supports multiple PEBS events, the records of these events are
mixed up and we need to demultiplex them.

Demuxing the records is hard because the hardware is deficient. The
hardware has two issues that, when combined, create impossible scenarios
to demux.

The first issue is that the 'status' field of the PEBS record is a copy
of the GLOBAL_STATUS MSR at PEBS assist time. To see why this is a
problem let us first describe the regular PEBS cycle:

A) the CTRn value reaches 0:
  - the corresponding bit in GLOBAL_STATUS gets set
  - we start arming the hardware assist
  < some unspecified amount of time later -- this could cover multiple
events of interest >

B) the hardware assist is armed, any next event will trigger it

C) a matching event happens:
  - the hardware assist triggers and generates a PEBS record
this includes a copy of GLOBAL_STATUS at this moment
  - if we auto-reload we (re)set CTRn
  - we clear the relevant bit in GLOBAL_STATUS

Now consider the following chain of events:

A0, B0, A1, C0

The event generated for counter 0 will include a status with counter 1
set, even though its not at all related to the record. A similar thing
can happen with a !PEBS event if it just happens to overflow at the
right moment.

The second issue is that the hardware will only emit one record for two
or more counters if the event that triggers the assist is 'close'. The
'close' can be several cycles. In some cases even the complete assist,
if the event is something that doesn't need retirement.

For instance, consider this chain of events:
A0, B0, A1, B1, C01

Where C01 is an event that triggers both hardware assists, we will
generate but a single record, but again with both counters listed in the
status field.

This time the record pertains to both events.

Note that these two cases are different but undistinguishable with the
data as generated. Therefore demuxing records with multiple PEBS bits
(we can safely ignore status bits for !PEBS counters) is impossible.

Furthermore we cannot emit the record to both events because that might
cause a data leak -- the events might not have the same privileges -- so
what this patch does is discard such events.

The assumption/hope is that such discards will be rare.

Here lists some possible ways you may get high discard rate.
  - when you count the same thing multiple times. But it is not a useful
configuration.
  - you can be unfortunate if you measure with a userspace only PEBS
event along with either a kernel or unrestricted PEBS event. Imagine
the event triggering and setting the overflow flag right before
entering the kernel. Then all kernel side events will end up with
multiple bits set.

Signed-off-by: Yan, Zheng 
Signed-off-by: Kan Liang 
---
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 144 +-
 include/linux/perf_event.h|  13 +++
 kernel/events/core.c  |   6 +-
 kernel/events/internal.h  |   9 --
 4 files changed, 118 insertions(+), 54 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index f26c8b4..28354ed 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -872,6 +872,9 @@ static void setup_pebs_sample_data(struct perf_event *event,
int fll, fst, dsrc;
int fl = event->hw.flags;
 
+   if (pebs == NULL)
+   return;
+
sample_type = event->attr.sample_type;
dsrc = sample_type & PERF_SAMPLE_DATA_SRC;
 
@@ -966,19 +969,68 @@ static void setup_pebs_sample_data(struct perf_event 
*event,
data->br_stack = >lbr_stack;
 }
 
+static inline void *
+get_next_pebs_record_by_bit(void *base, void *top, int bit)
+{
+   struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
+   void *at;
+   u64 pebs_status;
+
+   if (base == NULL)
+   return NULL;
+
+   for (at = base; at < top; at += x86_pmu.pebs_record_size) {
+   struct pebs_record_nhm *p = at;
+
+   if (test_bit(bit, (unsigned long *)>status)) {
+
+   if (p->status == (1 << bit))
+   return at;
+
+   /* clear non-PEBS bit and re-check */
+   pebs_status = p->status & cpuc->pebs_enabled;
+   pebs_status &= (1ULL << MAX_PEBS_EVENTS) - 1;
+   if (pebs_status == (1 << bit))
+   return at;
+   }
+   }
+   return NULL;
+}
+
 static void __intel_pmu_pebs_event(struct perf_event *event,
-  struct pt_regs *iregs, void *__pebs)
+  struct pt_regs *iregs,
+  void *base, void *top,
+  int bit, int count)
 {

[PATCH V8 0/8] large PEBS interrupt threshold

2015-05-06 Thread Kan Liang

This patch series implements large PEBS interrupt threshold.
Currently, the PEBS threshold is forced to set to one. A larger PEBS
interrupt threshold can significantly reduce the sampling overhead
especially for frequently occurring events
(like cycles or branches or load/stores) with small sampling period.
For example, perf record cycles event when running kernbench
with 10003 sampling period. The Elapsed Time reduced from 32.7 seconds
to 16.5 seconds, which is 2X faster.
For more details, please refer to patch 4's description.

Limitations:
 - It can not supply a callgraph.
 - It requires setting a fixed period.
 - It cannot supply a time stamp.
 - To supply a TID it requires flushing on context switch.
If the above requirement doesn't apply, the threshold will set to one.

Discard samples:
When PEBS events happen close to each other, the records for the events
could be mixed up. Demuxing the records is hard because of hardware
deficiecy. As a result, we have to drop some PEBS records.
A new RECORD type, PERF_RECORD_LOST_SAMPLES, is introduced to record
the number of possible discards, and make sure the user is not left
in the dark about such discards.
For details about sample discards, please refer to patch 3's description.

changes since v1:
  - drop patch 'perf, core: Add all PMUs to pmu_idr'
  - add comments for case that multiple counters overflow simultaneously
changes since v2:
  - rename perf_sched_cb_{enable,disable} to perf_sched_cb_user_{inc,dec}
  - use flag to indicate auto reload mechanism
  - move codes that setup PEBS sample data to separate function
  - output the PEBS records in batch
  - enable this for All (PEBS capable) hardware
  - more description for the multiplex
changes since v3:
  - ignore conflicting PEBS record
changes since v4:
  - Do more tests for collision and update comments
changes since v5:
  - Move autoreload and large PEBS available check to intel_pmu_hw_config
  - make AUTO_RELOAD conditional on large PEBS
  - !PEBS bug fix
  - coherent story about what is collision and how we handle it
  - Remove extra state pebs_sched_cb_enabled
changes since v6:
  - new flag PERF_X86_EVENT_FREERUNNING to indicate large PEBS available
  - patch reorder and changelog changes for patch 1 and 3
  - An easy way to clear !PEBS bit
  - Log collision to PERF_RECORD_SAMPLES_LOST
changes since v7:
  - Introduce PERF_RECORD_LOST_SAMPLES to record the number of discards
  - Remove entire for_each_set_bit() loop
  - Minor changes on comments and changelog

Yan, Zheng (6):
  perf, x86: use the PEBS auto reload mechanism when possible
  perf, x86: introduce setup_pebs_sample_data()
  perf, x86: handle multiple records in PEBS buffer
  perf, x86: large PEBS interrupt threshold
  perf, x86: drain PEBS buffer during context switch
  perf, x86: enlarge PEBS buffer

Kan Liang (2):
  perf, x86: introduce PERF_RECORD_LOST_SAMPLES
  perf tools: handle PERF_RECORD_LOST_SAMPLES

 arch/x86/kernel/cpu/perf_event.c   |  15 +-
 arch/x86/kernel/cpu/perf_event.h   |  16 ++
 arch/x86/kernel/cpu/perf_event_intel.c |  22 ++-
 arch/x86/kernel/cpu/perf_event_intel_ds.c  | 307 +
 arch/x86/kernel/cpu/perf_event_intel_lbr.c |   3 -
 include/linux/perf_event.h |  16 ++
 include/uapi/linux/perf_event.h|  12 ++
 kernel/events/core.c   |  41 +++-
 kernel/events/internal.h   |   9 -
 tools/perf/util/event.c|   9 +
 tools/perf/util/event.h|  18 ++
 tools/perf/util/machine.c  |  10 +
 tools/perf/util/machine.h  |   2 +
 tools/perf/util/session.c  |  19 ++
 tools/perf/util/tool.h |   1 +
 15 files changed, 390 insertions(+), 110 deletions(-)

-- 
1.8.3.1

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

[PATCH V8 7/8] perf, x86: introduce PERF_RECORD_LOST_SAMPLES

2015-05-06 Thread Kan Liang

From: Kan Liang 

After enlarging the PEBS interrupt threshold, there may be some mixed up
PEBS samples which are discarded by kernel. This patch drives the kernel
to emit a PERF_RECORD_LOST_SAMPLES record with the number of possible
discards when it is impossible to demux the samples. It makes sure the
user is not left in the dark about such discards.

Signed-off-by: Kan Liang 
---
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 16 ++
 include/linux/perf_event.h|  3 +++
 include/uapi/linux/perf_event.h   | 12 +++
 kernel/events/core.c  | 35 +++
 4 files changed, 62 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index fc03e7a..cdd331f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -1127,6 +1127,7 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs 
*iregs)
void *base, *at, *top;
int bit;
short counts[MAX_PEBS_EVENTS] = {};
+   short error[MAX_PEBS_EVENTS] = {};
 
if (!x86_pmu.pebs_active)
return;
@@ -1170,21 +1171,28 @@ static void intel_pmu_drain_pebs_nhm(struct pt_regs 
*iregs)
/* slow path */
pebs_status = p->status & cpuc->pebs_enabled;
pebs_status &= (1ULL << MAX_PEBS_EVENTS) - 1;
-   if (pebs_status != (1 << bit))
+   if (pebs_status != (1 << bit)) {
+   error[bit]++;
continue;
+   }
}
counts[bit]++;
}
 
for (bit = 0; bit < x86_pmu.max_pebs_events; bit++) {
-   if (counts[bit] == 0)
+   if ((counts[bit] == 0) && (error[bit] == 0))
continue;
event = cpuc->events[bit];
WARN_ON_ONCE(!event);
WARN_ON_ONCE(!event->attr.precise_ip);
 
-   __intel_pmu_pebs_event(event, iregs, base,
-  top, bit, counts[bit]);
+   /* log dropped samples number */
+   if (error[bit])
+   perf_log_lost_samples(event, error[bit]);
+
+   if (counts[bit])
+   __intel_pmu_pebs_event(event, iregs, base,
+  top, bit, counts[bit]);
}
 }
 
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index bed1b6f..d47d792 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -747,6 +747,9 @@ perf_event__output_id_sample(struct perf_event *event,
 struct perf_output_handle *handle,
 struct perf_sample_data *sample);
 
+extern void
+perf_log_lost_samples(struct perf_event *event, u64 lost);
+
 static inline bool is_sampling_event(struct perf_event *event)
 {
return event->attr.sample_period != 0;
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 309211b..2c1ae5c 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -800,6 +800,18 @@ enum perf_event_type {
 */
PERF_RECORD_ITRACE_START= 12,
 
+   /*
+* Records the dropped/lost sample number.
+*
+* struct {
+*  struct perf_event_headerheader;
+*  u64 id;
+*  u64 lost;
+*  struct sample_idsample_id;
+* };
+*/
+   PERF_RECORD_LOST_SAMPLES= 13,
+
PERF_RECORD_MAX,/* non-ABI */
 };
 
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4d221a4..1337fe3 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5927,6 +5927,41 @@ void perf_event_aux_event(struct perf_event *event, 
unsigned long head,
 }
 
 /*
+ * Lost/dropped samples logging
+ */
+void perf_log_lost_samples(struct perf_event *event, u64 lost)
+{
+   struct perf_output_handle handle;
+   struct perf_sample_data sample;
+   int ret;
+
+   struct {
+   struct perf_event_headerheader;
+   u64 id;
+   u64 lost;
+   } lost_samples_event = {
+   .header = {
+   .type = PERF_RECORD_LOST_SAMPLES,
+   .misc = 0,
+   .size = sizeof(lost_samples_event),
+   },
+   .id = event->id,
+   .lost   = lost,
+   };
+
+   perf_event_header__init_id(_samples_event.header, , event);
+
+   ret = perf_output_begin(, event,
+   lost_samples_event.header.size);
+

[PATCH V8 8/8] perf tools: handle PERF_RECORD_LOST_SAMPLES

2015-05-06 Thread Kan Liang

From: Kan Liang 

This patch modified the perf tool to handle the new RECORD type,
PERF_RECORD_LOST_SAMPLES.
The number of lost-sample events is stored in
.nr_events[PERF_EVENT_LOST_SAMPLES]. While the exact number of samples
which the kernel dropped is stored in total_lost_samples.
When the percentage of dropped samples is greater than 5%, a warning
will be sent out.

Here are some examples:

Eg 1, Recording different frequently-occurring events is safe with the
  patch. Only a very low drop rate is associated with such actions.

$ perf record -e '{cycles:p,instructions:p}' -c 20003 --no-time ~/tchain
~/tchain
[perf record: Woken up 148 times to write data]
[perf record: Captured and wrote 36.922 MB perf.data (1206322 samples)]

$ perf report -D | tail
  SAMPLE events:1206322
   MMAP2 events:  5
 LOST_SAMPLE events:   2559
  FINISHED_ROUND events:148
cycles:p stats:
   TOTAL events: 606278
  SAMPLE events: 606278
instructions:p stats:
   TOTAL events: 600044
  SAMPLE events: 600044

Eg 2, Recording the same thing multiple times can lead to high drop
  rate, but it is not a useful configuration.

$ perf record -e '{cycles:p,cycles:p}' -c 20003 --no-time ~/tchain
[perf record: Woken up 1 times to write data]
Warning:
Processed 600592 samples and lost 99.73% samples!
[perf record: Captured and wrote 0.121 MB perf.data (1629 samples)]

Signed-off-by: Kan Liang 
---
 tools/perf/util/event.c   |  9 +
 tools/perf/util/event.h   | 18 ++
 tools/perf/util/machine.c | 10 ++
 tools/perf/util/machine.h |  2 ++
 tools/perf/util/session.c | 19 +++
 tools/perf/util/tool.h|  1 +
 6 files changed, 59 insertions(+)

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index db52609..2daadc8 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -25,6 +25,7 @@ static const char *perf_event__names[] = {
[PERF_RECORD_SAMPLE]= "SAMPLE",
[PERF_RECORD_AUX]   = "AUX",
[PERF_RECORD_ITRACE_START]  = "ITRACE_START",
+   [PERF_RECORD_LOST_SAMPLES]  = "LOST_SAMPLES",
[PERF_RECORD_HEADER_ATTR]   = "ATTR",
[PERF_RECORD_HEADER_EVENT_TYPE] = "EVENT_TYPE",
[PERF_RECORD_HEADER_TRACING_DATA]   = "TRACING_DATA",
@@ -713,6 +714,14 @@ int perf_event__process_itrace_start(struct perf_tool 
*tool __maybe_unused,
return machine__process_itrace_start_event(machine, event);
 }
 
+int perf_event__process_lost_samples(struct perf_tool *tool __maybe_unused,
+union perf_event *event,
+struct perf_sample *sample,
+struct machine *machine)
+{
+   return machine__process_lost_samples_event(machine, event, sample);
+}
+
 size_t perf_event__fprintf_mmap(union perf_event *event, FILE *fp)
 {
return fprintf(fp, " %d/%d: [%#" PRIx64 "(%#" PRIx64 ") @ %#" PRIx64 
"]: %c %s\n",
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 7eecd5e..abfc579 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -52,6 +52,12 @@ struct lost_event {
u64 lost;
 };
 
+struct lost_samples_event {
+   struct perf_event_header header;
+   u64 id;
+   u64 lost;
+};
+
 /*
  * PERF_FORMAT_ENABLED | PERF_FORMAT_RUNNING | PERF_FORMAT_ID
  */
@@ -235,6 +241,12 @@ enum auxtrace_error_type {
  * total_lost tells exactly how many events the kernel in fact lost, i.e. it is
  * the sum of all struct lost_event.lost fields reported.
  *
+ * The kernel discards mixed up samples and sends the number in a
+ * PERF_RECORD_LOST_SAMPLES event. The number of lost-samples events is stored
+ * in .nr_events[PERF_EVENT_LOST_SAMPLES] while total_lost_samples tells
+ * exactly how many samples the kernel in fact dropped, i.e. it is the sum of
+ * all struct lost_samples_event.lost fields reported.
+ *
  * The total_period is needed because by default auto-freq is used, so
  * multipling nr_events[PERF_EVENT_SAMPLE] by a frequency isn't possible to get
  * the total number of low level events, it is necessary to to sum all struct
@@ -244,6 +256,7 @@ struct events_stats {
u64 total_period;
u64 total_non_filtered_period;
u64 total_lost;
+   u64 total_lost_samples;
u64 total_invalid_chains;
u32 nr_events[PERF_RECORD_HEADER_MAX];
u32 nr_non_filtered_samples;
@@ -342,6 +355,7 @@ union perf_event {
struct comm_event   comm;
struct fork_event   fork;
struct lost_event   lost;
+   struct lost_samples_event   lost_samples;
struct read_event   read;
struct throttle_event   throttle;
struct sample_event sample;
@@ -390,6 +404,10 @@ int

[PATCH V8 6/8] perf, x86: enlarge PEBS buffer

2015-05-06 Thread Kan Liang

From: Yan, Zheng 

Currently the PEBS buffer size is 4k, it only can hold about 21
PEBS records. This patch enlarges the PEBS buffer size to 64k
(the same as BTS buffer), 64k memory can hold about 330 PEBS
records. This will significantly the reduce number of PMI when
large PEBS interrupt threshold is used.

Signed-off-by: Yan, Zheng 
Signed-off-by: Kan Liang 
---
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 9ec5a16..fc03e7a 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -11,7 +11,7 @@
 #define BTS_RECORD_SIZE24
 
 #define BTS_BUFFER_SIZE(PAGE_SIZE << 4)
-#define PEBS_BUFFER_SIZE   PAGE_SIZE
+#define PEBS_BUFFER_SIZE   (PAGE_SIZE << 4)
 #define PEBS_FIXUP_SIZEPAGE_SIZE
 
 /*
-- 
1.8.3.1

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

[PATCH V8 1/8] perf, x86: use the PEBS auto reload mechanism when possible

2015-05-06 Thread Kan Liang

From: Yan, Zheng 

When a fixed period is specified, this patch make perf use the PEBS
auto reload mechanism. This makes normal profiling faster, because
it avoids one costly MSR write in the PMI handler.
However, the reset value will be loaded by hardware assist. There is a
little bit delay compared to previous non-auto-reload mechanism. The
delay time is arbitrary, but very small. The assist cost is 400-800
cycles, assuming common cases with everything cached. The minimum period
the patch currently uses is 1. In that extreme case it can be ~10%
if cycles are used.

Signed-off-by: Yan, Zheng 
Signed-off-by: Kan Liang 
---
 arch/x86/kernel/cpu/perf_event.c  | 15 +--
 arch/x86/kernel/cpu/perf_event.h  |  1 +
 arch/x86/kernel/cpu/perf_event_intel.c|  8 ++--
 arch/x86/kernel/cpu/perf_event_intel_ds.c |  7 +++
 4 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 87848eb..8cc1153 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -1058,13 +1058,16 @@ int x86_perf_event_set_period(struct perf_event *event)
 
per_cpu(pmc_prev_left[idx], smp_processor_id()) = left;
 
-   /*
-* The hw event starts counting from this event offset,
-* mark it to be able to extra future deltas:
-*/
-   local64_set(>prev_count, (u64)-left);
+   if (!(hwc->flags & PERF_X86_EVENT_AUTO_RELOAD) ||
+   local64_read(>prev_count) != (u64)-left) {
+   /*
+* The hw event starts counting from this event offset,
+* mark it to be able to extra future deltas:
+*/
+   local64_set(>prev_count, (u64)-left);
 
-   wrmsrl(hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask);
+   wrmsrl(hwc->event_base, (u64)(-left) & x86_pmu.cntval_mask);
+   }
 
/*
 * Due to erratum on certan cpu we need
diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 6ac5cb7..1cb5859 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -74,6 +74,7 @@ struct event_constraint {
 #define PERF_X86_EVENT_EXCL0x0040 /* HT exclusivity on counter */
 #define PERF_X86_EVENT_DYNAMIC 0x0080 /* dynamic alloc'd constraint */
 #define PERF_X86_EVENT_RDPMC_ALLOWED   0x0100 /* grant rdpmc permission */
+#define PERF_X86_EVENT_AUTO_RELOAD 0x0200 /* use PEBS auto-reload */
 
 
 struct amd_nb {
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 960e85d..3119071 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2305,8 +2305,12 @@ static int intel_pmu_hw_config(struct perf_event *event)
if (ret)
return ret;
 
-   if (event->attr.precise_ip && x86_pmu.pebs_aliases)
-   x86_pmu.pebs_aliases(event);
+   if (event->attr.precise_ip) {
+   if (!event->attr.freq)
+   event->hw.flags |= PERF_X86_EVENT_AUTO_RELOAD;
+   if (x86_pmu.pebs_aliases)
+   x86_pmu.pebs_aliases(event);
+   }
 
if (needs_branch_stack(event)) {
ret = intel_pmu_setup_lbr_filter(event);
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 813f75d..f856f73 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -688,6 +688,7 @@ void intel_pmu_pebs_enable(struct perf_event *event)
 {
struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
struct hw_perf_event *hwc = >hw;
+   struct debug_store *ds = cpuc->ds;
 
hwc->config &= ~ARCH_PERFMON_EVENTSEL_INT;
 
@@ -697,6 +698,12 @@ void intel_pmu_pebs_enable(struct perf_event *event)
cpuc->pebs_enabled |= 1ULL << (hwc->idx + 32);
else if (event->hw.flags & PERF_X86_EVENT_PEBS_ST)
cpuc->pebs_enabled |= 1ULL << 63;
+
+   /* Use auto-reload if possible to save a MSR write in the PMI */
+   if (hwc->flags & PERF_X86_EVENT_AUTO_RELOAD) {
+   ds->pebs_event_reset[hwc->idx] =
+   (u64)(-hwc->sample_period) & x86_pmu.cntval_mask;
+   }
 }
 
 void intel_pmu_pebs_disable(struct perf_event *event)
-- 
1.8.3.1

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

[PATCH V8 5/8] perf, x86: drain PEBS buffer during context switch

2015-05-06 Thread Kan Liang

From: Yan, Zheng 

Flush the PEBS buffer during context switch if PEBS interrupt threshold
is larger than one. This allows perf to supply TID for sample outputs.

Signed-off-by: Yan, Zheng 
Signed-off-by: Kan Liang 
---
 arch/x86/kernel/cpu/perf_event.h   |  6 +-
 arch/x86/kernel/cpu/perf_event_intel.c | 11 +-
 arch/x86/kernel/cpu/perf_event_intel_ds.c  | 32 ++
 arch/x86/kernel/cpu/perf_event_intel_lbr.c |  3 ---
 4 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 626ded3..8746c61 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -91,9 +91,11 @@ struct amd_nb {
 /*
  * Flags PEBS can handle without an PMI.
  *
+ * TID can only be handled by flushing at context switch.
+ *
  */
 #define PEBS_FREERUNNING_FLAGS \
-   (PERF_SAMPLE_IP | PERF_SAMPLE_ADDR | \
+   (PERF_SAMPLE_IP | PERF_SAMPLE_TID | PERF_SAMPLE_ADDR | \
PERF_SAMPLE_ID | PERF_SAMPLE_CPU | PERF_SAMPLE_STREAM_ID | \
PERF_SAMPLE_DATA_SRC | PERF_SAMPLE_IDENTIFIER | \
PERF_SAMPLE_TRANSACTION)
@@ -872,6 +874,8 @@ void intel_pmu_pebs_enable_all(void);
 
 void intel_pmu_pebs_disable_all(void);
 
+void intel_pmu_pebs_sched_task(struct perf_event_context *ctx, bool sched_in);
+
 void intel_ds_init(void);
 
 void intel_pmu_lbr_sched_task(struct perf_event_context *ctx, bool sched_in);
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index fdf818a..c4c5e1f 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2702,6 +2702,15 @@ static void intel_pmu_cpu_dying(int cpu)
fini_debug_store_on_cpu(cpu);
 }
 
+static void intel_pmu_sched_task(struct perf_event_context *ctx,
+bool sched_in)
+{
+   if (x86_pmu.pebs_active)
+   intel_pmu_pebs_sched_task(ctx, sched_in);
+   if (x86_pmu.lbr_nr)
+   intel_pmu_lbr_sched_task(ctx, sched_in);
+}
+
 PMU_FORMAT_ATTR(offcore_rsp, "config1:0-63");
 
 PMU_FORMAT_ATTR(ldlat, "config1:0-15");
@@ -2791,7 +2800,7 @@ static __initconst const struct x86_pmu intel_pmu = {
.cpu_starting   = intel_pmu_cpu_starting,
.cpu_dying  = intel_pmu_cpu_dying,
.guest_get_msrs = intel_guest_get_msrs,
-   .sched_task = intel_pmu_lbr_sched_task,
+   .sched_task = intel_pmu_sched_task,
 };
 
 static __init void intel_clovertown_quirk(void)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 7389a12..9ec5a16 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -546,6 +546,19 @@ int intel_pmu_drain_bts_buffer(void)
return 1;
 }
 
+static inline void intel_pmu_drain_pebs_buffer(void)
+{
+   struct pt_regs regs;
+
+   x86_pmu.drain_pebs();
+}
+
+void intel_pmu_pebs_sched_task(struct perf_event_context *ctx, bool sched_in)
+{
+   if (!sched_in)
+   intel_pmu_drain_pebs_buffer();
+}
+
 /*
  * PEBS
  */
@@ -711,8 +724,19 @@ void intel_pmu_pebs_enable(struct perf_event *event)
if (hwc->flags & PERF_X86_EVENT_FREERUNNING) {
threshold = ds->pebs_absolute_maximum -
x86_pmu.max_pebs_events * x86_pmu.pebs_record_size;
+
+   if (first_pebs)
+   perf_sched_cb_inc(event->ctx->pmu);
} else {
threshold = ds->pebs_buffer_base + x86_pmu.pebs_record_size;
+
+   /*
+* If not all events can use larger buffer,
+* roll back to threshold = 1
+*/
+   if (!first_pebs &&
+   (ds->pebs_interrupt_threshold > threshold))
+   perf_sched_cb_dec(event->ctx->pmu);
}
 
/* Use auto-reload if possible to save a MSR write in the PMI */
@@ -729,6 +753,7 @@ void intel_pmu_pebs_disable(struct perf_event *event)
 {
struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
struct hw_perf_event *hwc = >hw;
+   struct debug_store *ds = cpuc->ds;
 
cpuc->pebs_enabled &= ~(1ULL << hwc->idx);
 
@@ -737,6 +762,13 @@ void intel_pmu_pebs_disable(struct perf_event *event)
else if (event->hw.constraint->flags & PERF_X86_EVENT_PEBS_ST)
cpuc->pebs_enabled &= ~(1ULL << 63);
 
+   if (ds->pebs_interrupt_threshold >
+   ds->pebs_buffer_base + x86_pmu.pebs_record_size) {
+   intel_pmu_drain_pebs_buffer();
+   if (!pebs_is_enabled(cpuc))
+   perf_sched_cb_dec(event->ctx->pmu);
+   }
+
if (cpuc->enabled)
wrmsrl(MSR_IA32_PEBS_ENABLE, cpuc->pebs_enabled);
 
diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c 
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index

[PATCH V8 4/8] perf, x86: large PEBS interrupt threshold

2015-05-06 Thread Kan Liang

From: Yan, Zheng 

PEBS always had the capability to log samples to its buffers without
an interrupt. Traditionally perf has not used this but always set the
PEBS threshold to one.

For frequently occurring events (like cycles or branches or load/store)
this in term requires using a relatively high sampling period to avoid
overloading the system, by only processing PMIs. This in term increases
sampling error.

For the common cases we still need to use the PMI because the PEBS
hardware has various limitations. The biggest one is that it can not
supply a callgraph. It also requires setting a fixed period, as the
hardware does not support adaptive period. Another issue is that it
cannot supply a time stamp and some other options. To supply a TID it
requires flushing on context switch. It can however supply the IP, the
load/store address, TSX information, registers, and some other things.

So we can make PEBS work for some specific cases, basically as long as
you can do without a callgraph and can set the period you can use this
new PEBS mode.

The main benefit is the ability to support much lower sampling period
(down to -c 1000) without extensive overhead.

One use cases is for example to increase the resolution of the c2c tool.
Another is double checking when you suspect the standard sampling has
too much sampling error.

Some numbers on the overhead, using cycle soak, comparing the elapsed
time from "kernbench -M -H" between plain (threshold set to one) and
multi (large threshold).
The test command for plain:
  "perf record --time -e cycles:p -c $period -- kernbench -M -H"
The test command for multi:
  "perf record --no-time -e cycles:p -c $period -- kernbench -M -H"
(The only difference of test command between multi and plain is time
stamp options. Since time stamp is not supported by large PEBS
threshold, it can be used as a flag to indicate if large threshold is
enabled during the test.)

periodplain(Sec)  multi(Sec)  Delta
10003 32.716.516.2
20003 30.216.214.0
40003 18.614.14.5
80003 16.814.62.2
1316.914.12.8
8315.415.7-0.3
103   15.315.20.2
203   15.315.10.1

With periods below 13, plain (threshold one) cause much more
overhead. With 10003 sampling period, the Elapsed Time for multi is
even 2X faster than plain.

Signed-off-by: Yan, Zheng 
Signed-off-by: Kan Liang 
---
 arch/x86/kernel/cpu/perf_event.h  | 11 +++
 arch/x86/kernel/cpu/perf_event_intel.c|  5 -
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 27 +++
 3 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event.h b/arch/x86/kernel/cpu/perf_event.h
index 1cb5859..626ded3 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -75,6 +75,7 @@ struct event_constraint {
 #define PERF_X86_EVENT_DYNAMIC 0x0080 /* dynamic alloc'd constraint */
 #define PERF_X86_EVENT_RDPMC_ALLOWED   0x0100 /* grant rdpmc permission */
 #define PERF_X86_EVENT_AUTO_RELOAD 0x0200 /* use PEBS auto-reload */
+#define PERF_X86_EVENT_FREERUNNING 0x0400 /* use freerunning PEBS */
 
 
 struct amd_nb {
@@ -88,6 +89,16 @@ struct amd_nb {
 #define MAX_PEBS_EVENTS8
 
 /*
+ * Flags PEBS can handle without an PMI.
+ *
+ */
+#define PEBS_FREERUNNING_FLAGS \
+   (PERF_SAMPLE_IP | PERF_SAMPLE_ADDR | \
+   PERF_SAMPLE_ID | PERF_SAMPLE_CPU | PERF_SAMPLE_STREAM_ID | \
+   PERF_SAMPLE_DATA_SRC | PERF_SAMPLE_IDENTIFIER | \
+   PERF_SAMPLE_TRANSACTION)
+
+/*
  * A debug store configuration.
  *
  * We only support architectures that use 64bit fields.
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
b/arch/x86/kernel/cpu/perf_event_intel.c
index 3119071..fdf818a 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -2306,8 +2306,11 @@ static int intel_pmu_hw_config(struct perf_event *event)
return ret;
 
if (event->attr.precise_ip) {
-   if (!event->attr.freq)
+   if (!event->attr.freq) {
event->hw.flags |= PERF_X86_EVENT_AUTO_RELOAD;
+   if (!(event->attr.sample_type & 
~PEBS_FREERUNNING_FLAGS))
+   event->hw.flags |= PERF_X86_EVENT_FREERUNNING;
+   }
if (x86_pmu.pebs_aliases)
x86_pmu.pebs_aliases(event);
}
diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index 28354ed..7389a12 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -250,7 +250,7 @@ static int alloc_pebs_buffer(int cpu)
 {
struct debug_store *ds = per_cpu(cpu_hw_events, cpu).ds;
int node = cpu_to_node(cpu);
-   int max, thresh = 1; /* always use a

Re: [PATCH 0/13] Parallel struct page initialisation v4

2015-05-06 Thread Waiman Long


On 05/06/2015 01:58 PM, Waiman Long wrote:

On 05/06/2015 06:22 AM, Mel Gorman wrote:

On Wed, May 06, 2015 at 08:12:46AM +0100, Mel Gorman wrote:

On Tue, May 05, 2015 at 03:25:49PM -0700, Andrew Morton wrote:

On Tue, 5 May 2015 23:13:29 +0100 Mel Gorman  wrote:


Alternatively, the page allocator can go off and synchronously
initialize some pageframes itself.  Keep doing that until the
allocation attempt succeeds.

That was rejected during review of earlier attempts at this 
feature on

the grounds that it impacted allocator fast paths.

eh?  Changes are only needed on the allocation-attempt-failed path,
which is slow-path.
We'd have to distinguish between falling back to other zones because 
the
high zone is artifically exhausted and normal ALLOC_BATCH 
exhaustion. We'd
also have to avoid falling back to remote nodes prematurely. While I 
have
not tried an implementation, I expected they would need to be in the 
fast
paths unless I used jump labels to get around it. I'm going to try 
altering

when we initialise instead so that it happens earlier.


Which looks as follows. Waiman, a test on the 24TB machine would be
appreciated again. This patch should be applied instead of "mm: meminit:
Take into account that large system caches scale linearly with memory"

---8<---
mm: meminit: Finish initialisation of memory before basic setup

Waiman Long reported that 24TB machines hit OOM during basic setup when
struct page initialisation was deferred. One approach is to 
initialise memory
on demand but it interferes with page allocator paths. This patch 
creates
dedicated threads to initialise memory before basic setup. It then 
blocks
on a rw_semaphore until completion as a wait_queue and counter is 
overkill.
This may be slower to boot but it's simplier overall and also gets 
rid of a
lot of section mangling which existed so kswapd could do the 
initialisation.


Signed-off-by: Mel Gorman



This patch moves the deferred meminit from kswapd to its own kernel 
threads started after smp_init(). However, the hash table allocation 
was done earlier than that. It seems like it will still run out of 
memory in the 24TB machine that I tested on.


I will certainly try it out, but I doubt it will solve the problem on 
its own.


It turns out that the two new patches did work on the 24-TB DragonHawk 
without the "mm: meminit: Take into account that large system caches 
scale linearly with memory" patch. The bootup time was 357s which was 
just a few seconds slower than the other bootup times that I sent you 
yesterday.


BTW, do you want to change the following log message as kswapd will no 
longer be the one doing deferred meminit?


kswapd 0 initialised 396098436 pages in 6024ms

Cheers,
Longman

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

Re: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn_t

2015-05-06 Thread Dan Williams

On Wed, May 6, 2015 at 5:19 PM, Linus Torvalds
 wrote:
> On Wed, May 6, 2015 at 4:47 PM, Dan Williams  wrote:
>>
>> Conceptually better, but certainly more difficult to audit if the fake
>> struct page is initialized in a subtle way that breaks when/if it
>> leaks to some unwitting context.
>
> Maybe. It could go either way, though. In particular, with the
> "dynamically allocated struct page" approach, if somebody uses it past
> the supposed lifetime of the use, things like poisoning the temporary
> "struct page" could be fairly effective. You can't really poison the
> pfn - it's just a number, and if somebody uses it later than you think
> (and you have re-used that physical memory for something else), you'll
> never ever know.

True, but there's little need to poison a _pfn_t because it's
permanent once discovered via ->direct_access() on the hosting struct
block_device.  Sure, kmap_atomic_pfn_t() may fail when the pmem driver
unbinds from a device, but the __pfn_t is still valid.  Obviously, we
can only support atomic kmap(s) with this property, and it would be
nice to fault if someone continued to use the __pfn_t after the
hosting device was disabled.  To be clear, DAX has this same problem
today.  Nothing stops whomever called ->direct_access() to continue
using the pfn after the backing device has been disabled.

> I'd *assume* that most users of the dynamic "struct page" allocation
> have very clear lifetime rules. Those things would presumably normally
> get looked-up by some extended version of "get_user_pages()", and
> there's a clear use of the result, with no longer lifetime. Also, you
> do need to have some higher-level locking when you  do this, to make
> sure that the persistent pages don't magically get re-assigned. We're
> presumably talking about having a filesystem in that persistent
> memory, so we cannot be doing IO to the pages (from some other source
> - whether RDMA or some special zero-copy model) while the underlying
> filesystem is reassigning the storage because somebody deleted the
> file.
>
> IOW, there had better be other external rules about when - and how
> long - you can use a particular persistent page. No? So the whole
> "when/how to allocate the temporary 'struct page'" is just another
> detail in that whole thing.
>
> And yes, some uses may not ever actually see that. If the whole of
> persistent memory is just assigned to a database or something, and the
> DB just wants to do a "flush this range of persistent memory to
> long-term disk storage", then there may not be much of a "lifetime"
> issue for the persistent memory. But even then you're going to have IO
> completion callbacks etc to let the DB know that it has hit the disk,
> so..
>
> What is the primary thing that is driving this need? Do we have a very
> concrete example?

My pet concrete example is covered by __pfn_t.  Referencing persistent
memory in an md/dm hierarchical storage configuration.  Setting aside
the thrash to get existing block users to do "bvec_set_page(page)"
instead of "bvec->page = page" the onus is on that md/dm
implementation and backing storage device driver to operate on
__pfn_t.  That use case is simple because there is no use of page
locking or refcounting in that path, just dma_map_page() and
kmap_atomic().  The more difficult use case is precisely what Al
picked up on, O_DIRECT and RDMA.  This patchset does nothing to
address those use cases outside of not needing a struct page when they
eventually craft a bio.

I know Matthew Wilcox has explored the idea of "get_user_sg()" and let
the scatterlist hold the reference count and locks, but I'll let him
speak to that.

I still see __pfn_t as generally useful for the simple in-kernel
stacked-block-i/o use case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC

2015-05-06 Thread Scott Wood

On Wed, 2015-05-06 at 21:26 -0500, Lu Yangbo-B47093 wrote:
> Thanks.
> Pls see my comments below.
> 
> -Original Message-
> From: Wood Scott-B07421 
> Sent: Thursday, May 07, 2015 4:44 AM
> To: Lu Yangbo-B47093
> Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] powerpc/dts: Add 1588 timer node for eTSEC
> 
> On Wed, 2015-05-06 at 17:40 +0800, Yangbo Lu wrote:
> > Add 1588 timer node in files:
> > arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > arch/powerpc/boot/dts/bsc9132qds.dtsi
> > arch/powerpc/boot/dts/p1010rdb.dtsi
> > arch/powerpc/boot/dts/p1020rdb-pd.dts
> > arch/powerpc/boot/dts/p1021rdb-pc.dtsi
> > arch/powerpc/boot/dts/p1022ds.dtsi
> > arch/powerpc/boot/dts/p1025twr.dtsi
> > arch/powerpc/boot/dts/p2020rdb-pc.dtsi
> > 
> > Signed-off-by: Yangbo Lu 
> > ---
> >  arch/powerpc/boot/dts/bsc9131rdb.dtsi  | 12   
> > arch/powerpc/boot/dts/bsc9132qds.dtsi  | 12 
> >  arch/powerpc/boot/dts/p1010rdb.dtsi| 12 
> >  arch/powerpc/boot/dts/p1020rdb-pd.dts  | 12   
> > arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 12 
> >  arch/powerpc/boot/dts/p1022ds.dtsi | 12 
> >  arch/powerpc/boot/dts/p1025twr.dtsi| 12 
> >  arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 15 +--
> >  8 files changed, 93 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi 
> > b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > index 45efcba..629cc03 100644
> > --- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > +++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
> > @@ -80,6 +80,18 @@
> > status = "disabled";
> > };
> >  
> > +   ptp_clock@b0e00 {
> > +   compatible = "fsl,etsec-ptp";
> > +   reg = <0xb0e00 0xb0>;
> > +   interrupts = <68 2 0 0 69 2 0 0>;
> > +   fsl,tclk-period = <5>;
> > +   fsl,tmr-prsc= <2>;
> > +   fsl,tmr-add = <0xcccd>;
> > +   fsl,tmr-fiper1  = <0x3b9ac9fb>;
> > +   fsl,tmr-fiper2  = <0x00018696>;
> > +   fsl,max-adj = <24999>;
> 
> Please don't use hex for numbers that make more sense as decimal.
> [Lu Yangbo-B47093] The hex value is register value, I think it's better to 
> use hex.

Whether it goes into a register doesn't matter.  Hex values are useful
for values which are subdivided into various bitfields, or whose hex
representation is simpler than decimal.  I'm not familiar with the
details of this hardware, but I doubt the former is the case for
0x3b9ac9fb == 95 or 0x18696 == 0.

-Scott


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

Re: not syncing: Attempted to kill init! exitcode=0x00000004 ?

2015-05-06 Thread Masahiro Yamada

Hi Shawn,
(Sorry for late reply, I's been a vacation in Japan.)


2015-05-06 17:56 GMT+09:00 Shawn Guo :
> On Tue, May 5, 2015 at 7:54 PM, Shawn Guo  wrote:
>> On Tue, Apr 07, 2015 at 12:34:30PM +0900, Masahiro Yamada wrote:
>>> Hello experts,
>>> I hope this is the correct ML to ask this question.
>>>
>>> I am struggling to port Linux-4.0-rc7 onto my SoC/board,
>>> based on ARM cortex-A9 (single CPU), but the kernel fails to boot
>>> with the error:
>>> "not syncing: Attempted to kill init! exitcode=0x0004"
>>
>> Hi Masahiro,
>>
>> Have you track it down to the cause?  I'm asking because I'm seeing the
>> same issue with v4.0 on a vendor single Cortex-A9 SoC.

Yes, I have already solved my problem.

In my case,

 - The interrupt number for the UART device was wrong.  Fixed it.
 - I regenerated the initramdisk with Buildroot

and then I could boot the kernel successfully.




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

Re: [PATCH v4 3/3] tracing: add trace event for memory-failure

2015-05-06 Thread Steven Rostedt

On Mon, 20 Apr 2015 16:44:40 +0800
Xie XiuQi  wrote:

> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * MCE Extended Error Log trace event
> @@ -232,6 +233,90 @@ TRACE_EVENT(aer_event,
>   __print_flags(__entry->status, "|", aer_uncorrectable_errors))
>  );
>  
> +/*
> + * memory-failure recovery action result event
> + *
> + * unsigned long pfn -   Page Frame Number of the corrupted page
> + * int type  -   Page types of the corrupted page
> + * int result-   Result of recovery action
> + */
> +
> +#ifdef CONFIG_MEMORY_FAILURE
> +#define MF_ACTION_RESULT \
> + EM ( MF_IGNORED, "Ignord" ) \

 "Ignored" ?

> + EM ( MF_FAILED,  "Failed" ) \
> + EM ( MF_DELAYED, "Delayed" )\
> + EMe ( MF_RECOVERED, "Recovered" )
> +
> +#define MF_PAGE_TYPE \
> + EM ( MF_MSG_KERNEL, "reserved kernel page" )\
> + EM ( MF_MSG_KERNEL_HIGH_ORDER, "high-order kernel page" )   \
> + EM ( MF_MSG_SLAB, "kernel slab page" )  \
> + EM ( MF_MSG_DIFFERENT_COMPOUND, "different compound page after locking" 
> ) \
> + EM ( MF_MSG_POISONED_HUGE, "huge page already hardware poisoned" )  
> \
> + EM ( MF_MSG_HUGE, "huge page" ) \
> + EM ( MF_MSG_FREE_HUGE, "free huge page" )   \
> + EM ( MF_MSG_UNMAP_FAILED, "unmapping failed page" ) \
> + EM ( MF_MSG_DIRTY_SWAPCACHE, "dirty swapcache page" )   \
> + EM ( MF_MSG_CLEAN_SWAPCACHE, "clean swapcache page" )   \
> + EM ( MF_MSG_DIRTY_MLOCKED_LRU, "dirty mlocked LRU page" )   \
> + EM ( MF_MSG_CLEAN_MLOCKED_LRU, "clean mlocked LRU page" )   \
> + EM ( MF_MSG_DIRTY_UNEVICTABLE_LRU, "dirty unevictable LRU page" )   
> \
> + EM ( MF_MSG_CLEAN_UNEVICTABLE_LRU, "clean unevictable LRU page" )   
> \
> + EM ( MF_MSG_DIRTY_LRU, "dirty LRU page" )   \
> + EM ( MF_MSG_CLEAN_LRU, "clean LRU page" )   \
> + EM ( MF_MSG_TRUNCATED_LRU, "already truncated LRU page" )   \
> + EM ( MF_MSG_BUDDY, "free buddy page" )  \
> + EM ( MF_MSG_BUDDY_2ND, "free buddy page (2nd try)" )\
> + EMe ( MF_MSG_UNKNOWN, "unknown page" )
> +
> +/*
> + * First define the enums in MM_ACTION_RESULT to be exported to userspace
> + * via TRACE_DEFINE_ENUM().
> + */
> +#undef EM
> +#undef EMe
> +#define EM(a,b) TRACE_DEFINE_ENUM(a);
> +#define EMe(a,b) TRACE_DEFINE_ENUM(a);
> +
> +MF_ACTION_RESULT
> +MF_PAGE_TYPE
> +
> +/*
> + * Now redefine the EM() and EMe() macros to map the enums to the strings
> + * that will be printed in the output.
> + */
> +#undef EM
> +#undef EMe
> +#define EM(a,b)  { a, b },
> +#define EMe(a,b) { a, b }
> +
> +TRACE_EVENT(memory_failure_event,
> + TP_PROTO(unsigned long pfn,
> +  int type,
> +  int result),
> +
> + TP_ARGS(pfn, type, result),
> +
> + TP_STRUCT__entry(
> + __field(unsigned long, pfn)
> + __field(int, type)
> + __field(int, result)
> + ),
> +
> + TP_fast_assign(
> + __entry->pfn= pfn;
> + __entry->type   = type;
> + __entry->result = result;
> + ),
> +
> + TP_printk("pfn %#lx: recovery action for %s: %s",

Hmm, "%#" is new to me. I'm not sure libtraceevent handles that.

Not your problem, I need to make sure that it does, and if it does not,
I need to fix it.

I'm not even sure what %# does.

Other than the typo,

Acked-by: Steven Rostedt 

-- Steve


> + __entry->pfn,
> + __print_symbolic(__entry->type, MF_PAGE_TYPE),
> + __print_symbolic(__entry->result, MF_ACTION_RESULT)
> + )
> +);
> +#endif /* CONFIG_MEMORY_FAILURE */
>  #endif /* _TRACE_HW_EVENT_MC_H */
>  
>  /* This part must be outside protection */
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index f074f8e..42c5981 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -56,6 +56,7 @@
>  #include 
>  #include 
>  #include "internal.h"
> +#include "ras/ras_event.h"
>  
>  int sysctl_memory_failure_early_kill __read_mostly = 0;
>  
> @@ -850,6 +851,8 @@ static struct page_state {
>  static void action_result(unsigned long pfn, enum mf_action_page_type type,
> enum mf_result result)
>  {
> + trace_memory_failure_event(pfn, type, result);
> +
>   pr_err("MCE %#lx: recovery action for %s: %s\n",
>   pfn, action_page_types[type], action_name[result]);
>  }

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

Re: [PATCH v2 0/3] Dell Airplane Mode Switch driver

2015-05-06 Thread Alex Hung

Darren,

I guess you were looking at "Sheet1" that was comparison between
dell-rbtn and dell-wireless quite a while ago. The updated results for
dell-rbtn v2 are in the tab of "Dell-rbtnv2"

On Thu, May 7, 2015 at 5:57 AM, Darren Hart  wrote:
> On Wed, May 06, 2015 at 01:31:19PM +0200, Pali Rohár wrote:
>> Looks like everything is OK. Test3 is expected to not work correctly as
>> driver is not loaded...
>>
>> On Wednesday 06 May 2015 17:11:08 Alex Hung wrote:
>> > The test was updated @
>> > https://docs.google.com/spreadsheets/d/1voffS6dNglwAExSGh3UmG__UAO2qfZ829CkJLPo06aI/edit?usp=sharing.
>> > Please check the tab "Dell-rbtnv2"
>> >
>> > Notes:
>> > 1. The systems come and go and I can find some of original ones but I
>> > tests some others
>> > 2. Test 3 was done by Test 2 + "rmmod dell-laptop". All were run with
>> > all wireless devices are ON
>> >
>> > Summary:
>> > From external behaves such as Desktop's viewpoint (Unity was used and
>> > hope that's not surprising), the wireless devices are ON/OFF
>> > correctly. Other details are listed in the report.
>
> What am I to make of Sheet1:Row25 vs. Row27?
> This appears to me that for the Inspiron 3542, Dell Wireless for 3.16 has a
> functional soft block, while there is no change for Dell RBNT.
>
> Rows36 and 37... these are tellin gme that the ARBT method is broken on this
> machine?
>
>> --
>> Pali Rohár
>> pali.ro...@gmail.com
>>



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

[PATCH v3 2/3] usb: xhci: implement device_suspend/device_resume entries

2015-05-06 Thread Lu Baolu

This patch implements device_suspend/device_resume entries for xHC driver.
device_suspend will be called when a USB device is about to suspend. It
will issue a stop endpoint command for each endpoint in this device. The
Suspend(SP) bit in the command TRB will set which will give xHC a hint
about the suspend. device_resume will be called when a USB device is just
resumed. It will ring doorbells of all endpoint unconditionally. XHC may
use these suspend/resume hints to optimize its operation.

Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci-hub.c |  2 +-
 drivers/usb/host/xhci.c | 40 
 drivers/usb/host/xhci.h | 11 +++
 3 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 0827d7c..a83e82e 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -266,7 +266,7 @@ int xhci_find_slot_id_by_port(struct usb_hcd *hcd, struct 
xhci_hcd *xhci,
  * to complete.
  * suspend will set to 1, if suspend bit need to set in command.
  */
-static int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend)
+int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend)
 {
struct xhci_virt_device *virt_dev;
struct xhci_command *cmd;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..6b61833 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4680,6 +4680,40 @@ int xhci_disable_usb3_lpm_timeout(struct usb_hcd *hcd,
return ret;
return 0;
 }
+
+/*
+ * xHCI compatible host controller driver expects to be notified prior to
+ * selectively suspending a device. xHCI hcd could optimize the endpoint
+ * cache for power saving purpose. Refer to 4.15.1.1 of xHCI 1.1.
+ */
+void xhci_device_suspend(struct usb_hcd *hcd,
+   struct usb_device *udev, pm_message_t msg)
+{
+   struct xhci_hcd *xhci;
+
+   xhci = hcd_to_xhci(hcd);
+   if (!xhci || !xhci->devs[udev->slot_id])
+   return;
+
+   xhci_stop_device(xhci, udev->slot_id, 1);
+}
+
+/*
+ * xHCI compatible host controller driver expects to be notified after a
+ * USB device is resumed. xHCI hcd could optimize the endpoint cache
+ * to reduce the latency. Refer to 4.15.1.1 of xHCI 1.1.
+ */
+void xhci_device_resume(struct usb_hcd *hcd,
+   struct usb_device *udev, pm_message_t msg)
+{
+   struct xhci_hcd *xhci;
+
+   xhci = hcd_to_xhci(hcd);
+   if (!xhci || !xhci->devs[udev->slot_id])
+   return;
+
+   xhci_ring_device(xhci, udev->slot_id);
+}
 #else /* CONFIG_PM */
 
 int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
@@ -4976,6 +5010,12 @@ static const struct hc_driver xhci_hc_driver = {
.enable_usb3_lpm_timeout =  xhci_enable_usb3_lpm_timeout,
.disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
.find_raw_port_number = xhci_find_raw_port_number,
+
+   /*
+* call back when devices suspend or resume
+*/
+   .device_suspend =   xhci_device_suspend,
+   .device_resume =xhci_device_resume,
 };
 
 void xhci_init_driver(struct hc_driver *drv, int (*setup_fn)(struct usb_hcd *))
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 8e421b8..d826439 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1867,10 +1867,21 @@ u32 xhci_port_state_to_neutral(u32 state);
 int xhci_find_slot_id_by_port(struct usb_hcd *hcd, struct xhci_hcd *xhci,
u16 port);
 void xhci_ring_device(struct xhci_hcd *xhci, int slot_id);
+int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend);
 
 /* xHCI contexts */
 struct xhci_input_control_ctx *xhci_get_input_control_ctx(struct 
xhci_container_ctx *ctx);
 struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci, struct 
xhci_container_ctx *ctx);
 struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci, struct 
xhci_container_ctx *ctx, unsigned int ep_index);
 
+#ifdef CONFIG_PM
+void xhci_device_suspend(struct usb_hcd *hcd,
+   struct usb_device *udev, pm_message_t msg);
+void xhci_device_resume(struct usb_hcd *hcd,
+   struct usb_device *udev, pm_message_t msg);
+#else
+#define xhci_device_suspendNULL
+#define xhci_device_resume NULL
+#endif /* CONFIG_PM */
+
 #endif /* __LINUX_XHCI_HCD_H */
-- 
2.1.0

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

[PATCH v3 0/3] usb: notify hcd when USB device suspend or resume

2015-05-06 Thread Lu Baolu

This patch series try to meet a design requirement in xHCI spec.

The xHCI spec is designed to allow an xHC implementation to cache the
endpoint state. Caching endpoint state allows an xHC to reduce latency
when handling ERDYs and other USB asynchronous events. However holding
this state in xHC consumes resources and power. The xHCI spec designs
some methods through which host controller driver can hint xHC about
how to optimize its operation, e.g. to determine when it holds state
internally or pushes it out to memory, when to power down logic, etc.

When a USB device is going to suspend, states of all endpoints cached
in the xHC should be pushed out to memory to save power and resources.
Vice versa, when a USB device resumes, those states should be brought
back to the cache.

It is harmless if a USB devices under USB 3.0 host controller suspends
or resumes without a notification to hcd driver. However there may be
less opportunities for power savings and there may be increased latency
for restarting an endpoint. The precise impact will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.

Change log:
v2->v3:
 - move two xhci specific comments from hub to xhci
 - define xhci_device_suspend(resume) as NULL when no PM_CONFIG

v1->v2:
 - make the callback name specific to the activity in question
 - no need to export hcd_notify
 - put the callback in the right place

Lu Baolu (3):
  usb: notify hcd when USB device suspend or resume
  usb: xhci: implement device_suspend/device_resume entries
  usb: xhci: remove stop device and ring doorbell in hub control and bus
suspend

 drivers/usb/core/hcd.c  | 29 +++
 drivers/usb/core/hub.c  |  5 +
 drivers/usb/host/xhci-hub.c | 49 +
 drivers/usb/host/xhci.c | 40 
 drivers/usb/host/xhci.h | 11 ++
 include/linux/usb/hcd.h | 10 -
 6 files changed, 95 insertions(+), 49 deletions(-)

-- 
2.1.0

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

[PATCH v3 3/3] usb: xhci: remove stop device and ring doorbell in hub control and bus suspend

2015-05-06 Thread Lu Baolu

There is no need to call xhci_stop_device() and xhci_ring_device() in
hub control and bus suspend functions since all device suspend and
resume have been notified through device_suspend/device_resume interfaces.

Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci-hub.c | 47 -
 1 file changed, 47 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a83e82e..f12e1b7 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -704,7 +704,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 
wValue,
u32 temp, status;
int retval = 0;
__le32 __iomem **port_array;
-   int slot_id;
struct xhci_bus_state *bus_state;
u16 link_state = 0;
u16 wake_mask = 0;
@@ -818,17 +817,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 
wValue,
goto error;
}
 
-   slot_id = xhci_find_slot_id_by_port(hcd, xhci,
-   wIndex + 1);
-   if (!slot_id) {
-   xhci_warn(xhci, "slot_id is zero\n");
-   goto error;
-   }
-   /* unlock to execute stop endpoint commands */
-   spin_unlock_irqrestore(>lock, flags);
-   xhci_stop_device(xhci, slot_id, 1);
-   spin_lock_irqsave(>lock, flags);
-
xhci_set_link_state(xhci, port_array, wIndex, XDEV_U3);
 
spin_unlock_irqrestore(>lock, flags);
@@ -876,19 +864,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 
wValue,
goto error;
}
 
-   if (link_state == USB_SS_PORT_LS_U3) {
-   slot_id = xhci_find_slot_id_by_port(hcd, xhci,
-   wIndex + 1);
-   if (slot_id) {
-   /* unlock to execute stop endpoint
-* commands */
-   spin_unlock_irqrestore(>lock,
-   flags);
-   xhci_stop_device(xhci, slot_id, 1);
-   spin_lock_irqsave(>lock, flags);
-   }
-   }
-
xhci_set_link_state(xhci, port_array, wIndex,
link_state);
 
@@ -994,14 +969,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 
wValue,
XDEV_U0);
}
bus_state->port_c_suspend |= 1 << wIndex;
-
-   slot_id = xhci_find_slot_id_by_port(hcd, xhci,
-   wIndex + 1);
-   if (!slot_id) {
-   xhci_dbg(xhci, "slot_id is zero\n");
-   goto error;
-   }
-   xhci_ring_device(xhci, slot_id);
break;
case USB_PORT_FEAT_C_SUSPEND:
bus_state->port_c_suspend &= ~(1 << wIndex);
@@ -1133,20 +1100,12 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
while (port_index--) {
/* suspend the port if the port is not suspended */
u32 t1, t2;
-   int slot_id;
 
t1 = readl(port_array[port_index]);
t2 = xhci_port_state_to_neutral(t1);
 
if ((t1 & PORT_PE) && !(t1 & PORT_PLS_MASK)) {
xhci_dbg(xhci, "port %d not suspended\n", port_index);
-   slot_id = xhci_find_slot_id_by_port(hcd, xhci,
-   port_index + 1);
-   if (slot_id) {
-   spin_unlock_irqrestore(>lock, flags);
-   xhci_stop_device(xhci, slot_id, 1);
-   spin_lock_irqsave(>lock, flags);
-   }
t2 &= ~PORT_PLS_MASK;
t2 |= PORT_LINK_STROBE | XDEV_U3;
set_bit(port_index, _state->bus_suspended);
@@ -1207,7 +1166,6 @@ int xhci_bus_resume(struct usb_hcd *hcd)
/* Check whether need resume ports. If needed
   resume port and disable remote wakeup */
u32 temp;
-   int slot_id;
 
temp = readl(port_array[port_index]);
if (DEV_SUPERSPEED(temp))
@@ -1240,11 +1198,6 @@ int xhci_bus_resume(struct usb_hcd *hcd)
/* Clear PLC */
xhci_test_and_clear_bit(xhci,

[PATCH v3 1/3] usb: notify hcd when USB device suspend or resume

2015-05-06 Thread Lu Baolu

This patch adds two new entries in hc_driver. With these new entries,
USB core can notify host driver when a USB device is about to suspend
or just resumed.

The xHCI spec is designed to allow an xHC implementation to cache the
endpoint state. Caching endpoint state allows an xHC to reduce latency
when handling ERDYs and other USB asynchronous events. However holding
this state in xHC consumes resources and power. The xHCI spec designs
some methods through which host controller driver can hint xHC about
how to optimize its operation, e.g. to determine when it holds state
internally or pushes it out to memory, when to power down logic, etc.

When a USB device is going to suspend, states of all endpoints cached
in the xHC should be pushed out to memory to save power and resources.
Vice versa, when a USB device resumes, those states should be brought
back to the cache. USB core suspends or resumes a USB device by sending
set/clear port feature requests to the parent hub where the USB device
is connected. Unfortunately, these operations are transparent to xHCI
driver unless the USB device is plugged in a root port. This patch
utilizes the callback entries to notify xHCI driver whenever a USB
device suspends or resumes.

It is harmless if a USB devices under USB 3.0 host controller suspends
or resumes without a notification to hcd driver. However there may be
less opportunities for power savings and there may be increased latency
for restarting an endpoint. The precise impact will be different for
each xHC implementation. It all depends on what an implementation does
with the hints.

Signed-off-by: Lu Baolu 
---
 drivers/usb/core/hcd.c  | 29 +
 drivers/usb/core/hub.c  |  5 +
 include/linux/usb/hcd.h | 10 +-
 3 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 45a915c..a4cfc2d 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2289,6 +2289,35 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
 }
 EXPORT_SYMBOL_GPL(usb_hcd_resume_root_hub);
 
+/**
+ * hcd_suspend_notify - notify hcd driver when a device is going to suspend
+ * @udev: USB device to be suspended
+ * @msg: Power Management message describing this state transition
+ *
+ * Call back to hcd driver to notify that a USB device is going to suspend.
+ */
+void hcd_suspend_notify(struct usb_device *udev, pm_message_t msg)
+{
+   struct usb_hcd *hcd = bus_to_hcd(udev->bus);
+
+   if (hcd->driver->device_suspend)
+   hcd->driver->device_suspend(hcd, udev, msg);
+}
+
+/**
+ * hcd_resume_notify - notify hcd driver when a device is just resumed
+ * @udev: USB device just resumed
+ * @msg: Power Management message describing this state transition
+ *
+ * Call back to hcd driver to notify that a USB device is just resumed.
+ */
+void hcd_resume_notify(struct usb_device *udev, pm_message_t msg)
+{
+   struct usb_hcd *hcd = bus_to_hcd(udev->bus);
+
+   if (hcd->driver->device_resume)
+   hcd->driver->device_resume(hcd, udev, msg);
+}
 #endif /* CONFIG_PM */
 
 /*-*/
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3b71516..b3f0dc8 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3144,6 +3144,8 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
goto err_lpm3;
}
 
+   hcd_suspend_notify(udev, msg);
+
/* see 7.1.7.6 */
if (hub_is_superspeed(hub->hdev))
status = hub_set_port_link_state(hub, port1, USB_SS_PORT_LS_U3);
@@ -3169,6 +3171,8 @@ int usb_port_suspend(struct usb_device *udev, 
pm_message_t msg)
if (status) {
dev_dbg(_dev->dev, "can't suspend, status %d\n", status);
 
+   hcd_resume_notify(udev, msg);
+
/* Try to enable USB3 LPM and LTM again */
usb_unlocked_enable_lpm(udev);
  err_lpm3:
@@ -3422,6 +3426,7 @@ int usb_port_resume(struct usb_device *udev, pm_message_t 
msg)
}
 
  SuspendCleared:
+   hcd_resume_notify(udev, msg);
if (status == 0) {
udev->port_is_suspended = 0;
if (hub_is_superspeed(hub->hdev)) {
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 68b1e83..621d9b7 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -383,7 +383,13 @@ struct hc_driver {
int (*find_raw_port_number)(struct usb_hcd *, int);
/* Call for power on/off the port if necessary */
int (*port_power)(struct usb_hcd *hcd, int portnum, bool enable);
-
+   /* Call back to hcd when a USB device is going to suspend or just
+* resumed.
+*/
+   void(*device_suspend)(struct usb_hcd *, struct usb_device *udev,
+   pm_message_t msg);
+   void(*device_resume)(struct usb_hcd *, struct usb_device

Re: [PATCH v4 0/3] tracing: add trace event for memory-failure

2015-05-06 Thread Steven Rostedt

On Thu, 7 May 2015 01:12:07 +
Naoya Horiguchi  wrote:

> On Wed, Apr 29, 2015 at 07:14:27PM +0800, Xie XiuQi wrote:
> > Hi Naoya,
> > 
> > Could you help to review and applied this series if possible.
> 
> Sorry for late response, I was offline for several days due to national
> holidays.
> 
> This patchset is good to me, but I'm not sure which path it should go through.
> Ordinarily, memory-failure patches go to linux-mm, but patch 3 depends on
> TRACE_DEFINE_ENUM patches, so this can go to linux-next directly, or go to
> linux-mm with depending patches.
> 
> Steven, Andrew, which way do you like?
> 

The TRACE_DEFINE_ENUM() patch set went into the 4.1 merge window. It
should be fine to base off of any of Linus's tags after or including
4.1-rc1.

I need to start converting other trace events for 4.2.

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

Re: [PATCH 1/9] KVM: MMU: fix decoding cache type from MTRR

2015-05-06 Thread Xiao Guangrong




On 05/07/2015 05:42 AM, David Matlack wrote:

On Thu, Apr 30, 2015 at 3:24 AM,   wrote:

From: Xiao Guangrong 

There are some bugs in current get_mtrr_type();
1: bit 2 of mtrr_state->enabled is corresponding bit 11 of IA32_MTRR_DEF_TYPE


bit 1, not bit 2. (code is correct though)


Oh, i counted the bit from 1, my fault. :(




MSR which completely control MTRR's enablement that means other bits are
ignored if it is cleared

2: the fixed MTRR ranges are controlled by bit 1 of mtrr_state->enabled (bit 10


bit 0, not bit 1. (code is correct though)


Ditto. Will update the changelog in v2. Thank you for pointing it out.




of IA32_MTRR_DEF_TYPE)

3: if MTRR is disabled, UC is applied to all of physical memory rather than
mtrr_state->def_type


kvm_get_guest_memory_type defaults to MTRR_TYPE_WRBACK, not
mtrr_state->def_type, when get_mtrr_type returns 0xFF.



Yeah, that confused me. Based on the comment of vmx_get_mt_mask():
 *   a. VT-d without snooping control feature: can't guarantee the
 *  result, try to trust guest.
we need to completely follow guest's MTRR under this case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] brcmfmac: prohibit ACPI power management for brcmfmac driver

2015-05-06 Thread Fu, Zhonghui


Hi,

Any comments are welcome.


Thanks,
Zhonghui

On 2015/5/3 23:26, Fu, Zhonghui wrote:
> ACPI will manage WiFi chip's power state during suspend/resume
> process on some tablet platforms(such as ASUS T100TA). This is
> not supported by brcmfmac driver now, and the context of WiFi
> chip will be damaged after resume. This patch informs ACPI not
> to manage WiFi chip's power state.
>
> Signed-off-by: Zhonghui Fu 
> ---
> Changes in v2:
> - Another implementation.
>
>  drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c 
> b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> index 9b508bd..6c519e3 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -1114,6 +1115,8 @@ static int brcmf_ops_sdio_probe(struct sdio_func *func,
>   int err;
>   struct brcmf_sdio_dev *sdiodev;
>   struct brcmf_bus *bus_if;
> + struct device *dev;
> + struct acpi_device *adev;
>  
>   brcmf_dbg(SDIO, "Enter\n");
>   brcmf_dbg(SDIO, "Class=%x\n", func->class);
> @@ -1121,6 +1124,11 @@ static int brcmf_ops_sdio_probe(struct sdio_func *func,
>   brcmf_dbg(SDIO, "sdio device ID: 0x%04x\n", func->device);
>   brcmf_dbg(SDIO, "Function#: %d\n", func->num);
>  
> + /* prohibit ACPI power management for this device */
> + dev = >dev;
> + if (adev = ACPI_COMPANION(dev))
> + adev->flags.power_manageable = 0;
> +
>   /* Consume func num 1 but dont do anything with it. */
>   if (func->num == 1)
>   return 0;
> -- 1.7.1
>

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

RE: [v4 0/3] prerequisite changes for VT-d posted-interrupts

2015-05-06 Thread Wu, Feng

Hi Thomas,

Ping..

Since Liu Jiang's IRQ work has already been in the tip tree for a while, I think
It is time to send this series again based on the x86/apic branch of tip tree.
It would be very appreciated if you can have a look at this series!

Thanks,
Feng

> -Original Message-
> From: Wu, Feng
> Sent: Thursday, April 30, 2015 3:07 PM
> To: t...@linutronix.de; mi...@redhat.com; h...@zytor.com
> Cc: linux-kernel@vger.kernel.org; jiang@linux.intel.com; Wu, Feng
> Subject: [v4 0/3] prerequisite changes for VT-d posted-interrupts
> 
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
> 
> You can find the VT-d Posted-Interrtups Spec. in the following URL:
> http://www.intel.com/content/www/us/en/intelligent-systems/intel-technolog
> y/vt-directed-io-spec.html
> 
> This series implement some prerequisite parts for VT-d posted-interrupts. It
> was part of
> http://thread.gmane.org/gmane.linux.kernel.iommu/7708. To make things
> clear, I will divide
> the whole series which contain multiple components into three parts:
> - prerequisite changes (included in this series)
> - IOMMU part (v4 was reviewed, some comments need to be addressed)
> - KVM and VFIO parts (will send out this part once the first two parts are
> accepted)
> 
> This series is rebased on the x86-apic branch of tip tree.
> 
> Feng Wu (3):
>   genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a
> VCPU
>   x86, irq: Implement irq_set_vcpu_affinity for pci_msi_ir_controller
>   x86, irq: Define a global vector for VT-d Posted-Interrupts
> 
>  arch/x86/include/asm/entry_arch.h  |  2 ++
>  arch/x86/include/asm/hardirq.h |  1 +
>  arch/x86/include/asm/hw_irq.h  |  2 ++
>  arch/x86/include/asm/irq_vectors.h |  1 +
>  arch/x86/kernel/apic/msi.c |  1 +
>  arch/x86/kernel/entry_64.S |  2 ++
>  arch/x86/kernel/irq.c  | 27 +++
>  arch/x86/kernel/irqinit.c  |  2 ++
>  include/linux/irq.h|  6 ++
>  kernel/irq/chip.c  | 14 ++
>  kernel/irq/manage.c| 20 
>  11 files changed, 78 insertions(+)
> 
> --
> 2.1.0

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

linux-next: manual merge of the vfs tree with the f2fs tree

2015-05-06 Thread Stephen Rothwell

Hi Al,

Today's linux-next merge of the vfs tree got a conflict in
fs/f2fs/namei.c between commit 04002bddf33a ("f2fs: fix wrong error hanlder in 
f2fs_follow_link") from the f2fs tree and commits
32a09a012611 ("new ->follow_link() and ->put_link() calling
conventions") and e1a9e9dd8594 ("don't pass nameidata to
->follow_link()") from the vfs tree.

I fixed it up (the vfs tree changes are a superset of the f2fs tree
changes, so I just used them) and can carry the fix as necessary (no
action is required).

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


pgpEptPQLKICm.pgp
Description: OpenPGP digital signature

Re: [PATCH 8/9] KVM: MMU: fix MTRR update

2015-05-06 Thread Xiao Guangrong



Hi David,

Thanks for your review.

On 05/07/2015 05:36 AM, David Matlack wrote:


+static void vmx_set_msr_mtrr(struct kvm_vcpu *vcpu, u32 msr)
+{
+   struct mtrr_state_type *mtrr_state = >arch.mtrr_state;
+   unsigned char mtrr_enabled = mtrr_state->enabled;
+   gfn_t start, end, mask;
+   int index;
+   bool is_fixed = true;
+
+   if (msr == MSR_IA32_CR_PAT || !enable_ept ||
+ !kvm_arch_has_noncoherent_dma(vcpu->kvm))
+   return;
+
+   if (!(mtrr_enabled & 0x2) && msr != MSR_MTRRdefType)
+   return;
+
+   switch (msr) {
+   case MSR_MTRRfix64K_0:
+   start = 0x0;
+   end = 0x8;
+   break;
+   case MSR_MTRRfix16K_8:
+   start = 0x8;
+   end = 0xa;
+   break;
+   case MSR_MTRRfix16K_A:
+   start = 0xa;
+   end = 0xc;
+   break;
+   case MSR_MTRRfix4K_C ... MSR_MTRRfix4K_F8000:
+   index = msr - MSR_MTRRfix4K_C;
+   start = 0xc + index * (32 << 10);
+   end = start + (32 << 10);
+   break;
+   case MSR_MTRRdefType:
+   is_fixed = false;
+   start = 0x0;
+   end = ~0ULL;
+   break;
+   default:
+   /* variable range MTRRs. */
+   is_fixed = false;
+   index = (msr - 0x200) / 2;
+   start = (((u64)mtrr_state->var_ranges[index].base_hi) << 32) +
+  (mtrr_state->var_ranges[index].base_lo & PAGE_MASK);
+   mask = (((u64)mtrr_state->var_ranges[index].mask_hi) << 32) +
+  (mtrr_state->var_ranges[index].mask_lo & PAGE_MASK);
+   mask |= ~0ULL << cpuid_maxphyaddr(vcpu);
+
+   end = ((start & mask) | ~mask) + 1;
+   }
+
+   if (is_fixed && !(mtrr_enabled & 0x1))
+   return;


For variable range MTRRs, I think you want to break out here if the valid flag
(bit 11 of the mask MTRR) is not set.


We should update these MTRRs whenever the valid bit is changed. If here we see
valid bit is zero, guest is disabling MTRR for that range so that we need to
drop cache type for that range we previously set.

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

Re: [PATCH 1/1] mfd: max77686: Remove unused struct max77686_opmode_data

2015-05-06 Thread Chanwoo Choi

On 05/07/2015 02:07 AM, Javier Martinez Canillas wrote:
> The defined struct max77686_opmode_data isn't used neither by
> the max77686 mfd driver nor the drivers for its sub-devices.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
>  include/linux/mfd/max77686.h | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/include/linux/mfd/max77686.h b/include/linux/mfd/max77686.h
> index bb995ab9a575..d4b72d519115 100644
> --- a/include/linux/mfd/max77686.h
> +++ b/include/linux/mfd/max77686.h
> @@ -125,9 +125,4 @@ enum max77686_opmode {
>   MAX77686_OPMODE_STANDBY,
>  };
>  
> -struct max77686_opmode_data {
> - int id;
> - int mode;
> -};
> -
>  #endif /* __LINUX_MFD_MAX77686_H */
> 

Reviewed-by: Chanwoo Choi 

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

Re: [RFC V2] init: support device of major:minor:offset format

2015-05-06 Thread Yu Chen


Hi, Geert

On 05/07/2015 12:49 AM, Geert Uytterhoeven wrote:

On Wed, May 6, 2015 at 2:24 AM, Chen Yu  wrote:

Distribution like Ubuntu uses klibc rather than uswsusp to resume
system from hibernation, which will treat swap partition/file in
the form of major:minor:offset. For example, 8:3:0 represents a
swap partition in klibc, and klibc's resume process in initrd will
finally echo 8:3:0 to /sys/power/resume for manually restoring.
However in current implementation, 8:3:0 will be treated as an invalid


Why can't klibc write the same information as uswsusp?

I agree. However it seems that klibc treats all device/file as such
fixed format when dealing with hibernation, I guess that might be
easier for it to implement?


Why should the kernel adapt to a specific piece of userspace?


device format, and it is found that manual resumming from hibernation
will fail on lastest kernel.


Is this a regression, perhaps introduced by commit 283e7ad024115571
("init: stricter checking of major:minor root= values")? If that is the case,
please say so.


yes, it is. I think there's a modified patch for it at:

https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next=cb31ef485dd4c6a205d1064b42027f82076d00c8


Thanks

Best Regards,
Yu


Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds



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

Re: [PATCH] x86: skip delays during SMP initialization similar to Xen

2015-05-06 Thread Len Brown

> So I really like this, as it nicely side-steps the 'when should we do
> the legacy delays' issue by flagging on x2apic support.
>
> If anyone has objections, please holler.

We should have no delays even for many processors that lack x2apic.

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

[PATCH] clk: Add some more lockdep assertions

2015-05-06 Thread Stephen Boyd

We don't check to make sure the enable_lock is held across
enable/disable and we don't check if the prepare_lock is held
across prepare/unprepare. Add some asserts to catch any future
locking problems.

Signed-off-by: Stephen Boyd 
---

Based on clk-next

 drivers/clk/clk.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8cea0ec7179b..bbc04eae3b92 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -544,6 +544,8 @@ EXPORT_SYMBOL_GPL(__clk_mux_determine_rate_closest);
 
 static void clk_core_unprepare(struct clk_core *core)
 {
+   lockdep_assert_held(_lock);
+
if (!core)
return;
 
@@ -590,6 +592,8 @@ static int clk_core_prepare(struct clk_core *core)
 {
int ret = 0;
 
+   lockdep_assert_held(_lock);
+
if (!core)
return 0;
 
@@ -645,6 +649,8 @@ EXPORT_SYMBOL_GPL(clk_prepare);
 
 static void clk_core_disable(struct clk_core *core)
 {
+   lockdep_assert_held(_lock);
+
if (!core)
return;
 
@@ -693,6 +699,8 @@ static int clk_core_enable(struct clk_core *core)
 {
int ret = 0;
 
+   lockdep_assert_held(_lock);
+
if (!core)
return 0;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

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

2015-05-06 Thread Stephen Rothwell

Hi Ted,

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

fs/ext4/file.c: In function 'ext4_file_mmap':
fs/ext4/file.c:226:3: error: implicit declaration of function 
'ext4_get_encryption_info' [-Werror=implicit-function-declaration]
   int err = ext4_get_encryption_info(inode);
   ^
fs/ext4/super.c: In function 'ext4_clear_inode':
fs/ext4/super.c:958:19: error: 'struct ext4_inode_info' has no member named 
'i_crypt_info'
  if (EXT4_I(inode)->i_crypt_info)
   ^

Caused by commit ef8a5d07c606 ("ext4 crypto: reorganize how we store
keys in the inode").  This build has CONFIG_EXT4_FS_ENCRYPTION not set.

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


pgpWucntqaR76.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 2/3] memory-failure: change type of action_result's param 3 to enum

2015-05-06 Thread Naoya Horiguchi

On Mon, Apr 20, 2015 at 04:44:39PM +0800, Xie XiuQi wrote:
> Change type of action_result's param 3 to enum for type consistency,
> and rename mf_outcome to mf_result for clearly.
> 
> Signed-off-by: Xie XiuQi 

Acked-by: Naoya Horiguchi 

> ---
>  include/linux/mm.h  | 2 +-
>  mm/memory-failure.c | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8413615..93c4a00 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2156,7 +2156,7 @@ extern int soft_offline_page(struct page *page, int 
> flags);
>  /*
>   * Error handlers for various types of pages.
>   */
> -enum mf_outcome {
> +enum mf_result {
>   MF_IGNORED, /* Error: cannot be handled */
>   MF_FAILED,  /* Error: handling failed */
>   MF_DELAYED, /* Will be handled later */
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 6f5748d..f074f8e 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -847,7 +847,8 @@ static struct page_state {
>   * "Dirty/Clean" indication is not 100% accurate due to the possibility of
>   * setting PG_dirty outside page lock. See also comment above 
> set_page_dirty().
>   */
> -static void action_result(unsigned long pfn, enum mf_action_page_type type, 
> int result)
> +static void action_result(unsigned long pfn, enum mf_action_page_type type,
> +   enum mf_result result)
>  {
>   pr_err("MCE %#lx: recovery action for %s: %s\n",
>   pfn, action_page_types[type], action_name[result]);
> -- 
> 1.8.3.1
> --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/3] memory-failure: export page_type and action result

2015-05-06 Thread Naoya Horiguchi

On Mon, Apr 20, 2015 at 04:44:38PM +0800, Xie XiuQi wrote:
> Export 'outcome' and 'action_page_type' to mm.h, so we could use
> this enums outside.
> 
> This patch is preparation for adding trace events for memory-failure
> recovery action.
> 
> Signed-off-by: Xie XiuQi 

Acked-by: Naoya Horiguchi 

> ---
>  include/linux/mm.h  |  34 +++
>  mm/memory-failure.c | 168 
> +---
>  2 files changed, 101 insertions(+), 101 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8b08607..8413615 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2152,6 +2152,40 @@ extern void shake_page(struct page *p, int access);
>  extern atomic_long_t num_poisoned_pages;
>  extern int soft_offline_page(struct page *page, int flags);
>  
> +
> +/*
> + * Error handlers for various types of pages.
> + */
> +enum mf_outcome {
> + MF_IGNORED, /* Error: cannot be handled */
> + MF_FAILED,  /* Error: handling failed */
> + MF_DELAYED, /* Will be handled later */
> + MF_RECOVERED,   /* Successfully recovered */
> +};
> +
> +enum mf_action_page_type {
> + MF_MSG_KERNEL,
> + MF_MSG_KERNEL_HIGH_ORDER,
> + MF_MSG_SLAB,
> + MF_MSG_DIFFERENT_COMPOUND,
> + MF_MSG_POISONED_HUGE,
> + MF_MSG_HUGE,
> + MF_MSG_FREE_HUGE,
> + MF_MSG_UNMAP_FAILED,
> + MF_MSG_DIRTY_SWAPCACHE,
> + MF_MSG_CLEAN_SWAPCACHE,
> + MF_MSG_DIRTY_MLOCKED_LRU,
> + MF_MSG_CLEAN_MLOCKED_LRU,
> + MF_MSG_DIRTY_UNEVICTABLE_LRU,
> + MF_MSG_CLEAN_UNEVICTABLE_LRU,
> + MF_MSG_DIRTY_LRU,
> + MF_MSG_CLEAN_LRU,
> + MF_MSG_TRUNCATED_LRU,
> + MF_MSG_BUDDY,
> + MF_MSG_BUDDY_2ND,
> + MF_MSG_UNKNOWN,
> +};
> +
>  #if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLBFS)
>  extern void clear_huge_page(struct page *page,
>   unsigned long addr,
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index d9359b7..6f5748d 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -503,68 +503,34 @@ static void collect_procs(struct page *page, struct 
> list_head *tokill,
>   kfree(tk);
>  }
>  
> -/*
> - * Error handlers for various types of pages.
> - */
> -
> -enum outcome {
> - IGNORED,/* Error: cannot be handled */
> - FAILED, /* Error: handling failed */
> - DELAYED,/* Will be handled later */
> - RECOVERED,  /* Successfully recovered */
> -};
> -
>  static const char *action_name[] = {
> - [IGNORED] = "Ignored",
> - [FAILED] = "Failed",
> - [DELAYED] = "Delayed",
> - [RECOVERED] = "Recovered",
> -};
> -
> -enum action_page_type {
> - MSG_KERNEL,
> - MSG_KERNEL_HIGH_ORDER,
> - MSG_SLAB,
> - MSG_DIFFERENT_COMPOUND,
> - MSG_POISONED_HUGE,
> - MSG_HUGE,
> - MSG_FREE_HUGE,
> - MSG_UNMAP_FAILED,
> - MSG_DIRTY_SWAPCACHE,
> - MSG_CLEAN_SWAPCACHE,
> - MSG_DIRTY_MLOCKED_LRU,
> - MSG_CLEAN_MLOCKED_LRU,
> - MSG_DIRTY_UNEVICTABLE_LRU,
> - MSG_CLEAN_UNEVICTABLE_LRU,
> - MSG_DIRTY_LRU,
> - MSG_CLEAN_LRU,
> - MSG_TRUNCATED_LRU,
> - MSG_BUDDY,
> - MSG_BUDDY_2ND,
> - MSG_UNKNOWN,
> + [MF_IGNORED] = "Ignored",
> + [MF_FAILED] = "Failed",
> + [MF_DELAYED] = "Delayed",
> + [MF_RECOVERED] = "Recovered",
>  };
>  
>  static const char * const action_page_types[] = {
> - [MSG_KERNEL]= "reserved kernel page",
> - [MSG_KERNEL_HIGH_ORDER] = "high-order kernel page",
> - [MSG_SLAB]  = "kernel slab page",
> - [MSG_DIFFERENT_COMPOUND]= "different compound page after 
> locking",
> - [MSG_POISONED_HUGE] = "huge page already hardware poisoned",
> - [MSG_HUGE]  = "huge page",
> - [MSG_FREE_HUGE] = "free huge page",
> - [MSG_UNMAP_FAILED]  = "unmapping failed page",
> - [MSG_DIRTY_SWAPCACHE]   = "dirty swapcache page",
> - [MSG_CLEAN_SWAPCACHE]   = "clean swapcache page",
> - [MSG_DIRTY_MLOCKED_LRU] = "dirty mlocked LRU page",
> - [MSG_CLEAN_MLOCKED_LRU] = "clean mlocked LRU page",
> - [MSG_DIRTY_UNEVICTABLE_LRU] = "dirty unevictable LRU page",
> - [MSG_CLEAN_UNEVICTABLE_LRU] = "clean unevictable LRU page",
> - [MSG_DIRTY_LRU] = "dirty LRU page",
> - [MSG_CLEAN_LRU] = "clean LRU page",
> - [MSG_TRUNCATED_LRU] = "already truncated LRU page",
> - [MSG_BUDDY] = "free buddy page",
> - [MSG_BUDDY_2ND] = "free buddy page (2nd try)",
> - [MSG_UNKNOWN]   = "unknown page",
> + [MF_MSG_KERNEL] = "reserved kernel page",
> + [MF_MSG_KERNEL_HIGH_ORDER]  = "high-order kernel page",
> + [MF_MSG_SLAB]   = "kernel slab page",
> + [MF_MSG_DIFFERENT_COMPOUND]

Re: [PATCH v4 3/3] tracing: add trace event for memory-failure

2015-05-06 Thread Naoya Horiguchi

On Mon, Apr 20, 2015 at 04:44:40PM +0800, Xie XiuQi wrote:
> RAS user space tools like rasdaemon which base on trace event, could
> receive mce error event, but no memory recovery result event. So, I
> want to add this event to make this scenario complete.
> 
> This patch add a event at ras group for memory-failure.
> 
> The output like below:
> #  tracer: nop
> #
> #  entries-in-buffer/entries-written: 2/2   #P:24
> #
> #   _-=> irqs-off
> #  / _=> need-resched
> # | / _---=> hardirq/softirq
> # || / _--=> preempt-depth
> # ||| / delay
> #TASK-PID   CPU#  TIMESTAMP  FUNCTION
> #   | |   |      | |
>mce-inject-13150 [001]    277.019359: memory_failure_event: pfn 
> 0x19869: recovery action for free buddy page: Delayed
> 
> Cc: Tony Luck 
> Cc: Steven Rostedt 
> Signed-off-by: Xie XiuQi 

Reviewed-by: Naoya Horiguchi 

> ---
>  include/ras/ras_event.h | 85 
> +
>  mm/memory-failure.c |  3 ++
>  2 files changed, 88 insertions(+)
> 
> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
> index 79abb9c..258ed89 100644
> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * MCE Extended Error Log trace event
> @@ -232,6 +233,90 @@ TRACE_EVENT(aer_event,
>   __print_flags(__entry->status, "|", aer_uncorrectable_errors))
>  );
>  
> +/*
> + * memory-failure recovery action result event
> + *
> + * unsigned long pfn -   Page Frame Number of the corrupted page
> + * int type  -   Page types of the corrupted page
> + * int result-   Result of recovery action
> + */
> +
> +#ifdef CONFIG_MEMORY_FAILURE
> +#define MF_ACTION_RESULT \
> + EM ( MF_IGNORED, "Ignord" ) \
> + EM ( MF_FAILED,  "Failed" ) \
> + EM ( MF_DELAYED, "Delayed" )\
> + EMe ( MF_RECOVERED, "Recovered" )
> +
> +#define MF_PAGE_TYPE \
> + EM ( MF_MSG_KERNEL, "reserved kernel page" )\
> + EM ( MF_MSG_KERNEL_HIGH_ORDER, "high-order kernel page" )   \
> + EM ( MF_MSG_SLAB, "kernel slab page" )  \
> + EM ( MF_MSG_DIFFERENT_COMPOUND, "different compound page after locking" 
> ) \
> + EM ( MF_MSG_POISONED_HUGE, "huge page already hardware poisoned" )  
> \
> + EM ( MF_MSG_HUGE, "huge page" ) \
> + EM ( MF_MSG_FREE_HUGE, "free huge page" )   \
> + EM ( MF_MSG_UNMAP_FAILED, "unmapping failed page" ) \
> + EM ( MF_MSG_DIRTY_SWAPCACHE, "dirty swapcache page" )   \
> + EM ( MF_MSG_CLEAN_SWAPCACHE, "clean swapcache page" )   \
> + EM ( MF_MSG_DIRTY_MLOCKED_LRU, "dirty mlocked LRU page" )   \
> + EM ( MF_MSG_CLEAN_MLOCKED_LRU, "clean mlocked LRU page" )   \
> + EM ( MF_MSG_DIRTY_UNEVICTABLE_LRU, "dirty unevictable LRU page" )   
> \
> + EM ( MF_MSG_CLEAN_UNEVICTABLE_LRU, "clean unevictable LRU page" )   
> \
> + EM ( MF_MSG_DIRTY_LRU, "dirty LRU page" )   \
> + EM ( MF_MSG_CLEAN_LRU, "clean LRU page" )   \
> + EM ( MF_MSG_TRUNCATED_LRU, "already truncated LRU page" )   \
> + EM ( MF_MSG_BUDDY, "free buddy page" )  \
> + EM ( MF_MSG_BUDDY_2ND, "free buddy page (2nd try)" )\
> + EMe ( MF_MSG_UNKNOWN, "unknown page" )
> +
> +/*
> + * First define the enums in MM_ACTION_RESULT to be exported to userspace
> + * via TRACE_DEFINE_ENUM().
> + */
> +#undef EM
> +#undef EMe
> +#define EM(a,b) TRACE_DEFINE_ENUM(a);
> +#define EMe(a,b) TRACE_DEFINE_ENUM(a);
> +
> +MF_ACTION_RESULT
> +MF_PAGE_TYPE
> +
> +/*
> + * Now redefine the EM() and EMe() macros to map the enums to the strings
> + * that will be printed in the output.
> + */
> +#undef EM
> +#undef EMe
> +#define EM(a,b)  { a, b },
> +#define EMe(a,b) { a, b }
> +
> +TRACE_EVENT(memory_failure_event,
> + TP_PROTO(unsigned long pfn,
> +  int type,
> +  int result),
> +
> + TP_ARGS(pfn, type, result),
> +
> + TP_STRUCT__entry(
> + __field(unsigned long, pfn)
> + __field(int, type)
> + __field(int, result)
> + ),
> +
> + TP_fast_assign(
> + __entry->pfn= pfn;
> + __entry->type   = type;
> + __entry->result = result;
> + ),
> +
> + TP_printk("pfn %#lx: recovery action for %s: %s",
> + __entry->pfn,
> + __print_symbolic(__entry->type, MF_PAGE_TYPE),
> + __print_symbolic(__entry->result, MF_ACTION_RESULT)
> + )
> +);
> +#endif /* CONFIG_MEMORY_FAILURE */
>  #endif /* _TRACE_HW_EVENT_MC_H */
>  
>  /* This

Re: [PATCH v4 0/3] tracing: add trace event for memory-failure

2015-05-06 Thread Naoya Horiguchi

On Wed, Apr 29, 2015 at 07:14:27PM +0800, Xie XiuQi wrote:
> Hi Naoya,
> 
> Could you help to review and applied this series if possible.

Sorry for late response, I was offline for several days due to national
holidays.

This patchset is good to me, but I'm not sure which path it should go through.
Ordinarily, memory-failure patches go to linux-mm, but patch 3 depends on
TRACE_DEFINE_ENUM patches, so this can go to linux-next directly, or go to
linux-mm with depending patches.

Steven, Andrew, which way do you like?

Thanks,
Naoya Horiguchi

> Thanks,
> Xie XiuQi
> 
> On 2015/4/20 16:44, Xie XiuQi wrote:
> > RAS user space tools like rasdaemon which base on trace event, could
> > receive mce error event, but no memory recovery result event. So, I
> > want to add this event to make this scenario complete.
> > 
> > This patchset add a event at ras group for memory-failure.
> > 
> > The output like below:
> > #  tracer: nop
> > #
> > #  entries-in-buffer/entries-written: 2/2   #P:24
> > #
> > #   _-=> irqs-off
> > #  / _=> need-resched
> > # | / _---=> hardirq/softirq
> > # || / _--=> preempt-depth
> > # ||| / delay
> > #TASK-PID   CPU#  TIMESTAMP  FUNCTION
> > #   | |   |      | |
> >mce-inject-13150 [001]    277.019359: memory_failure_event: pfn 
> > 0x19869: recovery action for free buddy page: Delayed
> > 
> > --
> > v3->v4:
> >  - rebase on top of latest linux-next
> >  - update comments as Naoya's suggestion
> >  - add #ifdef CONFIG_MEMORY_FAILURE for this trace event
> >  - change type of action_result's param 3 to enum
> > 
> > v2->v3:
> >  - rebase on top of linux-next
> >  - based on Steven Rostedt's "tracing: Add TRACE_DEFINE_ENUM() macro
> >to map enums to their values" patch set v1.
> > 
> > v1->v2:
> >  - Comment update
> >  - Just passing 'result' instead of 'action_name[result]',
> >suggested by Steve. And hard coded there because trace-cmd
> >and perf do not have a way to process enums.
> > 
> > Xie XiuQi (3):
> >   memory-failure: export page_type and action result
> >   memory-failure: change type of action_result's param 3 to enum
> >   tracing: add trace event for memory-failure
> > 
> >  include/linux/mm.h  |  34 ++
> >  include/ras/ras_event.h |  85 
> >  mm/memory-failure.c | 172 
> > 
> >  3 files changed, 190 insertions(+), 101 deletions(-)
> > 
> 
> --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1934 matches

Mail list logo