Re: [PATCH] psmouse - focaltech report finger width to userspace

[Dmitry Tunin]

30.05.2015 02:37, Dmitry Torokhov пишет:
> On Sat, May 30, 2015 at 02:00:59AM +0300, Dmitry Tunin wrote:
>> Focaltech touchpads report finger width in packet[5] of absolute packet.
>> Range for width in raw format is 0x10 - 0x70. Second half-byte is always 0.
>> 0xff is reported, when a large contact area is detected.
>> This can be handled in userspace.
>>
>> Signed-off-by: Dmitry Tunin 
> 
> Let's add a few people...
> 
>> ---
>>  drivers/input/mouse/focaltech.c | 20 +---
>>  1 file changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/input/mouse/focaltech.c 
>> b/drivers/input/mouse/focaltech.c
>> index 23d2594..0c3b698 100644
>> --- a/drivers/input/mouse/focaltech.c
>> +++ b/drivers/input/mouse/focaltech.c
>> @@ -105,6 +105,16 @@ struct focaltech_hw_state {
>>  
>>  /* True if the clickpad has been pressed. */
>>  bool pressed;
>> +
>> +/*
>> +* Finger width 0-7 and 15 for a very big contact area.
>> +* 15 value stays until the finger is released.
>> +* Width is reported only in absolute packets.
>> +* Since hardware reports width only for last touching finger,
>> +* there is no need to store width for every specific finger, so 
>> +* we keep only last value reported.
>> +*/
>> +unsigned int width;
>>  };
>>  
>>  struct focaltech_data {
>> @@ -112,7 +122,7 @@ struct focaltech_data {
>>  struct focaltech_hw_state state;
>>  };
>>  
>> -static void focaltech_report_state(struct psmouse *psmouse)
>> +static void focaltech_report_state(struct psmouse *psmouse, bool abs)
>>  {
>>  struct focaltech_data *priv = psmouse->private;
>>  struct focaltech_hw_state *state = >state;
>> @@ -137,6 +147,7 @@ static void focaltech_report_state(struct psmouse 
>> *psmouse)
>>  input_report_abs(dev, ABS_MT_POSITION_X, clamped_x);
>>  input_report_abs(dev, ABS_MT_POSITION_Y,
>>   priv->y_max - clamped_y);
>> +if (abs) input_report_abs(dev, ABS_TOOL_WIDTH, 
>> state->width);
> 
> I am not sure this condition and the change in focaltech_process_packet
> are needed. The relative packets augment absolute one and we expect
> width not change so we can always report state->width (either updated or
> cached) and input core will drop dupes.

That's what I started from. Just added a report line. But this confused user 
space.
A touch packet reporting that a finger does not touch the pad together with 
width reported for same finger gets xorg-synaptics to ignore it.
E.g two-finger scrolling becomes unusable. xorg ignores "untouch" event and 
when fingers touch again, cursor jumps.

So finally this solution looks clean and safe to report width only with abs.

I sent some versions of these to linux-input mailing list and to Mathias, but 
forgot to add Dmitry.

I added a similar patch to my ppa, with backport of focaltech driver for Ubuntu 
3.19 kernel users. There are >500 installs. 
No issues reported.


> 
>>  }
>>  }
>>  input_mt_report_pointer_emulation(dev, true);
>> @@ -187,6 +198,7 @@ static void focaltech_process_abs_packet(struct psmouse 
>> *psmouse,
>>  
>>  state->fingers[finger].x = ((packet[1] & 0xf) << 8) | packet[2];
>>  state->fingers[finger].y = (packet[3] << 8) | packet[4];
>> +state->width = packet[5] >> 4;
>>  state->fingers[finger].valid = true;
>>  }
>>  
>> @@ -228,22 +240,23 @@ static void focaltech_process_packet(struct psmouse 
>> *psmouse)
>>  switch (packet[0] & 0xf) {
>>  case FOC_TOUCH:
>>  focaltech_process_touch_packet(psmouse, packet);
>> +focaltech_report_state(psmouse, false);
>>  break;
>>  
>>  case FOC_ABS:
>>  focaltech_process_abs_packet(psmouse, packet);
>> +focaltech_report_state(psmouse, true);
>>  break;
>>  
>>  case FOC_REL:
>>  focaltech_process_rel_packet(psmouse, packet);
>> +focaltech_report_state(psmouse, false);
>>  break;
>>  
>>  default:
>>  psmouse_err(psmouse, "Unknown packet type: %02x\n", packet[0]);
>>  break;
>>  }
>> -
>> -focaltech_report_state(psmouse);
>>  }
>>  
>>  static psmouse_ret_t focaltech_process_byte(struct psmouse *psmouse)
>> @@ -331,6 +344,7 @@ static void focaltech_set_input_params(struct psmouse 
>> *psmouse)
>>  __set_bit(EV_ABS, dev->evbit);
>>  input_set_abs_params(dev, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0);
>>  input_set_abs_params(dev, ABS_MT_POSITION_Y, 0, priv->y_max, 0, 0);
>> +input_set_abs_params(dev, ABS_TOOL_WIDTH, 0, 15, 0, 0);
>>  input_mt_init_slots(dev, 5, INPUT_MT_POINTER);
>>  __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
>>  }
>> -- 
>> 1.9.1
>>
> 
> 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  

Re: [PATCH 04/10] perf, tools: Handle header line in mapfile

[Andi Kleen]

On Fri, May 29, 2015 at 11:13:15AM +0200, Jiri Olsa wrote:
> On Thu, May 28, 2015 at 10:45:06PM -0700, Sukadev Bhattiprolu wrote:
> > Jiri Olsa [jo...@redhat.com] wrote:
> > | > if (line[0] == '#' || line[0] == '\n')
> > | > continue;
> > | > +   if (!strncmp(line, "Family", 6))
> > | > +   continue;
> > | 
> > | I think we should fix mapfiles to put the 'Family' starting
> > | line as a comment.. the way powerpc mapfile is done
> > 
> > You mean add something like this to the Intel mapfile:
> > 
> > # Power8 entries
> > 004d0100,1,power8.json,core
> > 
> > and drop this patch?
> 
> right

But it's a CSV file. CSV files are supposed to have column headers.
There are lots of tools that work better with them if they have headers.
Please keep the header.

-Andi

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

Re: [PATCH 1/4]:Add mbigen driver to support mbigen interrupt controller

[Joe Perches]

On Sat, 2015-05-30 at 11:19 +0800, majun (F) wrote:
> This patch contains the mbigen device driver.

Trivial notes:

Please use scripts/checkpatch.pl on your patches and see
if you want to correct any of the messages it produces.

> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c

You could add
#define pr_fmt(fmt) "mbigen: " fmt
before any of the #includes so that all of the
pr_(fmt, ...) uses are prefixed with "mbigen: "

> +int mbi_parse_irqs(struct device *dev, struct mbi_ops *ops)
> +{
> + pr_warn("%s:this function not use now\n", __func__);

Maybe pr_warn_once()

> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(mbi_parse_irqs);
> +
> +void mbi_free_irqs(struct device *dev, unsigned int virq, unsigned int nvec)
> +{
> + pr_warn("%s:this function not use now\n", __func__);

pr_warn_once()?

> +static struct mbigen *mbigen_get_device(struct mbigen_chip *chip,
> + 
> unsigned int nid)
> +{
> + struct mbigen *tmp, *mbigen;
> + bool found = false;
> +
> + if (nid >= MG_NR) {
> + pr_warn("MBIGEN: Device ID exceeds max number!\n");

So this wouldn't need a "MBIGEN: " prefix

etc...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4.1.0-rc4] STAGING: Delare request_cache as static for drivers/staging/lustre/lustre/ptlrpc/client.c

[Sudip Mukherjee]

On Wed, May 27, 2015 at 05:05:26PM +0800, Simon Guo wrote:
> Delare request_cache variable as static.

Is it Declare?

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/

[GIT PULL] ARM: EXYNOS: Improvements for 4.2, 3rd

[Krzysztof Kozlowski]

Dear Kukjin,

Old patch from Marek related to powering down of Exynos boards.

Best regards,
Krzysztof


The following changes since commit 8164b91ee8f4bb009fb16ef7c54e94a55e83dd35:

  ARM: exynos: Fix wake-up interrupts for Exynos3250 (2015-05-30 13:29:34 +0900)

are available in the git repository at:

  https://github.com/krzk/linux.git tags/samsung-for-4.2-3

for you to fetch changes up to 126bdccac56b97449a603133a2d389d280630d9a:

  exynos: pmu: use PS_HOLD based poweroff for all supported SoCs (2015-05-30 
13:30:17 +0900)


Old fix for proper power down of Exynos boards.


Marek Szyprowski (1):
  exynos: pmu: use PS_HOLD based poweroff for all supported SoCs

 arch/arm/mach-exynos/pmu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 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/

[GIT PULL] ARM: EXYNOS: Fix for 4.1, 3rd

[Krzysztof Kozlowski]

Dear Kukjin,

Fix from April which you said it is applied. Apparently it was not,
so here it is again.

Best regards,
Krzysztof


The following changes since commit 5c78bc1b466701c1b13d7b734f5b39cdd65babab:

  Merge branch 'samsung-defconfig-2nd' into for-next (2015-05-23 12:28:59 +0900)

are available in the git repository at:

  https://github.com/krzk/linux.git tags/samsung-fixes-4.1-3

for you to fetch changes up to 8164b91ee8f4bb009fb16ef7c54e94a55e83dd35:

  ARM: exynos: Fix wake-up interrupts for Exynos3250 (2015-05-30 13:29:34 +0900)


Fix for Exynos3250 wake-up interrupts after converting PMU
wakeup to stacked domains. This slipped through fingers some
time ago.


Marc Zyngier (1):
  ARM: exynos: Fix wake-up interrupts for Exynos3250

 arch/arm/mach-exynos/suspend.c | 4 ++--
 1 file changed, 2 insertions(+), 2 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/

Re: [PATCH 0/4] Cover: Support mbigen msi interrupt controller

[Joe Perches]

On Sat, 2015-05-30 at 11:19 +0800, majun (F) wrote:
> This patch set is applied to supprot the mbigen device.
[]
>  create mode 100755 Documentation/devicetree/bindings/arm/mbigen.txt
>  mode change 100644 => 100755 drivers/irqchip/Kconfig
>  mode change 100644 => 100755 drivers/irqchip/Makefile
>  mode change 100644 => 100755 drivers/irqchip/irq-gic-v3-its.c
>  create mode 100755 drivers/irqchip/irq-mbigen.c
>  create mode 100755 include/linux/irqchip/arm-gic-its.h
>  create mode 100644 include/linux/mbi.h
>  mode change 100644 => 100755 include/linux/msi.h
>  mode change 100644 => 100755 kernel/irq/msi.c

None of these should be executable

All of them should be 644

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

[GIT PULL] ARM: EXYNOS: DTS improvements for 4.2, 3rd

[Krzysztof Kozlowski]

Dear Kukjin,

Quite big set of changes, mostly refactor.

You can find them also on the lists with my reviewed-by.

Best regards,
Krzysztof


The following changes since commit 5c78bc1b466701c1b13d7b734f5b39cdd65babab:

  Merge branch 'samsung-defconfig-2nd' into for-next (2015-05-23 12:28:59 +0900)

are available in the git repository at:

  https://github.com/krzk/linux.git tags/samsung-dt-for-4.2-3

for you to fetch changes up to a33a220172cd832fd4b9f8c26f4e6053899d68c4:

  ARM: dts: Add Odroid XU3 Lite support (2015-05-30 13:22:45 +0900)


Device Tree improvements for Exynos based boards:
1. Refactor DT sources to label notation. All new Exynos boards follow
   this convention so only old DTS are changed: Exynos4 family, Exynos5
   and s3c2416.
   This convention reduces duplication of addresses in nodes
   and reduces possible mistakes when overriding nodes.
2. Switch LEDs on Odroid XU3 to PWM control.
3. Add nodes for JPEG codec on Exynos542x.
4. Enable wake alarm on Odroid XU3.
5. Add support for new board: Odroid XU3 Lite. The board is actually
   very similar to existing Odroid XU3.


Andrzej Pietrasiewicz (1):
  ARM: dts: exynos5420: add nodes for jpeg codec

Krzysztof Kozlowski (26):
  ARM: dts: Add labels to exynos4 nodes
  ARM: dts: Use labels for overriding nodes in exynos4210
  ARM: dts: Use labels for overriding nodes in exynos4210-origen
  ARM: dts: Use labels for overriding nodes in exynos4210-smdkv310
  ARM: dts: Use labels for overriding nodes in exynos4210-trats
  ARM: dts: Use labels for overriding nodes in exynos4212
  ARM: dts: Use labels for overriding nodes in exynos4x12
  ARM: dts: Use labels for overriding nodes in exynos4412
  ARM: dts: Use labels for overriding nodes in exynos4412-odroid
  ARM: dts: Use labels for overriding nodes in exynos4412-smdk4412
  ARM: dts: Use labels for overriding nodes in exynos4412-trats2
  ARM: dts: Use labels for overriding nodes in exynos4412-origen
  ARM: dts: Use labels for overriding nodes in exynos4412-tiny4412
  ARM: dts: Add labels to exynos5 nodes
  ARM: dts: Use labels for overriding nodes in exynos5250
  ARM: dts: Remove duplicated I2C7 nodes in exynos5250-snow
  ARM: dts: Use labels for overriding nodes in exynos5420-arndale-octa
  ARM: dts: Use labels for overriding nodes in exynos542x
  ARM: dts: Use labels for overriding nodes in exynos5420-smdk5420
  ARM: dts: Use labels for overriding nodes in exynos5440 boards
  ARM: dts: Use labels for overriding nodes in exynos5422-odroidxu3
  ARM: dts: s3c2416: Add labels to S3C2416 nodes
  ARM: dts: s3c2416: Use labels for overriding nodes in SMDK2416
  ARM: dts: odroidxu3: Enable wake alarm of S2MPS11 RTC
  of: Add vendor prefix for Hardkernel
  ARM: dts: Add Odroid XU3 Lite support

Peter Chubb (1):
  ARM: dts: exynos5422-odroidxu3: Hook up PWM and use it for LEDs

 .../devicetree/bindings/vendor-prefixes.txt|1 +
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/exynos4.dtsi |   22 +-
 arch/arm/boot/dts/exynos4210-origen.dts|  418 +++---
 arch/arm/boot/dts/exynos4210-smdkv310.dts  |  280 ++--
 arch/arm/boot/dts/exynos4210-trats.dts |  592 -
 arch/arm/boot/dts/exynos4210.dtsi  |   49 +-
 arch/arm/boot/dts/exynos4212.dtsi  |   12 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|  732 +--
 arch/arm/boot/dts/exynos4412-odroidx.dts   |   16 +-
 arch/arm/boot/dts/exynos4412-origen.dts|  892 ++---
 arch/arm/boot/dts/exynos4412-smdk4412.dts  |  210 +--
 arch/arm/boot/dts/exynos4412-tiny4412.dts  |   54 +-
 arch/arm/boot/dts/exynos4412-trats2.dts| 1332 ++--
 arch/arm/boot/dts/exynos4412.dtsi  |   20 +-
 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi  |8 +-
 arch/arm/boot/dts/exynos4x12.dtsi  |  218 ++--
 arch/arm/boot/dts/exynos5.dtsi |6 +-
 arch/arm/boot/dts/exynos5250-snow.dts  |   46 +-
 arch/arm/boot/dts/exynos5250.dtsi  |   82 +-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  634 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |  645 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   98 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  479 +++
 arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts|   20 +
 arch/arm/boot/dts/exynos5422-odroidxu3.dts |  430 +--
 arch/arm/boot/dts/exynos5440-sd5v1.dts |   10 +-
 arch/arm/boot/dts/exynos5440-ssdk5440.dts  |   85 +-
 arch/arm/boot/dts/exynos5440.dtsi  

[GIT PULL] ARM: EXYNOS: More defconfig for 4.2

[Krzysztof Kozlowski]

Dear Kukjin,

Minor defconfig changes from Anand Moon for Odroid XU3 board.
You can find them also on the lists with my reviewed-by.

Best regards,
Krzysztof


The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736:

  Linux 4.1-rc3 (2015-05-10 15:12:29 -0700)

are available in the git repository at:

  https://github.com/krzk/linux.git tags/samsung-defconfig-for-4.2

for you to fetch changes up to 314be0834460dfde70b614f1a2e5d041684ce796:

  ARM: exynos_defconfig: Enable LEDs for Odroid-XU3 (2015-05-30 13:19:49 +0900)


Enable in exynos_defconfig options for Odroid XU3:
1. sensors (fan, ina231),
2. LED.


Anand Moon (3):
  ARM: exynos_defconfig: Enable CONFIG_SENSORS_PWM_FAN for Odroid-XU3 
pmw-fan
  ARM: exynos_defconfig: Enable CONFIG_SENSORS_INA2XX for Odroid-XU3
  ARM: exynos_defconfig: Enable LEDs for Odroid-XU3

 arch/arm/configs/exynos_defconfig | 5 +
 1 file changed, 5 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] zram: clear disk io accounting when reset zram device

[Sergey Senozhatsky]

On (05/29/15 23:54), Minchan Kim wrote:
> I think the problem is caused from weired feature "reset" of zram.

agree.

> Until a while ago, we didn't have hot_add/del feature so we should
> use custom reset function but now we have hot/add feature.
> So reset is logically same feature(ie, reset = hot_remove+hot_add
> but remains same device id).
> 

hm, sounds interesting, but I think it will end up being tricky.

zram_remove() will be called from device's sysfs node (now we call it from
zram_control sysfs class node, makes a huge difference). sysfs locks the node
until node's read/write handler returns back, so zram_remove() will be called
with lock(s_active#XXX) being locked (we had a lockdep splat with these locks
recently), while zram_remove()->sysfs_remove_group() will once again attempt
to lock this node (the very same lock(s_active#XXX)). in other words, we cannot
fully remove zram device from its sysfs attr. and I don't want to add any bool
flags to zram_remove() and zram_add() indicating that this is a "partial" device
remove: don't delete device's sysfs group in remove() and don't create it in 
add().


doing reset from zram_control is easy, for sure:
lock idr mutex,
do zram_remove() and zram_add()
unlock idr lock.

`echo ID > /sys/.../zram_control/reset`

no need to modify remove()/add() -- idr will pick up just released idx,
so device_id will be preserved. but it'll be hard to drop the per-device
`reset` attr and to make it a zram_control attr. things would have been
much simpler if all of zram users were also zramctl users. zramctl, from
this point of view, lets us change zram interfaces easily -- we merely need
to teach/modify zramctl, the rest is transparent.

-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:locking/core] locking/pvqspinlock, x86: Implement the paravirt qspinlock call patching

[Sasha Levin]

On 05/08/2015 09:27 AM, tip-bot for Peter Zijlstra (Intel) wrote:
> Commit-ID:  f233f7f1581e78fd9b4023f2e7d8c1ed89020cc9
> Gitweb: http://git.kernel.org/tip/f233f7f1581e78fd9b4023f2e7d8c1ed89020cc9
> Author: Peter Zijlstra (Intel) 
> AuthorDate: Fri, 24 Apr 2015 14:56:38 -0400
> Committer:  Ingo Molnar 
> CommitDate: Fri, 8 May 2015 12:37:09 +0200
> 
> locking/pvqspinlock, x86: Implement the paravirt qspinlock call patching
> 
> We use the regular paravirt call patching to switch between:
> 
>   native_queued_spin_lock_slowpath()  __pv_queued_spin_lock_slowpath()
>   native_queued_spin_unlock() __pv_queued_spin_unlock()
> 
> We use a callee saved call for the unlock function which reduces the
> i-cache footprint and allows 'inlining' of SPIN_UNLOCK functions
> again.
> 
> We further optimize the unlock path by patching the direct call with a
> "movb $0,%arg1" if we are indeed using the native unlock code. This
> makes the unlock code almost as fast as the !PARAVIRT case.
> 
> This significantly lowers the overhead of having
> CONFIG_PARAVIRT_SPINLOCKS enabled, even for native code.
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> Signed-off-by: Waiman Long 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Andrew Morton 
> Cc: Boris Ostrovsky 
> Cc: Borislav Petkov 
> Cc: Daniel J Blueman 
> Cc: David Vrabel 
> Cc: Douglas Hatch 
> Cc: H. Peter Anvin 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Linus Torvalds 
> Cc: Oleg Nesterov 
> Cc: Paolo Bonzini 
> Cc: Paul E. McKenney 
> Cc: Peter Zijlstra 
> Cc: Raghavendra K T 
> Cc: Rik van Riel 
> Cc: Scott J Norton 
> Cc: Thomas Gleixner 
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: xen-de...@lists.xenproject.org
> Link: 
> http://lkml.kernel.org/r/1429901803-29771-10-git-send-email-waiman.l...@hp.com
> Signed-off-by: Ingo Molnar 

Hey Peter,

I'm seeing this on the latest -next kernel:

[ 8693.503262] BUG: KASan: out of bounds access in 
__pv_queued_spin_lock_slowpath+0x84e/0x8c0 at addr b9495950
[ 8693.503271] Read of size 8 by task swapper/9/0
[ 8693.503289] Address belongs to variable pv_lock_ops+0x10/0x240
[ 8693.503301] CPU: 9 PID: 0 Comm: swapper/9 Tainted: G  D 
4.1.0-rc5-next-20150529-sasha-00039-g7fd455d-dirty #2263
[ 8693.503335]  b6a1423a b6f92731d7a76ba3 8802b349f918 
b6a1423a
[ 8693.503355]   8802b349f9a8 8802b349f998 
ad5c70ee
[ 8693.503375]  ad2eb58e 0004 0086 
11011953cbb4
[ 8693.503379] Call Trace:
[ 8693.503409] ? dump_stack (lib/dump_stack.c:52)
[ 8693.503426] dump_stack (lib/dump_stack.c:52)
[ 8693.503454] kasan_report_error (mm/kasan/report.c:132 mm/kasan/report.c:193)
[ 8693.503463] ? __pv_queued_spin_lock_slowpath 
(./arch/x86/include/asm/paravirt.h:730 kernel/locking/qspinlock.c:410)
[ 8693.503474] ? kasan_report_error (mm/kasan/report.c:186)
[ 8693.503488] ? trace_hardirqs_off_caller (./arch/x86/include/asm/current.h:14 
kernel/locking/lockdep.c:2652)
[ 8693.503504] __asan_report_load8_noabort (mm/kasan/report.c:230 
mm/kasan/report.c:251)
[ 8693.503517] ? __pv_queued_spin_lock_slowpath 
(./arch/x86/include/asm/paravirt.h:730 kernel/locking/qspinlock.c:410)
[ 8693.503526] __pv_queued_spin_lock_slowpath 
(./arch/x86/include/asm/paravirt.h:730 kernel/locking/qspinlock.c:410)
[ 8693.503541] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503557] ? trace_hardirqs_off_thunk (arch/x86/lib/thunk_64.S:43)
[ 8693.503566] ? trace_hardirqs_off_caller (./arch/x86/include/asm/current.h:14 
kernel/locking/lockdep.c:2652)
[ 8693.503578] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503589] ? trace_hardirqs_off_thunk (arch/x86/lib/thunk_64.S:43)
[ 8693.503605] ? native_iret (arch/x86/kernel/entry_64.S:806)
[ 8693.503614] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503623] ? trace_hardirqs_off_thunk (arch/x86/lib/thunk_64.S:43)
[ 8693.503631] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503639] ? async_page_fault (arch/x86/kernel/entry_64.S:1261)
[ 8693.503663] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503681] ? native_iret (arch/x86/kernel/entry_64.S:806)
[ 8693.503691] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503699] ? trace_hardirqs_off_thunk (arch/x86/lib/thunk_64.S:43)
[ 8693.503730] ? trace_hardirqs_off_caller (./arch/x86/include/asm/current.h:14 
kernel/locking/lockdep.c:2652)
[ 8693.503743] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503754] ? trace_hardirqs_off_thunk (arch/x86/lib/thunk_64.S:43)
[ 8693.503772] ? native_iret (arch/x86/kernel/entry_64.S:806)
[ 8693.503784] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503794] ? trace_hardirqs_off_thunk (arch/x86/lib/thunk_64.S:43)
[ 8693.503802] ? error_sti (arch/x86/kernel/entry_64.S:1334)
[ 8693.503814] ? async_page_fault (arch/x86/kernel/entry_64.S:1

Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE

[Mike Galbraith]

On Fri, 2015-05-29 at 17:03 -0400, Josef Bacik wrote:

> for_each_lower_domain(sd) {
>  sg = sd->groups;
>  do {
>  if (!cpumask_intersects(sched_group_cpus(sg),
>  tsk_cpus_allowed(p)))
>  goto next;
> 
>  for_each_cpu(i, sched_group_cpus(sg)) {
>  if (i == target || !idle_cpu(i))
>  goto next;
>  }
> 
>  return cpumask_first_and(sched_group_cpus(sg),
>  tsk_cpus_allowed(p));
> next:
>  sg = sg->next
>  } while (sg != sd->groups);
> }
> 
> We get all the schedule groups for the schedule domain and if any of the 
> cpu's are not idle or the target then we skip the whole scheduling 
> group.  Isn't the scheduling group a group of CPU's?  Why can't we pick 
> an idle CPU in the group that has a none idle cpu or the target cpu? 
> Thanks,

We select an idle core if we can get one.  Yes, that leaves a pile of
SMT threads not checked/selected, but if you're gonna do a full search
of a large socket (humongous sparc-thing, shudder), you may as well eat
the BALANCE_WAKE overhead.

-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 01/36] mmu_notifier: add event information to address invalidation v7

[John Hubbard]

On Thu, 21 May 2015, j.gli...@gmail.com wrote:

> From: Jérôme Glisse 
> 
> The event information will be useful for new user of mmu_notifier API.
> The event argument differentiate between a vma disappearing, a page
> being write protected or simply a page being unmaped. This allow new
> user to take different path for different event for instance on unmap
> the resource used to track a vma are still valid and should stay around.
> While if the event is saying that a vma is being destroy it means that any
> resources used to track this vma can be free.
> 
> Changed since v1:
>   - renamed action into event (updated commit message too).
>   - simplified the event names and clarified their usage
> also documenting what exceptation the listener can have in
> respect to each event.
> 
> Changed since v2:
>   - Avoid crazy name.
>   - Do not move code that do not need to move.
> 
> Changed since v3:
>   - Separate hugue page split from mlock/munlock and softdirty.

Do we care about fixing up patch comments? If so:

s/hugue/huge/

> 
> Changed since v4:
>   - Rebase (no other changes).
> 
> Changed since v5:
>   - Typo fix.
>   - Changed zap_page_range from MMU_MUNMAP to MMU_MIGRATE to reflect the
> fact that the address range is still valid just the page backing it
> are no longer.
> 
> Changed since v6:
>   - try_to_unmap_one() only invalidate when doing migration.
>   - Differentiate fork from other case.
> 
> Signed-off-by: Jérôme Glisse 
> Reviewed-by: Rik van Riel 
> ---
>  drivers/gpu/drm/i915/i915_gem_userptr.c |   3 +-
>  drivers/gpu/drm/radeon/radeon_mn.c  |   3 +-
>  drivers/infiniband/core/umem_odp.c  |   9 ++-
>  drivers/iommu/amd_iommu_v2.c|   3 +-
>  drivers/misc/sgi-gru/grutlbpurge.c  |   9 ++-
>  drivers/xen/gntdev.c|   9 ++-
>  fs/proc/task_mmu.c  |   6 +-
>  include/linux/mmu_notifier.h| 135 
> ++--
>  kernel/events/uprobes.c |  10 ++-
>  mm/huge_memory.c|  39 ++---
>  mm/hugetlb.c|  23 +++---
>  mm/ksm.c|  18 +++--
>  mm/madvise.c|   4 +-
>  mm/memory.c |  27 ---
>  mm/migrate.c|   9 ++-
>  mm/mmu_notifier.c   |  28 ---
>  mm/mprotect.c   |   6 +-
>  mm/mremap.c |   6 +-
>  mm/rmap.c   |   4 +-
>  virt/kvm/kvm_main.c |  12 ++-
>  20 files changed, 261 insertions(+), 102 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 4039ede..452e9b1 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -132,7 +132,8 @@ restart:
>  static void i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier 
> *_mn,
>  struct mm_struct *mm,
>  unsigned long start,
> -unsigned long end)
> +unsigned long end,
> +enum mmu_event event)
>  {
>   struct i915_mmu_notifier *mn = container_of(_mn, struct 
> i915_mmu_notifier, mn);
>   struct interval_tree_node *it = NULL;
> diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
> b/drivers/gpu/drm/radeon/radeon_mn.c
> index eef006c..3a9615b 100644
> --- a/drivers/gpu/drm/radeon/radeon_mn.c
> +++ b/drivers/gpu/drm/radeon/radeon_mn.c
> @@ -121,7 +121,8 @@ static void radeon_mn_release(struct mmu_notifier *mn,
>  static void radeon_mn_invalidate_range_start(struct mmu_notifier *mn,
>struct mm_struct *mm,
>unsigned long start,
> -  unsigned long end)
> +  unsigned long end,
> +  enum mmu_event event)
>  {
>   struct radeon_mn *rmn = container_of(mn, struct radeon_mn, mn);
>   struct interval_tree_node *it;
> diff --git a/drivers/infiniband/core/umem_odp.c 
> b/drivers/infiniband/core/umem_odp.c
> index 40becdb..6ed69fa 100644
> --- a/drivers/infiniband/core/umem_odp.c
> +++ b/drivers/infiniband/core/umem_odp.c
> @@ -165,7 +165,8 @@ static int invalidate_page_trampoline(struct ib_umem 
> *item, u64 start,
>  
>  static void ib_umem_notifier_invalidate_page(struct mmu_notifier *mn,
>struct mm_struct *mm,
> -  unsigned long address)
> +  unsigned long address,
> +  enum mmu_event event)
>  

[PATCH 3/4]: Change arm-gic-its to support the Mbigen interrupt

[majun (F)]

This patch is applied to support the mbigen interrupt.

Change log:
--For irq_mbigen.c using,move some struct and function definition
  to a new head file arm-gic-its.h
--Add a irq_write_mbi_msg member for mbi interrupt using
--For mbi interrupt, the event id depends on the Hardware pin number on mbigen,
  so, the its_get_event_id is changed to calclulate the event id of mbi 
interrupt
--For mbigen, the device id information need to be carried with msg. So,
  its_irq_compose_msi_msg is changed.
--its_mask_msi_irq and its_unmaks_msi_irq are modifid for mbi interrupt using.
--before the irq_ack callback, check the irq_ack first(chip.c)


Signed-off-by: Ma Jun 
---
 drivers/irqchip/irq-gic-v3-its.c|   71 +++---
 include/linux/irq.h |1 +
 include/linux/irqchip/arm-gic-its.h |   68 +
 kernel/irq/chip.c   |   12 --
 4 files changed, 100 insertions(+), 52 deletions(-)
 mode change 100644 => 100755 drivers/irqchip/irq-gic-v3-its.c
 create mode 100755 include/linux/irqchip/arm-gic-its.h

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
old mode 100644
new mode 100755
index 9687f8a..21c36bf
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,7 +31,7 @@
 #include 
 #include 

-#include 
+#include 

 #include 
 #include 
@@ -42,36 +43,6 @@

 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)

-/*
- * Collection structure - just an ID, and a redistributor address to
- * ping. We use one per CPU as a bag of interrupts assigned to this
- * CPU.
- */
-struct its_collection {
-   u64 target_address;
-   u16 col_id;
-};
-
-/*
- * The ITS structure - contains most of the infrastructure, with the
- * msi_controller, the command queue, the collections, and the list of
- * devices writing to it.
- */
-struct its_node {
-   raw_spinlock_t  lock;
-   struct list_headentry;
-   struct msi_controller   msi_chip;
-   struct irq_domain   *domain;
-   void __iomem*base;
-   unsigned long   phys_base;
-   struct its_cmd_block*cmd_base;
-   struct its_cmd_block*cmd_write;
-   void*tables[GITS_BASER_NR_REGS];
-   struct its_collection   *collections;
-   struct list_headits_device_list;
-   u64 flags;
-   u32 ite_size;
-};

 #define ITS_ITT_ALIGN  SZ_256

@@ -79,17 +50,6 @@ struct its_node {
  * The ITS view of a device - belongs to an ITS, a collection, owns an
  * interrupt translation table, and a list of interrupts.
  */
-struct its_device {
-   struct list_headentry;
-   struct its_node *its;
-   struct its_collection   *collection;
-   void*itt;
-   unsigned long   *lpi_map;
-   irq_hw_number_t lpi_base;
-   int nr_lpis;
-   u32 nr_ites;
-   u32 device_id;
-};

 static LIST_HEAD(its_nodes);
 static DEFINE_SPINLOCK(its_lock);
@@ -528,7 +488,11 @@ static void its_send_invall(struct its_node *its, struct 
its_collection *col)
 static inline u32 its_get_event_id(struct irq_data *d)
 {
struct its_device *its_dev = irq_data_get_irq_chip_data(d);
-   return d->hwirq - its_dev->lpi_base;
+
+   if (!is_mbigen_domain(d))
+   return d->hwirq - its_dev->lpi_base;
+   else
+   return get_mbi_offset(d->irq);
 }

 static void lpi_set_config(struct irq_data *d, bool enable)
@@ -599,7 +563,13 @@ static void its_irq_compose_msi_msg(struct irq_data *d, 
struct msi_msg *msg)

msg->address_lo = addr & ((1UL << 32) - 1);
msg->address_hi = addr >> 32;
-   msg->data   = its_get_event_id(d);
+
+   /*for devices connect to mbigen, device id
+*information is needed*/
+   if (!is_mbigen_domain(d))
+   msg->data = its_get_event_id(d);
+   else
+   msg->data = (its_dev->device_id << 16) | its_get_event_id(d);
 }

 static struct irq_chip its_irq_chip = {
@@ -613,13 +583,15 @@ static struct irq_chip its_irq_chip = {

 static void its_mask_msi_irq(struct irq_data *d)
 {
-   pci_msi_mask_irq(d);
+   if (!is_mbigen_domain(d))
+   pci_msi_mask_irq(d);
irq_chip_mask_parent(d);
 }

 static void its_unmask_msi_irq(struct irq_data *d)
 {
-   pci_msi_unmask_irq(d);
+   if (!is_mbigen_domain(d))
+   pci_msi_unmask_irq(d);
irq_chip_unmask_parent(d);
 }

@@ -629,6 +601,8 @@ static struct irq_chip its_msi_irq_chip = {
.irq_mask   = its_mask_msi_irq,
.irq_eoi= irq_chip_eoi_parent,
.irq_write_msi_msg  = 

[PATCH 4/4]:dt-binding:Documents the mbigen bindings

[majun (F)]

Add the mbigen msi interrupt controller bindings document


Signed-off-by: Ma Jun 
---
 Documentation/devicetree/bindings/arm/mbigen.txt |   51 ++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100755 Documentation/devicetree/bindings/arm/mbigen.txt

diff --git a/Documentation/devicetree/bindings/arm/mbigen.txt 
b/Documentation/devicetree/bindings/arm/mbigen.txt
new file mode 100755
index 000..d442b31
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mbigen.txt
@@ -0,0 +1,51 @@
+Hisilicon mbigen device tree bindings.
+===
+
+Mbigen means: message based interrupt generator.
+
+MBI is kind of msi interrupt only used on Non-PCI devices.
+
+To reduce the wired interrupt number connected to GIC,
+Hisilicon designed mbigen to collect and generate interrupt.
+
+
+Non-pci devices can connect to mbigen and gnerate the inteerrupt
+by wirtting ITS register.
+
+The mbigen and devices connect to mbigen have the following properties:
+
+
+Mbigen required properties:
+---
+-compatible: Should be "hisilicon,mbi-gen"
+-msi-parent: should specified the ITS mbigen connected
+-interrupt controller: Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value is 2 for now.
+- reg: Specifies the base physical address and size of the ITS
+  registers.
+
+Examples:
+
+   mbigen_pa: interrupt-controller@4c03 {
+   compatible = "hisilicon,mbi-gen";
+   msi-parent = <_pa>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x4c03 0x1>;
+   };
+
+Device connect to mbigen required properties:
+
+-interrupt-parent: Specifies the mbigen node which device connected.
+-interrupts:specifies the interrupt source.The first cell is hwirq num, the
+  second number is trigger type.
+
+Examples:
+   usb0: ehci@a100 {
+   compatible = "generic-ehci";
+   interrupt-parent = <_pa>;
+   reg = <0xa100 0x1>;
+   interrupts = <20 4>;
+   };
+
-- 
1.7.1


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

[PATCH 2/4]: Change msi to support the Mbigen interrupt

[majun (F)]

This patch is applied to support the interrupts from Mbigen.

As a interrupt controller, Mbigen is used as a child domain of MSI
domain just like pci device.

Change log:
--add IRQ_DOMAIN_FLAG_MBIGEN to presents the interrupt from mbigen
--add function is_mbigen_domain to check the interrupt domain
--modified irq_chip_write_msi_msg to use the different message write function
  for interrupt from mbigen

Signed-off-by: Ma Jun 
---
 include/linux/irqdomain.h |2 +-
 include/linux/msi.h   |1 +
 kernel/irq/msi.c  |   22 +-
 3 files changed, 23 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 include/linux/msi.h
 mode change 100644 => 100755 kernel/irq/msi.c

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 676d730..cb6b33a 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -136,7 +136,7 @@ enum {

/* Core calls alloc/free recursive through the domain hierarchy. */
IRQ_DOMAIN_FLAG_AUTO_RECURSIVE  = (1 << 1),
-
+   IRQ_DOMAIN_FLAG_MBIGEN = (1 << 2),
/*
 * Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
 * for implementation specific purposes and ignored by the
diff --git a/include/linux/msi.h b/include/linux/msi.h
old mode 100644
new mode 100755
index 8ac4a68..3e2b6c7
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -239,5 +239,6 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct pci_dev 
*dev,
 int pci_msi_domain_check_cap(struct irq_domain *domain,
 struct msi_domain_info *info, struct device *dev);
 #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
+bool is_mbigen_domain(struct irq_data *data);

 #endif /* LINUX_MSI_H */
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
old mode 100644
new mode 100755
index 474de5c..1dba07e
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -31,11 +31,31 @@ void get_cached_msi_msg(unsigned int irq, struct msi_msg 
*msg)
 }
 EXPORT_SYMBOL_GPL(get_cached_msi_msg);

+bool is_mbigen_domain(struct irq_data *data)
+{
+   int virq;
+   struct irq_domain *domain;
+   struct irq_data *source_irq_data;
+
+   virq = data->irq;
+   source_irq_data = irq_get_irq_data(virq);
+   domain = source_irq_data->domain;
+
+   if (domain->flags & IRQ_DOMAIN_FLAG_MBIGEN)
+   return true;
+   else
+   return false;
+
+}
+
 #ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
 static inline void irq_chip_write_msi_msg(struct irq_data *data,
  struct msi_msg *msg)
 {
-   data->chip->irq_write_msi_msg(data, msg);
+   if (is_mbigen_domain(data))
+   data->chip->irq_write_mbi_msg(data, msg);
+   else
+   data->chip->irq_write_msi_msg(data, msg);
 }

 /**
-- 
1.7.1



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

[PATCH 1/4]:Add mbigen driver to support mbigen interrupt controller

[majun (F)]

This patch contains the mbigen device driver.

To support Mbigen device, irq-mbigen.c and mbi.h are added.

As a MSI interrupt controller, the mbigen is used as a child domain of
MSI domain just like PCI devices.

Change log:
--irq-mbigen.c: the driver of mbigen device.The mbigen irq domain is created 
here
   as child domain of MSI.
--Add CONFIG_MBIGEN_IRQ_DOMAIN enable this driver

Signed-off-by: Yun Wu 
Signed-off-by: Ma Jun 
---
 drivers/irqchip/Kconfig  |4 +
 drivers/irqchip/Makefile |1 +
 drivers/irqchip/irq-mbigen.c |  562 ++
 include/linux/mbi.h  |   77 ++
 4 files changed, 644 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 drivers/irqchip/Kconfig
 mode change 100644 => 100755 drivers/irqchip/Makefile
 create mode 100755 drivers/irqchip/irq-mbigen.c
 create mode 100644 include/linux/mbi.h

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
old mode 100644
new mode 100755
index 6de62a9..595a6eb
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -26,6 +26,10 @@ config ARM_GIC_V3
 config ARM_GIC_V3_ITS
bool
select PCI_MSI_IRQ_DOMAIN
+   select MBIGEN_IRQ_DOMAIN
+
+config MBIGEN_IRQ_DOMAIN
+   bool

 config ARM_NVIC
bool
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
old mode 100644
new mode 100755
index dda4927..23571c1
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_ARM_GIC) += irq-gic.o 
irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V3_ITS)   += irq-gic-v3-its.o
+obj-$(CONFIG_MBIGEN_IRQ_DOMAIN)+= irq-mbigen.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)+= irq-atmel-aic-common.o 
irq-atmel-aic.o
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
new file mode 100755
index 000..462f9a0
--- /dev/null
+++ b/drivers/irqchip/irq-mbigen.c
@@ -0,0 +1,562 @@
+/*
+ * Copyright (C) 2014 Hisilicon Limited, All Rights Reserved.
+ * Author: Yun Wu 
+ * Author: Jun Ma 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "irqchip.h"
+
+/* Register offsets */
+#define MG_IRQ_TYPE0x0
+#define MG_IRQ_CLEAR   0x100
+#define MG_IRQ_STATUS  0x200
+#define MG_MSG_DATA0x300
+
+/* The gap between normal and extended pin region */
+#define MG_EXT_OFST0x10
+
+/* Max number of interrupts supported */
+#define MG_NR_IRQS 640
+
+/* Number of mbigens supported in one chip */
+#define MG_NR  6
+
+struct mbigen_node {
+   struct list_headentry;
+   struct mbigen   *mbigen;
+   struct device_node  *source;
+   unsigned intirq;
+   unsigned intnr_irqs;
+};
+
+struct mbigen {
+   raw_spinlock_t  lock;
+   struct list_headentry;
+   struct mbigen_chip  *chip;
+   unsigned intnid;
+   unsigned intirqs_used;
+   struct list_headnodes;
+};
+
+struct mbigen_chip {
+   raw_spinlock_t  lock;
+   struct list_headentry;
+   struct device   *dev;
+   struct device_node  *node;
+   void __iomem*base;
+   struct irq_domain   *domain;
+   struct list_headnodes;
+};
+
+static LIST_HEAD(mbigen_chips);
+static DEFINE_SPINLOCK(mbigen_lock);
+
+int get_mbi_offset(int virq)
+{
+   struct irq_data *data;
+   struct mbi_desc *mbidesc;
+   int offset = 0;
+
+   data = irq_get_irq_data(virq);
+
+   mbidesc = (struct mbi_desc *)data->msi_desc;
+   offset = mbidesc->offset;
+   return offset;
+}
+
+int mbi_parse_irqs(struct device *dev, struct mbi_ops *ops)
+{
+   pr_warn("%s:this function not use now\n", __func__);
+   return -EINVAL;
+}
+EXPORT_SYMBOL(mbi_parse_irqs);
+
+void mbi_free_irqs(struct device *dev, unsigned int virq, unsigned int nvec)
+{
+   pr_warn("%s:this function not use now\n", __func__);
+}
+EXPORT_SYMBOL(mbi_free_irqs);
+
+static 

[PATCH 0/4] Cover: Support mbigen msi interrupt controller

[majun (F)]

This patch set is applied to supprot the mbigen device.

Mbigen means message based interrupt generator.
It locate in ITS or out side of ITS.

In fact, mbigen is a kind of interrupt controller collects
the irq form Non-PCI devices and generate msi interrupt.

Hisilicon designed mbigen to reduce the wired interrupt
number connected to GIC.

In these patches, the interrupts from Non-PCI devices are
named as MBI to distiguish between legacy MSI interrupt from
PCI devices.

As a MSI interrupt controller, the mbigen is used as a child
domain of MSI domain just like PCI devices.

So,in order to support the mbigen interrupt controller, the
msi.c and its-gic-v3-its.c are changed.

Ma Jun (4):
  Add mbigen driver to support mbigen interrupt controller
  Change msi to support the Mbigen interrupt
  Change arm-gic-its to support the Mbigen interrupt
  dt-binding:Documents the mbigen bindings

 Documentation/devicetree/bindings/arm/mbigen.txt |   51 ++
 drivers/irqchip/Kconfig  |4 +
 drivers/irqchip/Makefile |1 +
 drivers/irqchip/irq-gic-v3-its.c |   71 +--
 drivers/irqchip/irq-mbigen.c |  562 ++
 include/linux/irq.h  |1 +
 include/linux/irqchip/arm-gic-its.h  |   68 +++
 include/linux/irqdomain.h|2 +-
 include/linux/mbi.h  |   77 +++
 include/linux/msi.h  |1 +
 kernel/irq/chip.c|   12 +-
 kernel/irq/msi.c |   22 +-
 12 files changed, 818 insertions(+), 54 deletions(-)
 create mode 100755 Documentation/devicetree/bindings/arm/mbigen.txt
 mode change 100644 => 100755 drivers/irqchip/Kconfig
 mode change 100644 => 100755 drivers/irqchip/Makefile
 mode change 100644 => 100755 drivers/irqchip/irq-gic-v3-its.c
 create mode 100755 drivers/irqchip/irq-mbigen.c
 create mode 100755 include/linux/irqchip/arm-gic-its.h
 create mode 100644 include/linux/mbi.h
 mode change 100644 => 100755 include/linux/msi.h
 mode change 100644 => 100755 kernel/irq/msi.c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: HMM (Heterogeneous Memory Management) v8

[John Hubbard]

On Thu, 21 May 2015, j.gli...@gmail.com wrote:

> 
> So sorry had to resend because i stupidly forgot to cc mailing list.
> Ignore private send done before.
> 
> 
> HMM (Heterogeneous Memory Management) is an helper layer for device
> that want to mirror a process address space into their own mmu. Main
> target is GPU but other hardware, like network device can take also
> use HMM.
> 
> There is two side to HMM, first one is mirroring of process address
> space on behalf of a device. HMM will manage a secondary page table
> for the device and keep it synchronize with the CPU page table. HMM
> also do DMA mapping on behalf of the device (which would allow new
> kind of optimization further down the road (1)).
> 
> Second side is allowing to migrate process memory to device memory
> where device memory is unmappable by the CPU. Any CPU access will
> trigger special fault that will migrate memory back.
> 
> From design point of view not much changed since last patchset (2).
> Most of the change are in small details of the API expose to device
> driver. This version also include device driver change for Mellanox
> hardware to use HMM as an alternative to ODP (which provide a subset
> of HMM functionality specificaly for RDMA devices). Long term plan
> is to have HMM completely replace ODP.
> 

Hi Jerome!

OK, seeing as how there is so much material to review here, I'll start 
with the easiest part first: documentation.

There is a lot of information spread throughout this patchset that needs 
to be preserved and made readily accessible, but some of it is only found 
in the comments in patch headers. It would be better if the information 
were right there in the source tree, not just in git history. Also, the 
comment blocks that are in the code itself are useful, but maybe not 
quite sufficient to provide the big picture.

With that in mind, I think that a Documentation/vm/hmm.txt file should be 
provided. It could capture all of this. We can refer to it from within the 
code, thus providing a higher level of quality (because we only have to 
update one place, for big-picture documentation comments).

If it helps, I'll volunteer to piece something together from the material 
that you have created, plus maybe a few notes about what a typical calling 
sequence looks like (since I have actual backtraces here from the 
ConnectIB cards).

Also, there are a lot of typographical errors that we can fix up as part 
of that effort. We want to ensure that such tiny issues don't distract 
people from the valuable content, so those need to be fixed. I'll let 
others decide as to whether that sort of fit-and-finish needs to happen 
now, or as a follow-up patch or two.

And finally, a critical part of good documentation is the naming of 
things. We're sort of still in the "wow, it works" phase of this project, 
and so now is a good time to start fussing about names. Therefore, you'll 
see a bunch of small and large naming recommendations coming from me, for 
the various patches here.

thanks,
John Hubbard

> 
> 
> Why doing this ?
> 
> Mirroring a process address space is mandatory with OpenCL 2.0 and
> with other GPU compute API. OpenCL 2.0 allow different level of
> implementation and currently only the lowest 2 are supported on
> Linux. To implement the highest level, where CPU and GPU access
> can happen concurently and are cache coherent, HMM is needed, or
> something providing same functionality, for instance through
> platform hardware.
> 
> Hardware solution such as PCIE ATS/PASID is limited to mirroring
> system memory and does not provide way to migrate memory to device
> memory (which offer significantly more bandwidth up to 10 times
> faster than regular system memory with discret GPU, also have
> lower latency than PCIE transaction).
> 
> Current CPU with GPU on same die (AMD or Intel) use the ATS/PASID
> and for Intel a special level of cache (backed by a large pool of
> fast memory).
> 
> For foreseeable futur, discrete GPU will remain releveant as they
> can have a large quantity of faster memory than integrated GPU.
> 
> Thus we believe HMM will allow to leverage discret GPU memory in
> a transparent fashion to the application, with minimum disruption
> to the linux kernel mm code. Also HMM can work along hardware
> solution such as PCIE ATS/PASID (leaving regular case to ATS/PASID
> while HMM handles the migrated memory case).
> 
> 
> 
> Design :
> 
> The patch 1, 2, 3 and 4 augment the mmu notifier API with new
> informations to more efficiently mirror CPU page table updates.
> 
> The first side of HMM, process address space mirroring, is
> implemented in patch 5 through 12. This use a secondary page
> table, in which HMM mirror memory actively use by the device.
> HMM does not take a reference on any of the page, it use the
> mmu notifier API to track changes to the CPU page table and to
> update the mirror page table. All this while providing a simple
> API to device driver.
> 
> To implement this we 

[PATCH] Input: of_touchscreen - remove interdependence of max/fuzz values

[Sebastian Reichel]

Commit 3eea8b5d68c8 introduced a dependency between touchscreen-max-*
and touchscreen-fuzz-*, so that either both must be specified or none
of them. If only one of them is specified the other value will be
reset to 0. This commit restores the previous behaviour, that the
drivers default value will be used for the unspecified value.

Reported-By: Pavel Machek 
Fixes: 3eea8b5d68c8 (Input: of_touchscreen - rework the DT parsing function)
Signed-off-by: Sebastian Reichel 
---
 drivers/input/touchscreen/of_touchscreen.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/input/touchscreen/of_touchscreen.c 
b/drivers/input/touchscreen/of_touchscreen.c
index b82b520..7d2cf59 100644
--- a/drivers/input/touchscreen/of_touchscreen.c
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -42,8 +42,11 @@ static void touchscreen_set_params(struct input_dev *dev,
}
 
absinfo = >absinfo[axis];
-   absinfo->maximum = max;
-   absinfo->fuzz = fuzz;
+
+   if (max)
+   absinfo->maximum = max;
+   if (fuzz)
+   absinfo->fuzz = fuzz;
 }
 
 /**
@@ -65,23 +68,17 @@ void touchscreen_parse_of_params(struct input_dev *dev)
 
maximum = of_get_optional_u32(np, "touchscreen-size-x");
fuzz = of_get_optional_u32(np, "touchscreen-fuzz-x");
-   if (maximum || fuzz) {
-   touchscreen_set_params(dev, ABS_X, maximum, fuzz);
-   touchscreen_set_params(dev, ABS_MT_POSITION_X, maximum, fuzz);
-   }
+   touchscreen_set_params(dev, ABS_X, maximum, fuzz);
+   touchscreen_set_params(dev, ABS_MT_POSITION_X, maximum, fuzz);
 
maximum = of_get_optional_u32(np, "touchscreen-size-y");
fuzz = of_get_optional_u32(np, "touchscreen-fuzz-y");
-   if (maximum || fuzz) {
-   touchscreen_set_params(dev, ABS_Y, maximum, fuzz);
-   touchscreen_set_params(dev, ABS_MT_POSITION_Y, maximum, fuzz);
-   }
+   touchscreen_set_params(dev, ABS_Y, maximum, fuzz);
+   touchscreen_set_params(dev, ABS_MT_POSITION_Y, maximum, fuzz);
 
maximum = of_get_optional_u32(np, "touchscreen-max-pressure");
fuzz = of_get_optional_u32(np, "touchscreen-fuzz-pressure");
-   if (maximum || fuzz) {
-   touchscreen_set_params(dev, ABS_PRESSURE, maximum, fuzz);
-   touchscreen_set_params(dev, ABS_MT_PRESSURE, maximum, fuzz);
-   }
+   touchscreen_set_params(dev, ABS_PRESSURE, maximum, fuzz);
+   touchscreen_set_params(dev, ABS_MT_PRESSURE, maximum, fuzz);
 }
 EXPORT_SYMBOL(touchscreen_parse_of_params);
-- 
2.1.4

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

Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900

[Sebastian Reichel]

Hi,

On Fri, May 29, 2015 at 09:32:11PM +0200, Pavel Machek wrote:
> Fix dts to match what the Linux kernel expects. This works around
> touchscreen problems in 4.1 linux on Nokia n900.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> index 4b641c7..09089a6 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> @@ -32,8 +32,8 @@ Example:
>   touchscreen-fuzz-x = <4>;
>   touchscreen-fuzz-y = <7>;
>   touchscreen-fuzz-pressure = <2>;
> - touchscreen-max-x = <4096>;
> - touchscreen-max-y = <4096>;
> + touchscreen-size-x = <4096>;
> + touchscreen-size-y = <4096>;
>   touchscreen-max-pressure = <2048>;
>  
>   ti,x-plate-ohms = <280>;
> diff --git a/arch/arm/boot/dts/omap3-n900.dts 
> b/arch/arm/boot/dts/omap3-n900.dts
> index 5c16145..5f5e0f3 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -832,8 +832,8 @@
>   touchscreen-fuzz-x = <4>;
>   touchscreen-fuzz-y = <7>;
>   touchscreen-fuzz-pressure = <2>;
> - touchscreen-max-x = <4096>;
> - touchscreen-max-y = <4096>;
> + touchscreen-size-x = <4096>;
> + touchscreen-size-y = <4096>;
>   touchscreen-max-pressure = <2048>;
>  
>   ti,x-plate-ohms = <280>;

Acked-By: Sebastian Reichel 

max-x/fuzz-x is a leftover from development of the generic bindings
(Initially I used min and max).

If 3eea8b5d68c801fec788b411582b803463834752's behaviour should
become the new behaviour it should be documented, that maximum and
fuzz values are dependent on each other. Instead I suggest to
restore the old behaviour.

-- Sebastian


signature.asc
Description: Digital signature

[PATCH v9 0/6] arm64,hi6220: Enable Hisilicon Hi6220 SoC

[Bintian Wang]

Hi6220 is one mobile solution of Hisilicon, this patchset contains
initial support for Hi6220 SoC and HiKey development board, which
supports octal ARM Cortex A53 cores. Initial support is minimal and
includes just the arch configuration, device tree configuration, the
clock driver has been picked up by clock maintainers in clk tree.

PSCI is enabled in device tree and there is no problem to boot all the
octal cores, and the CPU hotplug is also working now, you can download
and compile the latest firmware based on the following link to run this
patch set:
https://github.com/96boards/documentation/wiki/UEFI

Chnages v9:
* Rebase to linus/master 4.1-rc1
* Remove the clock driver from this version because the clock maintainers
  have queued up the clock driver:
  git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next-hi6220
* This version also includes clock header file:
  [PATCH v9 6/6] dt-bindings: Add header file of hi6220 clock driver
  Although above patch is included in clock driver, I add to this series
  because the device tree file includes it, there will be compile error
  without it.
  At last, we just need to keep one when merged together.

Changes v6~v8:
This three versions only modified the clock drivers based on the
Stephen's review advices.
* clk-hi6220.c:
  ** Split the clock header file from clock driver
  ** Delete setting the parents clock of UART1 to HI6220_150M in clock
 driver, we can do that using assigned-clock in dts when enable
 UART1 in the future.
* clkdivider-hi6220.c: 
  ** Reuse some functions exported by clk-divider.c
  ** Remove "pr_err" and CLK_IS_BASIC flag
  ** Fix some programing style problems
* hisilicon/clk.h: remove the "__init" markings on some funcition
  prototypes.

Changes v5:
* Rebase to kernel 4.1-rc2
* Add compatible string "hisilicon,hi6220-pl011" for Hisilicon designed
  UART
* clk-hi6220.c: use __initdata for non-const arrays based on the commit
  692d8328e8c039f9497eb862c6cf835de922c061 

Changes v4:
* Rebase to kernel 4.1-rc1
* Delete "arm,cortex-a15-gic" from the gic node in dts 

Changes v3:
* Verified the CPU hotplug based on the new released firmware
* Redefined the compatible strings of four system controllers in dts 
* Setting COMMON_CLK_HI6220 to a bool symbol
* Keep CONFGI_ARCH_HISI sorted alphabetically

Changes v2:
* Split the DT bindings documents into earlier patches
* Change SMP enable method from spin-table to PSCI in device tree
* Remove "clock-frequency" from armv8-timer device node in device tree
* Add more description about Hisilicon designed system controllers
  in DT bindings document
* Enable high speed clock on UART1 mux
* Other changes based on the discussion in the mailing list:
  https://lkml.org/lkml/2015/2/5/147

Bintian Wang (6):
  arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig
  arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC
  clk: hi6220: Document devicetree bindings for hi6220 clock
  Documentation: DT: PL011: hi6220: add compatible string for Hisilicon
designed UART
  arm64: dts: Add dts files for Hisilicon Hi6220 SoC
  dt-bindings: Add header file of hi6220 clock driver

 .../bindings/arm/hisilicon/hisilicon.txt   |   87 ++
 .../devicetree/bindings/clock/hi6220-clock.txt |   34 
 Documentation/devicetree/bindings/serial/pl011.txt |4 +-
 arch/arm64/Kconfig |5 +
 arch/arm64/boot/dts/Makefile   |1 +
 arch/arm64/boot/dts/hisilicon/Makefile |5 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   31 
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  172 +++
 arch/arm64/configs/defconfig   |1 +
 include/dt-bindings/clock/hi6220-clock.h   |  173 
 10 files changed, 512 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt
 create mode 100644 arch/arm64/boot/dts/hisilicon/Makefile
 create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
 create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220.dtsi
 create mode 100644 include/dt-bindings/clock/hi6220-clock.h

-- 
1.7.9.5

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

Re: [PATCH v2 3/6] dt-bindings: brcmstb-gpio: document properties for wakeup

[Gregory Fong]

On Fri, May 29, 2015 at 6:37 PM, Brian Norris
 wrote:
> On Fri, May 29, 2015 at 05:57:50PM -0700, Gregory Fong wrote:
>> On Fri, May 29, 2015 at 5:36 PM, Brian Norris
>>  wrote:
>> > On Thu, May 28, 2015 at 07:14:07PM -0700, Gregory Fong wrote:
>> >> --- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
>> >> +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
>> >> @@ -33,6 +33,12 @@ Optional properties:
> ...
>> >>  - #interrupt-cells:
>> >>  Should be <2>.  The first cell is the GPIO number, the second should 
>> >> specify
>> >>  flags.  The following subset of flags is supported:
>> >> @@ -48,7 +54,10 @@ Optional properties:
>> >>  Marks the device node as an interrupt controller
>> >>
>> >>  - interrupt-names:
>> >> -The name of the IRQ resource used by this controller
>> >> +The names of the IRQ resources used by this controller
>> >
>> > If you're specifying names, you should list them here.
>>
>> I was wondering about that.  Some bindings have them listed, some
>> don't.  In this case I know what names currently exist but there could
>> certainly be different ones in the future.  How does that work?  Or am
>> I misunderstanding what this field is used for?  Where are the
>> documented rules for this?
>
> The only documentation I see is:
> Documentation/devicetree/bindings/resource-names.txt
>
> That documents the basics of the *-names properties, not their expected
> usage.
>
> In practice, they're only useful if you have enough optional resources
> that fixed indexing isn't sufficient, and you need to use
> platform_get_resource_byname().
>
> So IMO, their purposes seems to be one of these:
> (1) functional (e.g., for get_resource_byname(), when you have more than
> one optional resource)
> (2) self-documentation (which might run counter to #1, as you begin
> generating too many unique names)
> (3) no purpose
>
> So IMO, if you ever want (1), they shouldn't have instance-specific
> naming, but should use something generic to the device class. Otherwise,
> they are just self-documentation, and aren't functionally useful. So
> IMO, these sorts of names:
>
> interrupt-names = "upg_gio_aon", "upg_gio_aon_wakeup";
>
> work better as functional descriptions:
>
> interrupt-names = "gio", "wakeup";
>
> But in the end, I wouldn't foresee you needing to do (1), so you're left
> with (2) or (3), at which point I'm not sure if you should even mention
> the property.

I'm fine with leaving out the interrupt-names property, since we're
not using it here anyway.  Unless there are serious objections, I'll
plan on remove it from the bindings doc next round.

Thanks,
Gregory
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v9 4/6] Documentation: DT: PL011: hi6220: add compatible string for Hisilicon designed UART

[Bintian Wang]

Hisilicon does some performance enhancements based on PL011(e.g. larger
FIFO length), so add one compatible string "hisilicon,hi6220-uart" for
future optimisations or workarounds works.

Signed-off-by: Bintian Wang 
Suggested-by: Mark Rutland 
---
 Documentation/devicetree/bindings/serial/pl011.txt |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/serial/pl011.txt 
b/Documentation/devicetree/bindings/serial/pl011.txt
index ba3ecb8..cb9fd9d 100644
--- a/Documentation/devicetree/bindings/serial/pl011.txt
+++ b/Documentation/devicetree/bindings/serial/pl011.txt
@@ -1,7 +1,9 @@
 * ARM AMBA Primecell PL011 serial UART
 
 Required properties:
-- compatible: must be "arm,primecell", "arm,pl011"
+- compatible: should contain one of the following sequences:
+  * "arm,pl011", "arm,primecell"
+  * "hisilicon,hi6220-pl011", "arm,pl011", "arm,primecell"
 - reg: exactly one register range with length 0x1000
 - interrupts: exactly one interrupt specifier
 
-- 
1.7.9.5

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

[PATCH v9 1/6] arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig

[Bintian Wang]

This patch introduces ARCH_HISI to enable Hisilicon SoC family in
Kconfig and defconfig.

Signed-off-by: Bintian Wang 
Acked-by: Haojian Zhuang 
Reviewed-by: Wei Xu 
Tested-by: Will Deacon 
Tested-by: Tyler Baker 
Tested-by: Kevin Hilman 
---
 arch/arm64/Kconfig   |5 +
 arch/arm64/configs/defconfig |1 +
 2 files changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4269dba..2af5efe 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -180,6 +180,11 @@ config ARCH_FSL_LS2085A
help
  This enables support for Freescale LS2085A SOC.
 
+config ARCH_HISI
+   bool "Hisilicon SoC Family"
+   help
+ This enables support for Hisilicon ARMv8 SoC family
+
 config ARCH_MEDIATEK
bool "Mediatek MT65xx & MT81xx ARMv8 SoC"
select ARM_GIC
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2ed7449..1d293ea 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -33,6 +33,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_EXYNOS7=y
 CONFIG_ARCH_FSL_LS2085A=y
+CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_SEATTLE=y
 CONFIG_ARCH_TEGRA=y
-- 
1.7.9.5

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

[PATCH v9 3/6] clk: hi6220: Document devicetree bindings for hi6220 clock

[Bintian Wang]

Document DT files bindings for Hisilicon hi6220 clock.

Signed-off-by: Bintian Wang 
Acked-by: Haojian Zhuang 
Suggested-by: Arnd Bergmann 
Acked-by: Stephen Boyd 
---
 .../devicetree/bindings/clock/hi6220-clock.txt |   34 
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hi6220-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt 
b/Documentation/devicetree/bindings/clock/hi6220-clock.txt
new file mode 100644
index 000..53ddb19
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt
@@ -0,0 +1,34 @@
+* Hisilicon Hi6220 Clock Controller
+
+Clock control registers reside in different Hi6220 system controllers,
+please refer the following document to know more about the binding rules
+for these system controllers:
+
+Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+
+Required Properties:
+
+- compatible: the compatible should be one of the following strings to
+   indicate the clock controller functionality.
+
+   - "hisilicon,hi6220-aoctrl"
+   - "hisilicon,hi6220-sysctrl"
+   - "hisilicon,hi6220-mediactrl"
+   - "hisilicon,hi6220-pmctrl"
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+For example:
+   sys_ctrl: sys_ctrl {
+   compatible = "hisilicon,hi6220-sysctrl", "syscon";
+   reg = <0x0 0xf703 0x0 0x2000>;
+   #clock-cells = <1>;
+   };
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in .
-- 
1.7.9.5

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

[PATCH v9 6/6] dt-bindings: Add header file of hi6220 clock driver

[Bintian Wang]

Add the header file "hi6220-clock.h" used by both
hi6220 clock driver and hi6220 device tree file.

Suggested-by: Stephen Boyd 
Signed-off-by: Bintian Wang 
Tested-by: Will Deacon 
Tested-by: Tyler Baker 
Tested-by: Kevin Hilman 
---
 include/dt-bindings/clock/hi6220-clock.h |  173 ++
 1 file changed, 173 insertions(+)
 create mode 100644 include/dt-bindings/clock/hi6220-clock.h

diff --git a/include/dt-bindings/clock/hi6220-clock.h 
b/include/dt-bindings/clock/hi6220-clock.h
new file mode 100644
index 000..70ee383
--- /dev/null
+++ b/include/dt-bindings/clock/hi6220-clock.h
@@ -0,0 +1,173 @@
+/*
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Bintian Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_HI6220_H
+#define __DT_BINDINGS_CLOCK_HI6220_H
+
+/* clk in Hi6220 AO (always on) controller */
+#define HI6220_NONE_CLOCK  0
+
+/* fixed rate clocks */
+#define HI6220_REF32K  1
+#define HI6220_CLK_TCXO2
+#define HI6220_MMC1_PAD3
+#define HI6220_MMC2_PAD4
+#define HI6220_MMC0_PAD5
+#define HI6220_PLL_BBP 6
+#define HI6220_PLL_GPU 7
+#define HI6220_PLL1_DDR8
+#define HI6220_PLL_SYS 9
+#define HI6220_PLL_SYS_MEDIA   10
+#define HI6220_DDR_SRC 11
+#define HI6220_PLL_MEDIA   12
+#define HI6220_PLL_DDR 13
+
+/* fixed factor clocks */
+#define HI6220_300M14
+#define HI6220_150M15
+#define HI6220_PICOPHY_SRC 16
+#define HI6220_MMC0_SRC_SEL17
+#define HI6220_MMC1_SRC_SEL18
+#define HI6220_MMC2_SRC_SEL19
+#define HI6220_VPU_CODEC   20
+#define HI6220_MMC0_SMP21
+#define HI6220_MMC1_SMP22
+#define HI6220_MMC2_SMP23
+
+/* gate clocks */
+#define HI6220_WDT0_PCLK   24
+#define HI6220_WDT1_PCLK   25
+#define HI6220_WDT2_PCLK   26
+#define HI6220_TIMER0_PCLK 27
+#define HI6220_TIMER1_PCLK 28
+#define HI6220_TIMER2_PCLK 29
+#define HI6220_TIMER3_PCLK 30
+#define HI6220_TIMER4_PCLK 31
+#define HI6220_TIMER5_PCLK 32
+#define HI6220_TIMER6_PCLK 33
+#define HI6220_TIMER7_PCLK 34
+#define HI6220_TIMER8_PCLK 35
+#define HI6220_UART0_PCLK  36
+
+#define HI6220_AO_NR_CLKS  37
+
+/* clk in Hi6220 systrl */
+/* gate clock */
+#define HI6220_MMC0_CLK1
+#define HI6220_MMC0_CIUCLK 2
+#define HI6220_MMC1_CLK3
+#define HI6220_MMC1_CIUCLK 4
+#define HI6220_MMC2_CLK5
+#define HI6220_MMC2_CIUCLK 6
+#define HI6220_USBOTG_HCLK 7
+#define HI6220_CLK_PICOPHY 8
+#define HI6220_HIFI9
+#define HI6220_DACODEC_PCLK10
+#define HI6220_EDMAC_ACLK  11
+#define HI6220_CS_ATB  12
+#define HI6220_I2C0_CLK13
+#define HI6220_I2C1_CLK14
+#define HI6220_I2C2_CLK15
+#define HI6220_I2C3_CLK16
+#define HI6220_UART1_PCLK  17
+#define HI6220_UART2_PCLK  18
+#define HI6220_UART3_PCLK  19
+#define HI6220_UART4_PCLK  20
+#define HI6220_SPI_CLK 21
+#define HI6220_TSENSOR_CLK 22
+#define HI6220_MMU_CLK 23
+#define HI6220_HIFI_SEL24
+#define HI6220_MMC0_SYSPLL 25
+#define HI6220_MMC1_SYSPLL 26
+#define HI6220_MMC2_SYSPLL 27
+#define HI6220_MMC0_SEL28
+#define HI6220_MMC1_SEL29
+#define HI6220_BBPPLL_SEL  30
+#define HI6220_MEDIA_PLL_SRC   31
+#define HI6220_MMC2_SEL32
+#define HI6220_CS_ATB_SYSPLL   33
+
+/* mux clocks */
+#define HI6220_MMC0_SRC34
+#define HI6220_MMC0_SMP_IN 35
+#define HI6220_MMC1_SRC36
+#define HI6220_MMC1_SMP_IN 37
+#define HI6220_MMC2_SRC38
+#define HI6220_MMC2_SMP_IN 39
+#define HI6220_HIFI_SRC40
+#define HI6220_UART1_SRC   41
+#define HI6220_UART2_SRC   42
+#define HI6220_UART3_SRC   43
+#define HI6220_UART4_SRC   44
+#define HI6220_MMC0_MUX0   45
+#define HI6220_MMC1_MUX0   46
+#define HI6220_MMC2_MUX0   47
+#define HI6220_MMC0_MUX1   48
+#define HI6220_MMC1_MUX1   49
+#define HI6220_MMC2_MUX1   50
+
+/* divider clocks */
+#define HI6220_CLK_BUS 51
+#define HI6220_MMC0_DIV52
+#define HI6220_MMC1_DIV53
+#define HI6220_MMC2_DIV54
+#define HI6220_HIFI_DIV55
+#define HI6220_BBPPLL0_DIV 56
+#define HI6220_CS_DAPB 57
+#define HI6220_CS_ATB_DIV  58
+
+#define HI6220_SYS_NR_CLKS 59
+
+/* clk in Hi6220 media controller */
+/* gate clocks */
+#define HI6220_DSI_PCLK1
+#define HI6220_G3D_PCLK2
+#define HI6220_ACLK_CODEC_VPU  3
+#define 

[PATCH v9 5/6] arm64: dts: Add dts files for Hisilicon Hi6220 SoC

[Bintian Wang]

Add initial dtsi file to support Hisilicon Hi6220 SoC with
support of Octal core CPUs in two clusters and each cluster
has quard Cortex-A53.

Also add dts file to support HiKey development board which
based on Hi6220 SoC.

Signed-off-by: Bintian Wang 
Acked-by: Haojian Zhuang 
Reviewed-by: Yiping Xu 
Tested-by: Will Deacon 
Tested-by: Tyler Baker 
Tested-by: Kevin Hilman 
---
 arch/arm64/boot/dts/Makefile   |1 +
 arch/arm64/boot/dts/hisilicon/Makefile |5 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   31 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  172 
 4 files changed, 209 insertions(+)
 create mode 100644 arch/arm64/boot/dts/hisilicon/Makefile
 create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
 create mode 100644 arch/arm64/boot/dts/hisilicon/hi6220.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index ad26a75..38913be 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -4,6 +4,7 @@ dts-dirs += arm
 dts-dirs += cavium
 dts-dirs += exynos
 dts-dirs += freescale
+dts-dirs += hisilicon
 dts-dirs += mediatek
 dts-dirs += qcom
 dts-dirs += sprd
diff --git a/arch/arm64/boot/dts/hisilicon/Makefile 
b/arch/arm64/boot/dts/hisilicon/Makefile
new file mode 100644
index 000..fa81a6e
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_HISI) += hi6220-hikey.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
new file mode 100644
index 000..e36a539
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -0,0 +1,31 @@
+/*
+ * dts file for Hisilicon HiKey Development Board
+ *
+ * Copyright (C) 2015, Hisilicon Ltd.
+ *
+ */
+
+/dts-v1/;
+
+/*Reserved 1MB memory for MCU*/
+/memreserve/ 0x05e0 0x0010;
+
+#include "hi6220.dtsi"
+
+/ {
+   model = "HiKey Development Board";
+   compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x4000>;
+   };
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
new file mode 100644
index 000..229937f
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -0,0 +1,172 @@
+/*
+ * dts file for Hisilicon Hi6220 SoC
+ *
+ * Copyright (C) 2015, Hisilicon Ltd.
+ */
+
+#include 
+#include 
+
+/ {
+   compatible = "hisilicon,hi6220";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   cpu0: cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   };
+
+   cpu1: cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x1>;
+   enable-method = "psci";
+   };
+
+   cpu2: cpu@2 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   device_type = "cpu";
+   reg = <0x0 0x2>;
+   enable-method = "psci";
+   };
+
+  

[PATCH v9 2/6] arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC

[Bintian Wang]

This patch adds documentation for the devicetree bindings used by the
DT files of Hisilicon hi6220 SoC mobile platform.

Signed-off-by: Bintian Wang 
Suggested-by: Arnd Bergmann 
Acked-by: Haojian Zhuang 
Acked-by: Stephen Boyd 
---
 .../bindings/arm/hisilicon/hisilicon.txt   |   87 
 1 file changed, 87 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 35b1bd4..f67d0f3 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -1,5 +1,8 @@
 Hisilicon Platforms Device Tree Bindings
 
+Hi6220 SoC
+Required root node properties:
+   - compatible = "hisilicon,hi6220";
 
 Hi4511 Board
 Required root node properties:
@@ -13,6 +16,9 @@ HiP01 ca9x2 Board
 Required root node properties:
- compatible = "hisilicon,hip01-ca9x2";
 
+HiKey Board
+Required root node properties:
+   - compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220";
 
 Hisilicon system controller
 
@@ -41,6 +47,87 @@ Example:
};
 
 ---
+Hisilicon Hi6220 system controller
+
+Required properties:
+- compatible : "hisilicon,hi6220-sysctrl"
+- reg : Register address and size
+- #clock-cells: should be set to 1, many clock registers are defined
+  under this controller and this property must be present.
+
+Hisilicon designs this controller as one of the system controllers,
+its main functions are the same as Hisilicon system controller, but
+the register offset of some core modules are different.
+
+Example:
+   /*for Hi6220*/
+   sys_ctrl: sys_ctrl {
+   compatible = "hisilicon,hi6220-sysctrl", "syscon";
+   reg = <0x0 0xf703 0x0 0x2000>;
+   #clock-cells = <1>;
+   };
+
+
+Hisilicon Hi6220 Power Always ON domain controller
+
+Required properties:
+- compatible : "hisilicon,hi6220-aoctrl"
+- reg : Register address and size
+- #clock-cells: should be set to 1, many clock registers are defined
+  under this controller and this property must be present.
+
+Hisilicon designs this system controller to control the power always
+on domain for mobile platform.
+
+Example:
+   /*for Hi6220*/
+   ao_ctrl: ao_ctrl {
+   compatible = "hisilicon,hi6220-aoctrl", "syscon";
+   reg = <0x0 0xf780 0x0 0x2000>;
+   #clock-cells = <1>;
+   };
+
+
+Hisilicon Hi6220 Media domain controller
+
+Required properties:
+- compatible : "hisilicon,hi6220-mediactrl"
+- reg : Register address and size
+- #clock-cells: should be set to 1, many clock registers are defined
+  under this controller and this property must be present.
+
+Hisilicon designs this system controller to control the multimedia
+domain(e.g. codec, G3D ...) for mobile platform.
+
+Example:
+   /*for Hi6220*/
+   media_ctrl: media_ctrl {
+   compatible = "hisilicon,hi6220-mediactrl", "syscon";
+   reg = <0x0 0xf441 0x0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+
+Hisilicon Hi6220 Power Management domain controller
+
+Required properties:
+- compatible : "hisilicon,hi6220-pmctrl"
+- reg : Register address and size
+- #clock-cells: should be set to 1, some clock registers are define
+  under this controller and this property must be present.
+
+Hisilicon designs this system controller to control the power management
+domain for mobile platform.
+
+Example:
+   /*for Hi6220*/
+   pm_ctrl: pm_ctrl {
+   compatible = "hisilicon,hi6220-pmctrl", "syscon";
+   reg = <0x0 0xf7032000 0x0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+---
 Hisilicon HiP01 system controller
 
 Required properties:
-- 
1.7.9.5

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

Re: [PATCH v2 3/6] dt-bindings: brcmstb-gpio: document properties for wakeup

[Brian Norris]

On Fri, May 29, 2015 at 05:57:50PM -0700, Gregory Fong wrote:
> On Fri, May 29, 2015 at 5:36 PM, Brian Norris
>  wrote:
> > On Thu, May 28, 2015 at 07:14:07PM -0700, Gregory Fong wrote:
> >> --- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
> >> +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
> >> @@ -33,6 +33,12 @@ Optional properties:
...
> >>  - #interrupt-cells:
> >>  Should be <2>.  The first cell is the GPIO number, the second should 
> >> specify
> >>  flags.  The following subset of flags is supported:
> >> @@ -48,7 +54,10 @@ Optional properties:
> >>  Marks the device node as an interrupt controller
> >>
> >>  - interrupt-names:
> >> -The name of the IRQ resource used by this controller
> >> +The names of the IRQ resources used by this controller
> >
> > If you're specifying names, you should list them here.
> 
> I was wondering about that.  Some bindings have them listed, some
> don't.  In this case I know what names currently exist but there could
> certainly be different ones in the future.  How does that work?  Or am
> I misunderstanding what this field is used for?  Where are the
> documented rules for this?

The only documentation I see is:
Documentation/devicetree/bindings/resource-names.txt

That documents the basics of the *-names properties, not their expected
usage.

In practice, they're only useful if you have enough optional resources
that fixed indexing isn't sufficient, and you need to use
platform_get_resource_byname().

So IMO, their purposes seems to be one of these:
(1) functional (e.g., for get_resource_byname(), when you have more than
one optional resource)
(2) self-documentation (which might run counter to #1, as you begin
generating too many unique names)
(3) no purpose

So IMO, if you ever want (1), they shouldn't have instance-specific
naming, but should use something generic to the device class. Otherwise,
they are just self-documentation, and aren't functionally useful. So
IMO, these sorts of names:

interrupt-names = "upg_gio_aon", "upg_gio_aon_wakeup";

work better as functional descriptions:

interrupt-names = "gio", "wakeup";

But in the end, I wouldn't foresee you needing to do (1), so you're left
with (2) or (3), at which point I'm not sure if you should even mention
the property.

Just my 2 cents (and those cents may not even be worth face value),
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: DWC3 linux driver query

[sundeep subbaraya]

Hi,

On Fri, May 29, 2015 at 8:35 PM, Felipe Balbi  wrote:
> On Fri, May 29, 2015 at 07:01:16PM +0530, sundeep subbaraya wrote:
>> Hi Felipe,
>>
>> On Thu, May 28, 2015 at 7:41 PM, Felipe Balbi  wrote:
>> > Hi,
>> >
>> > On Thu, May 28, 2015 at 04:53:09PM +0530, sundeep subbaraya wrote:
>> >> Hi Felipe and Paul,
>> >
>> > btw, Paul has left Synopys :-)
>>
>> ahh I see..
>> >
>> >> I am seeing an issue while testing iperf for USB ethernet gadget with
>> >> dwc3 controller in 2.0 mode. After debugging I figured out that:
>> >>
>> >> 1. Network gadget queues say 3 requests. (for IN endpoint)
>> >> 2. It turns out with req.no_interrupt flag,
>> >> DWC3 driver issues START_TRANSFER with req0:IOC, req1, req2:LST
>> >> 3. As per driver state machine, we get XFERNOTREADY then prepare these
>> >> TRBs and issue start transfer. Make Endpoint state as Busy.
>> >> 4. Endpoint state is set to free in XFERINPROGRESS or XFERCOMPLETE event.
>> >> 5. The issue I see here is there are NAKs going to host (seen in
>> >> analyzer) in between req0 and req2 hence XFERNOTREADY(Transfer Active)
>> >> events in between XFERINPROGRESS and  XFERCOMPLETE  events.
>> >> 6. As a result, EP is set as free in XFERINPROGRESS, since EP is free
>> >> start transfer command is issued in XFERNOTREADY handler.The command
>> >> fails since controller did not release the xfer resource yet.
>> >>
>> >> I feel controller behaviour is fine since it sends NAK and writes that
>> >> event. Driver may have to be modified to make EP as free only in
>> >> XFERCOMPLETE event handler (ofcourse not for Isoc).
>> >
>> > this sounds like the correct solution.
>> >
>> >> Note I am testing on a platform which is very slow (the interface
>> >> between DDR and core runs at 4Mhz).
>> >
>> > sweet :-)
>>
>> No it is not :) :). I struggled a lot while debugging :(
>>
>> >
>> >> Where as on Zynq (DWC3 in PL), a faster system compared to above one I
>> >
>> > hey, when will we see a glue layer for Zynq ? :-)
>>
>> we don't have hardware with 2.0 and 3.0 PHY together currently. I will
>> write and test
>> once the hardware is ready :)
>>
>> >
>> >> do not see any NAKs in between Start transfer command and XFERCOMPLETE
>> >> event.
>> >>
>> >> What do you guys say? Do you agree linux driver has to be modified or
>> >> Core should never issue NAKs in between Start transfer and
>> >> XFERCOMPLETE?
>> >
>> > well, if we queued enough transfers, it shouldn't NAK. OTOH, we
>> > shouldn't allow for a new StartTransfer command until all pending
>> > requests have been transferred.
>>
>> Yes correct but the hardware design is very slow here so hitting this case
>> >
>> >> A patch correcting DEPCMD status macros has been applied. Thank you
>> >> Felipe for trace points in driver otherwise it would have taken very
>> >> long time to figure out the root cause :) .
>> >
>> > yeah, those are really helpful :-)
>> >
>> >> Below is the trace log:(enabled only for IN bulk endpoint)
>> >>
>> >>  irq/97-dwc3-1308  [001] d...   553.713513: dwc3_msg: ep1in-bulk
>> >> XFERNOTREADY.Transfer Not Active
>> >>  irq/97-dwc3-1308  [001] d...   553.713768: dwc3_msg: ep1in-bulk:
>> >> req ffc039a68580 dma 011c60a2 length 1558 IOC
>> >>
>> >>  irq/97-dwc3-1308  [001] d...   553.714266: dwc3_msg: ep1in-bulk:
>> >> req ffc039a687c0 dma 011c10a2 length 1558
>> >>
>> >>  irq/97-dwc3-1308  [001] d...   553.714753: dwc3_msg: ep1in-bulk:
>> >> req ffc039a68700 dma 011c18a2 length 1558 last IOC
>> >>
>> >>  irq/97-dwc3-1308  [001] d...   553.717768: dwc3_msg: ep1in-bulk
>> >> XFERNOTREADY.Transfer Active
>> >>  irq/97-dwc3-1308  [001] d...   553.718203: dwc3_msg: ep1in-bulk EP 
>> >> BUSY
>> >>  irq/97-dwc3-1308  [001] d...   553.718412: dwc3_msg: ep1in-bulk
>> >> XFERNOTREADY.Transfer Active
>> >>  irq/97-dwc3-1308  [001] d...   553.718638: dwc3_msg: ep1in-bulk EP 
>> >> BUSY
>> >>  irq/97-dwc3-1308  [001] d...   553.718837: dwc3_msg: ep1in-bulk
>> >> XFERNOTREADY.Transfer Active
>> >>  irq/97-dwc3-1308  [001] d...   553.719049: dwc3_msg: ep1in-bulk EP 
>> >> BUSY
>> >>  irq/97-dwc3-1308  [001] d...   553.719248: dwc3_msg: ep1in-bulk
>> >> XFERINPROGRESS
>> >>  irq/97-dwc3-1308  [001] d...   553.719520: dwc3_msg: request
>> >> ffc039a68580 from ep1in-bulk completed 1558/1558 ===> 0
>> >>
>> >>  irq/97-dwc3-1308  [001] d...   553.720225: dwc3_msg: ep1in-bulk
>> >> XFERNOTREADY.Transfer Active
>> >>  irq/97-dwc3-1308  [001] d...   553.720612: dwc3_msg: ep1in-bulk
>> >> XFERNOTREADY.Transfer Active
>> >>  irq/97-dwc3-1308  [001] d...   553.720826: dwc3_msg: ep1in-bulk EP 
>> >> BUSY
>> >>  irq/97-dwc3-1308  [001] d...   553.721026: dwc3_msg: ep1in-bulk
>> >> XFERNOTREADY.Transfer Active
>> >>  irq/97-dwc3-1308  [001] d...   553.721243: dwc3_msg: ep1in-bulk EP 
>> >> BUSY
>> >>  irq/97-dwc3-1308  [001] d...   553.721446: dwc3_msg: ep1in-bulk
>> >> XFERCOMPLETE
>> >>  irq/97-dwc3-1308  [001] d...   

Re: [PATCH v2 2/6] gpio: brcmstb: Add interrupt support

[Gregory Fong]

On Fri, May 29, 2015 at 5:10 PM, Brian Norris
 wrote:
> A few small comments:
>
> On Thu, May 28, 2015 at 07:14:06PM -0700, Gregory Fong wrote:
>> v2:
>> - since imask member of bank struct was removed, just read and write from 
>> mask
>>   reg and don't maintain a shadow
>
> ^^ this comment may be addressing what I'm going to ask about below? Not
> sure why this was changed, actually.

Yes, see below...

>
>> - warn on invalid IRQs
>> - move some irq setup to a separate function since probe is getting unwieldy
>>
>>  drivers/gpio/Kconfig|   1 +
>>  drivers/gpio/gpio-brcmstb.c | 276 
>> 
>>  2 files changed, 277 insertions(+)
>>
> ...
>> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
>> index 7a3cb1f..b9962ff 100644
>> --- a/drivers/gpio/gpio-brcmstb.c
>> +++ b/drivers/gpio/gpio-brcmstb.c
> ...
>> @@ -63,6 +69,231 @@ brcmstb_gpio_gc_to_priv(struct gpio_chip *gc)
> ...
>> +static void brcmstb_gpio_irq_bank_handler(int irq,
>> + struct brcmstb_gpio_bank *bank)
>> +{
>> + struct brcmstb_gpio_priv *priv = bank->parent_priv;
>> + void __iomem *reg_base = priv->reg_base;
>> + unsigned long status;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(>bgc.lock, flags);
>> + while ((status = bank->bgc.read_reg(reg_base + GIO_STAT(bank->id)) &
>> +  bank->bgc.read_reg(reg_base + GIO_MASK(bank->id {
>
> In case you do run this loop multiple times (multiple interrupts in
> progress?), wouldn't it make sense to stash the mask exactly once,
> outside the loop? It's probably not a real big deal in practice, I
> guess.

I made this change after Linus's remark at
https://lkml.org/lkml/2015/5/12/303 on v1, which I agree with mostly
since it's a premature optimization---I haven't determined whether
keeping a shadow mask actually helps performance at all in practice,
and better to keep it simpler without actual data.

>
>> + int bit;
>> + for_each_set_bit(bit, , 32) {
>> + int hwirq = bank->bgc.gc.base -
>> + priv->gpio_base + bit;
>> + int child_irq =
>> + irq_find_mapping(priv->irq_domain,
>> +  hwirq);
>> + u32 stat = bank->bgc.read_reg(reg_base +
>> +   GIO_STAT(bank->id));
>> + if (bit >= bank->width)
>> + dev_warn(>pdev->dev,
>> +  "IRQ for invalid GPIO (bank=%d, 
>> offset=%d)\n",
>> +  bank->id, bit);
>> + bank->bgc.write_reg(reg_base + GIO_STAT(bank->id),
>> + stat | BIT(bit));
>> + generic_handle_irq(child_irq);
>> + }
>> + }
>> + spin_unlock_irqrestore(>bgc.lock, flags);
>> +}
> ...
>> @@ -153,6 +410,16 @@ static int brcmstb_gpio_probe(struct platform_device 
>> *pdev)
>>   priv->reg_base = reg_base;
>>   priv->pdev = pdev;
>>
>> + if (of_find_property(np, "interrupt-controller", NULL)) {
>
> of_property_read_bool()?

OK.

>
>> + priv->parent_irq = platform_get_irq(pdev, 0);
>> + if (priv->parent_irq < 0) {
>> + dev_err(dev, "Couldn't get IRQ");
>> + return -ENOENT;
>> + }
>> + } else {
>> + priv->parent_irq = -ENOENT;
>> + }
>> +
>>   INIT_LIST_HEAD(>bank_list);
>>   if (brcmstb_gpio_sanity_check_banks(dev, np, res))
>>   return -EINVAL;
>
> Otherwise, looks OK to my inexpert eyes.
>
> Reviewed-by: Brian Norris 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo

[Alexei Starovoitov]

On 5/29/15 4:55 PM, Masami Hiramatsu wrote:
> On 2015/05/29 15:30, He Kuang wrote:
>> hi, Alexei
>>
>> On 2015/5/29 2:10, Alexei Starovoitov wrote:
>>> On 5/28/15 6:01 AM, He Kuang wrote:
> I don't think you can break it down in two steps like this.
>> There is no such thing as 'calling regs'. x86_32 with ax,dx,cx
>> are not 'calling regs'. 64-bit values will be passed in a pair.
>> Only 'pt_regs + arch + func_proto + asmlinkage' makes sense
> >from the user point of view.
>> Adding 'asmlinkage' attr is also trivial.
>> 'func(long, char) asmlinkage' is easy to parse and the user
 I think at this early stage, we could make our bpf variable
 prologue work with debuginfo while keeping bpf 'SEC' syntax
 consistent with original perf probe. After all, we can use
 pt_regs directly or relay to perf-probe cache by Masami to deal
 with non-debug cases.
>>>
>>> so you're saying you don't want to support non-debug case for now?
>>> Sure, as long as section name parser will be able to support
>>> 'func(long, char) asmlinkage' syntax in the future without breaking
>>> compatibility. I'm mostly interested in cases when debug info
>>> is not available at all. So perf-probe cache is of no use to me.
>>>
>>>
>>
>> Yes, that syntax do deal with the situation which current 'perf
>> probe' syntax not covered, so not only bpf prologue would benifit
>> from that, maybe we could try to let perf probe involve that.
> 
> Hmm, then how about below syntax?
> 
>   perf probe x86_acpi_enter_sleep_state $regparams:asmlinkage(char)
> 
> So, regparams has following synopsis.
> 
>   $regparams[:[asmlinkage|0-6]([u8|u16|u32|u64|ptr][,...])]

the number doesn't make sense in generic command. Only x86_32 plays
with calling convention. All other archs are not doing anything special
for asmlinkage.
I think the following is enough:
$regparams[[:asmlinkage]([u8|u16|u32|u64|ptr|char|short|long|
long long|void*][,...])]
asmlinkage most of the time won't be used and typical command will look
like: 'func=func $regparams(char, long, void*)'
which is ok for kprobe.
For bpf section name I would still prefer 'func(char, long, void*)'
since it's more concise, easier to remember, more similar to C declaration.

> Note that asmlinkage is a synonym of 0, and default depends on arch :)
> Some architecture ignores this part, e.g. x86_64 always uses regs.
> And it is automatically expanded to argX="%reg or $stackX".
> 
> e.g.
>   $regparams is expanded to
>arg1=%di arg2=%si arg3=%dx arg4=%cx arg5=%r8 arg6=%r9 (on x86_64)
>arg1=%ax arg2=%dx arg3=%cx arg4=$stack1 arg5=$stack2 arg6=$stack3 (on i386)
> 
>   $regparams:0 is expanded to
>arg1=%di arg2=%si arg3=%dx arg4=%cx arg5=%r8 arg6=%r9 (on x86_64)
>arg1=$stack1 arg2=$stack2 arg3=$stack3 arg4=$stack4 arg5=$stack5 
> arg6=$stack6 (on i386)
> 
>   $regparams:3(char,long) is expanded to
>arg1=%di:s8 arg2=%si:s64 (on x86_64)
>arg1=%ax:s8 arg2=%dx:s64 (on i386)
> 
> How is this?
> 
> Thank you,
> 
> 

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

Re: [PATCH v11 12/12] drivers/block/pmem: Map NVDIMM with ioremap_wt()

[Dan Williams]

On Fri, May 29, 2015 at 3:59 PM, Toshi Kani  wrote:
> From: Toshi Kani 
>
> The pmem driver maps NVDIMM with ioremap_nocache() as we cannot
> write back the contents of the CPU caches in case of a crash.
>
> This patch changes to use ioremap_wt(), which provides uncached
> writes but cached reads, for improving read performance.
>
> Signed-off-by: Toshi Kani 

Acked-by: Dan Williams 

...with the caveat that I'm going to follow in behind this series with
generic ioremap_cache() enabling and converting pmem to use
persistent_copy() / persistent_sync() when the arch/cpu has persistent
memory synchronization instructions.  After the conversion
ioremap_wt() will still be there for the non-persistent_sync() capable
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: [tip:sched/core] sched/core: Validate rq_clock*() serialization

[Sasha Levin]

On 01/14/2015 09:03 AM, tip-bot for Peter Zijlstra wrote:
> Commit-ID:  cebde6d681aa45f96111cfcffc1544cf2a0454ff
> Gitweb: http://git.kernel.org/tip/cebde6d681aa45f96111cfcffc1544cf2a0454ff
> Author: Peter Zijlstra 
> AuthorDate: Mon, 5 Jan 2015 11:18:10 +0100
> Committer:  Ingo Molnar 
> CommitDate: Wed, 14 Jan 2015 13:34:19 +0100
> 
> sched/core: Validate rq_clock*() serialization
> 
> rq->clock{,_task} are serialized by rq->lock, verify this.
> 
> One immediate fail is the usage in scale_rt_capability, so 'annotate'
> that for now, there's more 'funny' there. Maybe change rq->lock into a
> raw_seqlock_t?
> 
> (Only 32-bit is affected)
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> Link: http://lkml.kernel.org/r/20150105103554.361872...@infradead.org
> Cc: Linus Torvalds 
> Cc: umgwanakikb...@gmail.com
> Signed-off-by: Ingo Molnar 
> ---

Hey Peter,

I'm seeing the following in the latest -next:

[ 2706.857941] [ cut here ]
[ 2706.857963] WARNING: CPU: 6 PID: 14780 at kernel/sched/sched.h:728 
update_curr+0x3db/0x550()
[ 2706.857971] Modules linked in:
[ 2706.857982] CPU: 6 PID: 14780 Comm: trinity-c2 Not tainted 
4.1.0-rc5-next-20150529-sasha-00039-g7fd455d-dirty #2262
[ 2706.858000]  a6a1426a c9f98986 8802b6807b98 
a6a1426a
[ 2706.858015]    8802b6807be8 
9d1e50c6
[ 2706.858029]  9d1e52f5 9d28a2fb 8800c3d0b068 
88050c1c3068
[ 2706.858033] Call Trace:
[ 2706.858054]  ? dump_stack (lib/dump_stack.c:52)
[ 2706.858064] dump_stack (lib/dump_stack.c:52)
[ 2706.858077] warn_slowpath_common (kernel/panic.c:448)
[ 2706.858085] ? warn_slowpath_null (kernel/panic.c:479)
[ 2706.858092] ? update_curr (kernel/sched/sched.h:728 kernel/sched/fair.c:698)
[ 2706.858102] warn_slowpath_null (kernel/panic.c:482)
[ 2706.858110] update_curr (kernel/sched/sched.h:728 kernel/sched/fair.c:698)
[ 2706.858116] ? update_curr (kernel/sched/fair.c:697)
[ 2706.858128] task_tick_fair (include/linux/sched.h:3049 
kernel/sched/fair.c:397 kernel/sched/fair.c:2795 kernel/sched/fair.c:3372 
kernel/sched/fair.c:8000)
[ 2706.858141] ? sched_clock_cpu (kernel/sched/clock.c:315)
[ 2706.858151] ? task_tick_fair (kernel/sched/fair.c:7994)
[ 2706.858162] scheduler_tick (kernel/sched/core.c:2523)
[ 2706.858177] update_process_times (kernel/time/timer.c:1399)
[ 2706.858188] tick_sched_handle.isra.12 (kernel/time/tick-sched.c:152)
[ 2706.858196] ? tick_sched_handle.isra.12 (kernel/time/tick-sched.c:134)
[ 2706.858206] tick_sched_timer (kernel/time/tick-sched.c:1075)
[ 2706.858217] __hrtimer_run_queues (kernel/time/hrtimer.c:1138 
kernel/time/hrtimer.c:1194)
[ 2706.858228] ? ftrace_call (arch/x86/kernel/mcount_64.S:158)
[ 2706.858237] ? tick_sched_do_timer (kernel/time/tick-sched.c:1059)
[ 2706.858246] ? hrtimer_fixup_init (kernel/time/hrtimer.c:1161)
[ 2706.858256] ? __hrtimer_run_queues (kernel/time/hrtimer.c:1161)
[ 2706.858267] hrtimer_interrupt (kernel/time/hrtimer.c:1231)
[ 2706.858281] ? preempt_schedule_context (kernel/sched/core.c:2941 
(discriminator 1) include/linux/jump_label.h:125 (discriminator 1) 
include/linux/context_tracking_state.h:29 (discriminator 1) 
include/linux/context_tracking.h:34 (discriminator 1) kernel/sched/core.c:2947 
(discriminator 1))
[ 2706.858293] local_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:891)
[ 2706.858301] ? local_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:863)
[ 2706.858311] smp_apic_timer_interrupt (./arch/x86/include/asm/apic.h:655 
arch/x86/kernel/apic/apic.c:915)
[ 2706.858323] apic_timer_interrupt (arch/x86/kernel/entry_64.S:911)
[ 2706.858332]  
[ 2706.858333] ---[ end trace b7e04749c55c3d4e ]---


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/6] dt-bindings: brcmstb-gpio: document properties for wakeup

[Gregory Fong]

On Fri, May 29, 2015 at 5:36 PM, Brian Norris
 wrote:
> On Thu, May 28, 2015 at 07:14:07PM -0700, Gregory Fong wrote:
>> Some brcmstb GPIO controllers can be used to wake from suspend, so use the
>> de facto standard property 'wakeup-source' to mark the nodes of controllers
>> with that capability.
>>
>> Also document interrupts-extended, which will be used for wakeup handling
>> because the interrupt parent for the wake IRQ is different from the regular
>> IRQ.
>>
>> Signed-off-by: Gregory Fong 
>> ---
>> New in v2.
>>
>>  .../devicetree/bindings/gpio/brcm,brcmstb-gpio.txt | 26 
>> +-
>>  1 file changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt 
>> b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
>> index 435f1bc..568814f 100644
>> --- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
>> +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
>> @@ -33,6 +33,12 @@ Optional properties:
>>  - interrupt-parent:
>>  phandle of the parent interrupt controller
>>
>> +- interrupts-extended:
>> +Alternate form of specifying interrupts and parents that allows for
>> +multiple parents.  This takes precedence over 'interrupts' and
>> +'interrupt-parent'.  This probably must be used if the wakeup-source
>> +property is provided because that may have a different interrupt parent.
>> +
>
> "This probably must be used" seems a little awkward, especially when
> you're just explaining an implementation detail of our SoCs, rather than
> something unique about this binding. Maybe:
>
>   "Wakeup-capable GPIO controllers often route their wakeup interrupt
>   lines through a different interrupt controller than the primary
>   interrupt line, making this property necessary."

That wording does seem better, will change.

>
>>  - #interrupt-cells:
>>  Should be <2>.  The first cell is the GPIO number, the second should 
>> specify
>>  flags.  The following subset of flags is supported:
>> @@ -48,7 +54,10 @@ Optional properties:
>>  Marks the device node as an interrupt controller
>>
>>  - interrupt-names:
>> -The name of the IRQ resource used by this controller
>> +The names of the IRQ resources used by this controller
>
> If you're specifying names, you should list them here.

I was wondering about that.  Some bindings have them listed, some
don't.  In this case I know what names currently exist but there could
certainly be different ones in the future.  How does that work?  Or am
I misunderstanding what this field is used for?  Where are the
documented rules for this?

>
>> +
>> +- wakeup-source:
>> +GPIOs for this controller can be used as a wakeup source
>>
>>  Example:
>>   upg_gio: gpio@f040a700 {
>> @@ -63,3 +72,18 @@ Example:
>>   interrupt-names = "upg_gio";
>>   brcm,gpio-bank-widths = <0x20 0x20 0x20 0x18>;
>>   };
>> +
>> + upg_gio_aon: gpio@f04172c0 {
>> + #gpio-cells = <0x2>;
>> + #interrupt-cells = <0x2>;
>
> Might use decimal instead of hex for the above 2 lines?

Sure.

>
>> + compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
>> + gpio-controller;
>> + interrupt-controller;
>> + reg = <0xf04172c0 0x40>;
>> + interrupt-parent = <0xc>;
>
> That should be a phandle, not an int (I realize phandles resolve down to
> an integer, but we're speaking DTS, not DTB).

OK.

>
>> + interrupts = <0x6>;
>> + interrupts-extended = <0xc 0x6 0xa 0x5>;
>
> Same here (phandles).
>
> Also, even though the interrupt binding semantics specify precedence
> between interrupts and interrupts-extended, I'd think an example should
> stick to one or the other, no?

This is the output that we actually get from the bootloader.  But
regardless, IMO the example should have both cases: precedence is
well-defined, both sets of information are valid, and the driver can
handle the case where interrupts-extended is not an understood
property.

>
>> + interrupt-names = "upg_gio_aon", "upg_gio_aon_wakeup";
>> + wakeup-source;
>> + brcm,gpio-bank-widths = <0x12 0x4>;
>> + };
>
> Reviewed-by: Brian Norris 

Thanks for the review,
Gregory
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / Wakeirq: Fix typo in prototype for dev_pm_set_dedicated_wake_irq

[Rafael J. Wysocki]

On Friday, May 29, 2015 12:18:37 PM Felipe Balbi wrote:
> 
> --2fjX3cMESU3XgGmZ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Fri, May 29, 2015 at 09:54:02AM -0700, Tony Lindgren wrote:
> > Looks like I only built test the dev_pm_set_wake_irq and not the
> > dev_pm_set_dedicated_wake_irq case on x86.
> >=20
> > Turns out there's a typo for the dev_pm_set_dedicated_wake_irq
> > prototype that causes a build error if CONFIG_COMPILE_TEST
> > and CONFIG_MMC_OMAP_HS are selected.
> >=20
> > Cc: Stephen Rothwell 
> > Cc: Ulf Hansson 
> > Reported-by: Jim Davis 
> > Signed-off-by: Tony Lindgren 
> 
> cool:
> 
> Reviewed-by: Felipe Balbi 

Applied, thanks!


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

Re: [PATCH v8 0/7] arm64,hi6220: Enable Hisilicon Hi6220 SoC

[Bintian]

Hello Kevin,

On 2015/5/30 7:00, Kevin Hilman wrote:

Hi Bintian,

Bintian Wang  writes:


From: Bintian Wang 

Hi6220 is one mobile solution of Hisilicon, this patchset contains
initial support for Hi6220 SoC and HiKey development board, which
supports octal ARM Cortex A53 cores. Initial support is minimal and
includes just the arch configuration, clock driver, device tree
configuration.

PSCI is enabled in device tree and there is no problem to boot all the
octal cores, and the CPU hotplug is also working now, you can download
and compile the latest firmware based on the following link to run this
patch set:
https://github.com/96boards/documentation/wiki/UEFI

Changes v6~v8:
This three versions only modified the clock drivers based on the
Stephen's review advices.
* clk-hi6220.c:
   ** Split the clock header file from clock driver
   ** Delete setting the parents clock of UART1 to HI6220_150M in clock
  driver, we can do that using assigned-clock in dts when enable
  UART1 in the future.
* clkdivider-hi6220.c:
   ** Reuse some functions exported by clk-divider.c
   ** Remove "pr_err" and CLK_IS_BASIC flag
   ** Fix some programing style problems
* hisilicon/clk.h: remove the "__init" markings on some funcition
   prototypes.


It's not clear what kernel this series is meant to apply to.  It doesn't
apply cleanly to v4.1-rc2 (the version stated for v5) or the current -rc
(v4.1-rc5) it also doesn't apply cleanly to linus/master or linux-next.

If the series doesn't apply to Linus tree, please state clearly in the
changelog what tree it should apply to as well as any dependncies.

Also, this version is missing patch 1 from the v6 series, which adds the
Kconfig/defconfig changes. Without that patch, nothing in this series is
even compiled (clk driver or DTS files.)

So my recommendation, since the clock driver is very close to being
merged:

Please create a v9 series with *only* the patches that are not already
queued up on the clk tree[1].  That should be patches 1-3 and 7 of this
series, plus patch 1 from v6.

That series should apply cleanly to v4.1-rc1 (or a newer -rc if there
are dependencies.)  In the changelog to that series, state the version
that it applies to, and also state that it depends on the clk-next
branch where the clock maintainers have queued up the driver[1].

Then all that's left is to collect an ack from a DT maintainer, and
these can be queued up via the arm-soc tree.

FWIW, I've boot tested patches 1-3 and 7 of this series, plus patch 1
from v6 combined with the clk-next-hi6220 branch[1] on my board (which
uses ATF + mainline u-boot) and all 8 A53 cores are coming up, so feel
free to add:

Tested-by: Kevin Hilman 

to your v9 series.

Very good and detailed instructions, I will prepare the v9 soon.

Thanks,

Bintian


Thanks,

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next-hi6220

.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/6] gpio: brcmstb: Allow GPIOs to be wakeup sources

[Brian Norris]

On Thu, May 28, 2015 at 07:14:08PM -0700, Gregory Fong wrote:
> Several drivers (e.g. gpio-keys) allow for GPIOs to be configured as
> wakeup sources, and this GPIO controller supports that through a
> separate interrupt path.
> 
> The de-facto standard DT property "wakeup-source" is checked, since
> that indicates whether the GPIO controller hardware can wake.  Uses
> the IRQCHIP_MASK_ON_SUSPEND irq_chip flag because UPG GIO doesn't have
> any of its own wakeup source configuration.
> 
> Signed-off-by: Gregory Fong 
> ---
> New in v2.
> 
>  drivers/gpio/gpio-brcmstb.c | 53 
> +
>  1 file changed, 53 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
> index b9962ff..2598c1e 100644
> --- a/drivers/gpio/gpio-brcmstb.c
> +++ b/drivers/gpio/gpio-brcmstb.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define GIO_BANK_SIZE   0x20
>  #define GIO_ODEN(bank)  (((bank) * GIO_BANK_SIZE) + 0x00)
> @@ -48,6 +49,7 @@ struct brcmstb_gpio_priv {
>   struct irq_domain *irq_domain;
>   int parent_irq;
>   int gpio_base;
> + int parent_wake_irq;
>  };
>  
>  #define MAX_GPIO_PER_BANK   32
> @@ -183,6 +185,31 @@ static int brcmstb_gpio_irq_set_type(struct irq_data *d, 
> unsigned int type)
>   return 0;
>  }
>  
> +static int brcmstb_gpio_irq_set_wake(struct irq_data *d, unsigned int enable)
> +{
> + struct brcmstb_gpio_bank *bank = irq_data_get_irq_chip_data(d);
> + struct brcmstb_gpio_priv *priv = bank->parent_priv;
> +
> + /*
> +  * Only enable wake IRQ once for however many hwirqs can wake
> +  * since they all use the same wake IRQ.  Mask will be set
> +  * up appropriately thanks to IRQCHIP_MASK_ON_SUSPEND flag.
> +  */
> + if (enable)
> + enable_irq_wake(priv->parent_wake_irq);
> + else
> + disable_irq_wake(priv->parent_wake_irq);
> + return 0;
> +}
> +
> +static irqreturn_t brcmstb_gpio_wake_irq_handler(int irq, void *data)
> +{
> + struct brcmstb_gpio_priv *priv = data;
> +
> + pm_wakeup_event(>pdev->dev, 0);
> + return IRQ_HANDLED;
> +}
> +
>  static void brcmstb_gpio_irq_bank_handler(int irq,
>   struct brcmstb_gpio_bank *bank)
>  {
> @@ -369,6 +396,32 @@ static int brcmstb_gpio_irq_setup(struct platform_device 
> *pdev,
>   priv->irq_chip.irq_mask = brcmstb_gpio_irq_mask;
>   priv->irq_chip.irq_unmask = brcmstb_gpio_irq_unmask;
>   priv->irq_chip.irq_set_type = brcmstb_gpio_irq_set_type;
> +
> + /* Ensures that all non-wakeup IRQs are disabled at suspend */
> + priv->irq_chip.flags = IRQCHIP_MASK_ON_SUSPEND;
> +
> + if (IS_ENABLED(CONFIG_PM_SLEEP) &&
> + of_get_property(np, "wakeup-source", NULL)) {

of_property_read_bool()?

> + priv->parent_wake_irq = platform_get_irq(pdev, 1);
> + if (priv->parent_wake_irq < 0)  {
> + dev_warn(dev,
> + "Couldn't get wake IRQ - GPIOs will not be able 
> to wake from sleep");
> + } else {
> + int err = devm_request_irq(dev, priv->parent_wake_irq,
> + brcmstb_gpio_wake_irq_handler, 0,
> + "brcmstb-gpio-wake", priv);
> +
> + if (err < 0) {
> + dev_err(dev, "Couldn't request wake IRQ");
> + return err;
> + }
> +
> + device_set_wakeup_capable(dev, true);
> + device_wakeup_enable(dev);

Might want to move these two lines above the devm_request_irq(), so that
you're ready to record PM events immediately at probe time. This is
important when waking from S5 states, where we sometimes want to be able
to check the /sys/devices/.../wakeup_count stats to see what woke us up.

> + priv->irq_chip.irq_set_wake = brcmstb_gpio_irq_set_wake;
> + }
> + }
> +
>   priv->irq_domain =
>   irq_domain_add_linear(np, priv->num_gpios,
> _gpio_irq_domain_ops,

With that:

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

[Notice] ACPI core and PM core maintenance in travel mode until June 7

[Rafael J. Wysocki]

Hi All,

In the next few days I'll be traveling for LinuxCon Japan starting tomorrow.

I'll do my best to keep up with the patch flow during that time, but that
usually is hard for me during conferences, so please be prepared for extra
delays.

Kind regards,
Rafael

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

Re: [PATCH v2 3/6] dt-bindings: brcmstb-gpio: document properties for wakeup

[Brian Norris]

On Thu, May 28, 2015 at 07:14:07PM -0700, Gregory Fong wrote:
> Some brcmstb GPIO controllers can be used to wake from suspend, so use the
> de facto standard property 'wakeup-source' to mark the nodes of controllers
> with that capability.
> 
> Also document interrupts-extended, which will be used for wakeup handling
> because the interrupt parent for the wake IRQ is different from the regular
> IRQ.
> 
> Signed-off-by: Gregory Fong 
> ---
> New in v2.
> 
>  .../devicetree/bindings/gpio/brcm,brcmstb-gpio.txt | 26 
> +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt 
> b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
> index 435f1bc..568814f 100644
> --- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
> @@ -33,6 +33,12 @@ Optional properties:
>  - interrupt-parent:
>  phandle of the parent interrupt controller
>  
> +- interrupts-extended:
> +Alternate form of specifying interrupts and parents that allows for
> +multiple parents.  This takes precedence over 'interrupts' and
> +'interrupt-parent'.  This probably must be used if the wakeup-source
> +property is provided because that may have a different interrupt parent.
> +

"This probably must be used" seems a little awkward, especially when
you're just explaining an implementation detail of our SoCs, rather than
something unique about this binding. Maybe:

  "Wakeup-capable GPIO controllers often route their wakeup interrupt
  lines through a different interrupt controller than the primary
  interrupt line, making this property necessary."

>  - #interrupt-cells:
>  Should be <2>.  The first cell is the GPIO number, the second should 
> specify
>  flags.  The following subset of flags is supported:
> @@ -48,7 +54,10 @@ Optional properties:
>  Marks the device node as an interrupt controller
>  
>  - interrupt-names:
> -The name of the IRQ resource used by this controller
> +The names of the IRQ resources used by this controller

If you're specifying names, you should list them here.

> +
> +- wakeup-source:
> +GPIOs for this controller can be used as a wakeup source
>  
>  Example:
>   upg_gio: gpio@f040a700 {
> @@ -63,3 +72,18 @@ Example:
>   interrupt-names = "upg_gio";
>   brcm,gpio-bank-widths = <0x20 0x20 0x20 0x18>;
>   };
> +
> + upg_gio_aon: gpio@f04172c0 {
> + #gpio-cells = <0x2>;
> + #interrupt-cells = <0x2>;

Might use decimal instead of hex for the above 2 lines?

> + compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
> + gpio-controller;
> + interrupt-controller;
> + reg = <0xf04172c0 0x40>;
> + interrupt-parent = <0xc>;

That should be a phandle, not an int (I realize phandles resolve down to
an integer, but we're speaking DTS, not DTB).

> + interrupts = <0x6>;
> + interrupts-extended = <0xc 0x6 0xa 0x5>;

Same here (phandles).

Also, even though the interrupt binding semantics specify precedence
between interrupts and interrupts-extended, I'd think an example should
stick to one or the other, no?

> + interrupt-names = "upg_gio_aon", "upg_gio_aon_wakeup";
> + wakeup-source;
> + brcm,gpio-bank-widths = <0x12 0x4>;
> + };

Reviewed-by: Brian Norris 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/17] video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()

[Luis R. Rodriguez]

On Fri, May 29, 2015 at 08:41:44AM +0200, Ingo Molnar wrote:
> 
> * Luis R. Rodriguez  wrote:
> 
> > +   gbe_mem = devm_ioremap_wc(_dev->dev, gbe_mem_phys,
> > + gbe_mem_size);
> 
> > +   gbe_mem = dma_alloc_writecombine(NULL, gbe_mem_size,
> > +_dma_addr, GFP_KERNEL);
> 
> > +   par->wc_cookie = arch_phys_wc_add(gbe_mem_phys, gbe_mem_size);
> 
> > +   arch_phys_wc_del(par->wc_cookie);
> 
> > +   arch_phys_wc_del(par->wc_cookie);
> 
> Could we _please_ rename dma_*_writecombine() to dma_*_wc(), so that the 
> naming is 
> coherent across the various APIs?

Sure, OK done. Will send once this series is merged and visible on linux-next.
But who's tree should this go through? Since it depends on this series which
goes through Tomi's tree should it go through there?

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3] ARM: dts: odroidxu3: Enable USB3 regulators

[Krzysztof Kozlowski]

W dniu 29.05.2015 o 23:30, Anand Moon pisze:
> Enable regulator for usbdrd3_0 and usbdrd3_1.
> Looking at the schematic pin diagram for MAX77802
> USB3_0 and USB3_1 is regulated by LDO9 and LD011.
> 
> Fix the boot message of failed.
> [3.503539] exynos-dwc3 usb@1200: Looking up vdd33-supply from device 
> tree
> [3.503556] exynos-dwc3 usb@1200: Looking up vdd33-supply property in 
> node /usb@1200 failed
> [3.503568] usb@1200 supply vdd33 not found, using dummy regulator
> [3.509154] exynos-dwc3 usb@1200: Looking up vdd10-supply from device 
> tree
> [3.509170] exynos-dwc3 usb@1200: Looking up vdd10-supply property in 
> node /usb@1200 failed
> [3.509181] usb@1200 supply vdd10 not found, using dummy regulator
> [3.917548] exynos-dwc3 usb@1240: Looking up vdd33-supply from device 
> tree
> [3.917565] exynos-dwc3 usb@1240: Looking up vdd33-supply property in 
> node /usb@1240 failed
> [3.917578] usb@1240 supply vdd33 not found, using dummy regulator
> [3.922731] exynos-dwc3 usb@1240: Looking up vdd10-supply from device 
> tree
> [3.922747] exynos-dwc3 usb@1240: Looking up vdd10-supply property in 
> node /usb@1240 failed
> 
> Tested-by: Krzysztof Kozlowski 
> Signed-off-by: Anand Moon 

Looks good now, thanks.

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: Add generic driver for Zeitec touchscreens

[Dmitry Torokhov]

Hi Bogdan,

On Thu, May 28, 2015 at 03:22:02PM +0300, Bogdan George Stefan wrote:
> This driver adds support for Zeitec touchscreens. It has
> been tested with ZET6273 and ZET9172.
> 
> It supports ACPI and device tree enumeration. For ACPI you need ACPI
> 5.1+ in order to be able to use named GPIOs.
> 
> Screen resolution, the maximum number of fingers supported,
> if the touchscreen has hardware keys are configurable
> using ACPI/DT properties.
> 
> Signed-off-by: Bogdan George Stefan 
> ---
> Changes since v1:
> 
> Implemented most changes following Dmitry Torokhov's recommendations
> from https://lkml.org/lkml/2015/5/15/319
> The only things I kept are described below in the Notes section.
> - fixed style issues
> - reset is activated when gpio is set to high
> - switched from i2c_transfer to i2c_master_recv/i2c_master_send
> - removed redundant evbit initialization. However EV_ABS still needs
> to be reported and it is set through input_set_capability
> - replaced usleep_range with msleep where neede. Checking the patch
> with -strict will report an issue on this. Hope this is not a problem
> - fixed casts in zet_process_events
> - removed  client->irq = gpiod_to_irq(ts->irq); from probe
> - moved firmware loading from probe to open
> - used proper casts in zet_suspend
> - dropped zet_ts_remove as it was doing unnecesary things
> Notes:
> - I've kept the flags IRQF_TRIGGER_FALLING | IRQF_ONESHOT when calling
> devm_request_threaded_irq. No the irq handler is not called whn only 
> IRQF_ONESHOT
> is used. Looking at other drivers, I saw that they use the same aproach. I am 
> not
> sure how to setup things in ACPI/DT so that the driver could work only with 
> IRQF_ONESHOT

Hmm, Rafael, do ACPI systems automatically set up IRQ triggers,
similarly to what OF systems do (based on device tree data)?

> - The number of thingers that can simultaneously touch the device and if it 
> has
> HW keys or not, cannot be read from the device. I've asked Zeitec on this.

According to a random Zeitec datasheet I found on the web you send 0xB2
command to the device to retrieve buch of information, including number
of fingers and whether keys are supported.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] gpio: brcmstb: Add interrupt support

[Brian Norris]

A few small comments:

On Thu, May 28, 2015 at 07:14:06PM -0700, Gregory Fong wrote:
> v2:
> - since imask member of bank struct was removed, just read and write from mask
>   reg and don't maintain a shadow

^^ this comment may be addressing what I'm going to ask about below? Not
sure why this was changed, actually.

> - warn on invalid IRQs
> - move some irq setup to a separate function since probe is getting unwieldy
> 
>  drivers/gpio/Kconfig|   1 +
>  drivers/gpio/gpio-brcmstb.c | 276 
> 
>  2 files changed, 277 insertions(+)
> 
...
> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
> index 7a3cb1f..b9962ff 100644
> --- a/drivers/gpio/gpio-brcmstb.c
> +++ b/drivers/gpio/gpio-brcmstb.c
...
> @@ -63,6 +69,231 @@ brcmstb_gpio_gc_to_priv(struct gpio_chip *gc)
...
> +static void brcmstb_gpio_irq_bank_handler(int irq,
> + struct brcmstb_gpio_bank *bank)
> +{
> + struct brcmstb_gpio_priv *priv = bank->parent_priv;
> + void __iomem *reg_base = priv->reg_base;
> + unsigned long status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>bgc.lock, flags);
> + while ((status = bank->bgc.read_reg(reg_base + GIO_STAT(bank->id)) &
> +  bank->bgc.read_reg(reg_base + GIO_MASK(bank->id {

In case you do run this loop multiple times (multiple interrupts in
progress?), wouldn't it make sense to stash the mask exactly once,
outside the loop? It's probably not a real big deal in practice, I
guess.

> + int bit;
> + for_each_set_bit(bit, , 32) {
> + int hwirq = bank->bgc.gc.base -
> + priv->gpio_base + bit;
> + int child_irq =
> + irq_find_mapping(priv->irq_domain,
> +  hwirq);
> + u32 stat = bank->bgc.read_reg(reg_base +
> +   GIO_STAT(bank->id));
> + if (bit >= bank->width)
> + dev_warn(>pdev->dev,
> +  "IRQ for invalid GPIO (bank=%d, 
> offset=%d)\n",
> +  bank->id, bit);
> + bank->bgc.write_reg(reg_base + GIO_STAT(bank->id),
> + stat | BIT(bit));
> + generic_handle_irq(child_irq);
> + }
> + }
> + spin_unlock_irqrestore(>bgc.lock, flags);
> +}
...
> @@ -153,6 +410,16 @@ static int brcmstb_gpio_probe(struct platform_device 
> *pdev)
>   priv->reg_base = reg_base;
>   priv->pdev = pdev;
>  
> + if (of_find_property(np, "interrupt-controller", NULL)) {

of_property_read_bool()?

> + priv->parent_irq = platform_get_irq(pdev, 0);
> + if (priv->parent_irq < 0) {
> + dev_err(dev, "Couldn't get IRQ");
> + return -ENOENT;
> + }
> + } else {
> + priv->parent_irq = -ENOENT;
> + }
> +
>   INIT_LIST_HEAD(>bank_list);
>   if (brcmstb_gpio_sanity_check_banks(dev, np, res))
>   return -EINVAL;

Otherwise, looks OK to my inexpert eyes.

Reviewed-by: Brian Norris 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] ipc,msg: provide barrier pairings for lockless receive

[Davidlohr Bueso]

We currently use a full barrier on the sender side to
to avoid receiver tasks disappearing on us while still
performing on the sender side wakeup. We lack however,
the proper CPU-CPU interactions pairing on the receiver
side which busy-waits for the message. Similarly, we do
not need a full smp_mb, and can relax the semantics for
the writer and reader sides of the message. This is safe
as we are only ordering loads and stores to r_msg. And in
both smp_wmb and smp_rmb, there are no stores after the
calls _anyway_.

This obviously applies for pipelined_send and expunge_all,
for EIRDM when destroying a queue.

Signed-off-by: Davidlohr Bueso 
---
 ipc/msg.c | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/ipc/msg.c b/ipc/msg.c
index 2b6fdbb..ac5116e 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -196,7 +196,7 @@ static void expunge_all(struct msg_queue *msq, int res)
 * or dealing with -EAGAIN cases. See lockless receive part 1
 * and 2 in do_msgrcv().
 */
-   smp_mb();
+   smp_wmb();
msr->r_msg = ERR_PTR(res);
}
 }
@@ -580,7 +580,7 @@ static inline int pipelined_send(struct msg_queue *msq, 
struct msg_msg *msg)
/* initialize pipelined send ordering */
msr->r_msg = NULL;
wake_up_process(msr->r_tsk);
-   smp_mb(); /* see barrier comment below */
+   smp_wmb(); /* see barrier comment below */
msr->r_msg = ERR_PTR(-E2BIG);
} else {
msr->r_msg = NULL;
@@ -589,11 +589,12 @@ static inline int pipelined_send(struct msg_queue *msq, 
struct msg_msg *msg)
wake_up_process(msr->r_tsk);
/*
 * Ensure that the wakeup is visible before
-* setting r_msg, as the receiving end depends
-* on it. See lockless receive part 1 and 2 in
-* do_msgrcv().
+* setting r_msg, as the receiving can otherwise
+* exit - once r_msg is set, the receiver can
+* continue. See lockless receive part 1 and 2
+* in do_msgrcv().
 */
-   smp_mb();
+   smp_wmb();
msr->r_msg = msg;
 
return 1;
@@ -934,10 +935,22 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, 
long msgtyp, int msgfl
 * wake_up_process(). There is a race with exit(), see
 * ipc/mqueue.c for the details.
 */
-   msg = (struct msg_msg *)msr_d.r_msg;
-   while (msg == NULL) {
-   cpu_relax();
+   for (;;) {
+   /*
+* Pairs with writer barrier in pipelined_send
+* or expunge_all
+*/
+   smp_rmb();
msg = (struct msg_msg *)msr_d.r_msg;
+   if (msg)
+   break;
+
+   /*
+* The cpu_relax() call is a compiler barrier
+* which forces everything in this loop to be
+* re-loaded.
+*/
+   cpu_relax();
}
 
/* Lockless receive, part 3:
-- 
2.1.4

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

[PATCH 1/2] ipc,shm: move BUG_ON check into shm_lock

[Davidlohr Bueso]

Upon every shm_lock call, we BUG_ON if an error was returned,
indicating racing either in idr or in RMID. Move this logic
into the locking.

Signed-off-by: Davidlohr Bueso 
---
 ipc/shm.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/ipc/shm.c b/ipc/shm.c
index 6d76707..3152dea 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -155,8 +155,14 @@ static inline struct shmid_kernel *shm_lock(struct 
ipc_namespace *ns, int id)
 {
struct kern_ipc_perm *ipcp = ipc_lock(_ids(ns), id);
 
-   if (IS_ERR(ipcp))
+   if (IS_ERR(ipcp)) {
+   /*
+* We raced in the idr lookup or with RMID,
+* either way, the ID is busted.
+*/
+   BUG_ON(1);
return (struct shmid_kernel *)ipcp;
+   }
 
return container_of(ipcp, struct shmid_kernel, shm_perm);
 }
@@ -191,7 +197,6 @@ static void shm_open(struct vm_area_struct *vma)
struct shmid_kernel *shp;
 
shp = shm_lock(sfd->ns, sfd->id);
-   BUG_ON(IS_ERR(shp));
shp->shm_atim = get_seconds();
shp->shm_lprid = task_tgid_vnr(current);
shp->shm_nattch++;
@@ -258,7 +263,6 @@ static void shm_close(struct vm_area_struct *vma)
down_write(_ids(ns).rwsem);
/* remove from the list of attaches of the shm segment */
shp = shm_lock(ns, sfd->id);
-   BUG_ON(IS_ERR(shp));
shp->shm_lprid = task_tgid_vnr(current);
shp->shm_dtim = get_seconds();
shp->shm_nattch--;
@@ -1191,7 +1195,6 @@ out_fput:
 out_nattch:
down_write(_ids(ns).rwsem);
shp = shm_lock(ns, shmid);
-   BUG_ON(IS_ERR(shp));
shp->shm_nattch--;
if (shm_may_destroy(ns, shp))
shm_destroy(ns, shp);
-- 
2.1.4

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

Re: [RFC PATCH 0/5] livepatch: add support on arm64

[Masami Hiramatsu]

On 2015/05/28 14:51, Li Bin wrote:
> This patchset propose a method for gcc -mfentry feature(profile
> before prologue) implementation for arm64, and propose the livepatch
> implementation for arm64 based on this feature.
> The gcc implementation about this feature will be post to the gcc 
> community soon.
> 
> With this -mfentry feature, the entry of each function like:
> 
> foo:
> mov x9, x30 
> bl __fentry__
> mov x30, x9
> [prologue]
> ... 
> 
> The x9 is a callee corruptible register, and the __fentry__ function
> is responsible to protect all registers, so it can be used to protect
> the x30. And the added two instructions which is register mov operation
> have ralatively small impact on performance.

Hm, this implementation looks good to me :)
This also enables us to KPROBES_ON_FTRACE too.

Thanks,

> 
> This patchset has been tested on arm64 platform.
> 
> Li Bin (4):
>   livepatch: ftrace: arm64: Add support for DYNAMIC_FTRACE_WITH_REGS
>   livepatch: ftrace: add ftrace_function_stub_ip function
>   livepatch: ftrace: arm64: Add support for -mfentry on arm64
>   livepatch: arm64: add support for livepatch on arm64
> 
> Xie XiuQi (1):
>   livepatch: arm64: support relocation in a module
> 
>  arch/arm64/Kconfig |5 +
>  arch/arm64/include/asm/ftrace.h|9 +
>  arch/arm64/include/asm/livepatch.h |   45 +
>  arch/arm64/kernel/Makefile |1 +
>  arch/arm64/kernel/arm64ksyms.c |4 +
>  arch/arm64/kernel/entry-ftrace.S   |  154 +++-
>  arch/arm64/kernel/ftrace.c |   28 +++-
>  arch/arm64/kernel/livepatch.c  |   41 
>  arch/arm64/kernel/module.c |  355 
> ++--
>  include/linux/ftrace.h |1 +
>  kernel/livepatch/core.c|   17 ++-
>  kernel/trace/ftrace.c  |   32 
>  scripts/recordmcount.pl|2 +-
>  13 files changed, 508 insertions(+), 186 deletions(-)
>  create mode 100644 arch/arm64/include/asm/livepatch.h
>  create mode 100644 arch/arm64/kernel/livepatch.c
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo

[Masami Hiramatsu]

On 2015/05/29 15:30, He Kuang wrote:
> hi, Alexei
> 
> On 2015/5/29 2:10, Alexei Starovoitov wrote:
>> On 5/28/15 6:01 AM, He Kuang wrote:
 I don't think you can break it down in two steps like this.
> There is no such thing as 'calling regs'. x86_32 with ax,dx,cx
> are not 'calling regs'. 64-bit values will be passed in a pair.
> Only 'pt_regs + arch + func_proto + asmlinkage' makes sense
 >from the user point of view.
> Adding 'asmlinkage' attr is also trivial.
> 'func(long, char) asmlinkage' is easy to parse and the user
>>> I think at this early stage, we could make our bpf variable
>>> prologue work with debuginfo while keeping bpf 'SEC' syntax
>>> consistent with original perf probe. After all, we can use
>>> pt_regs directly or relay to perf-probe cache by Masami to deal
>>> with non-debug cases.
>>
>> so you're saying you don't want to support non-debug case for now?
>> Sure, as long as section name parser will be able to support
>> 'func(long, char) asmlinkage' syntax in the future without breaking
>> compatibility. I'm mostly interested in cases when debug info
>> is not available at all. So perf-probe cache is of no use to me.
>>
>>
> 
> Yes, that syntax do deal with the situation which current 'perf
> probe' syntax not covered, so not only bpf prologue would benifit
> from that, maybe we could try to let perf probe involve that.

Hmm, then how about below syntax?

 perf probe x86_acpi_enter_sleep_state $regparams:asmlinkage(char)

So, regparams has following synopsis.

 $regparams[:[asmlinkage|0-6]([u8|u16|u32|u64|ptr][,...])]

Note that asmlinkage is a synonym of 0, and default depends on arch :)
Some architecture ignores this part, e.g. x86_64 always uses regs.
And it is automatically expanded to argX="%reg or $stackX".

e.g.
 $regparams is expanded to
  arg1=%di arg2=%si arg3=%dx arg4=%cx arg5=%r8 arg6=%r9 (on x86_64)
  arg1=%ax arg2=%dx arg3=%cx arg4=$stack1 arg5=$stack2 arg6=$stack3 (on i386)

 $regparams:0 is expanded to
  arg1=%di arg2=%si arg3=%dx arg4=%cx arg5=%r8 arg6=%r9 (on x86_64)
  arg1=$stack1 arg2=$stack2 arg3=$stack3 arg4=$stack4 arg5=$stack5 arg6=$stack6 
(on i386)

 $regparams:3(char,long) is expanded to
  arg1=%di:s8 arg2=%si:s64 (on x86_64)
  arg1=%ax:s8 arg2=%dx:s64 (on i386)

How is this?

Thank you,


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] PCI / ACPI fix for 4.1-rc6

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-pci-4.1-rc6

to receive a fix for the ACPI PCI host bridge initialization code
as commit dc4fdaf0e4839109169d8261814813816951c75f

 PCI / ACPI: Do not set ACPI companions for host bridges with parents

on top of commit ba155e2d21f6bf05de86a78dbe5bfd8757604a65

 Linux 4.1-rc5

This fixes a bug uncovered by a recent driver core change that
modified the implementation of the ACPI_COMPANION_SET() macro to
strictly rely on its second argument to be either NULL or a valid
pointer to struct acpi_device.

As it turns out, pcibios_root_bridge_prepare() on x86 and ia64
works with the assumption that the only code path calling
pci_create_root_bus() is pci_acpi_scan_root() and therefore
the sysdata argument passed to it will always match the
expectations of pcibios_root_bridge_prepare().  That need not
be the case, however, and in particular it is not the case for
the Xen pcifront driver that passes a pointer to its own private
data strcture as sysdata to pci_scan_bus_parented() which then
passes it to pci_create_root_bus() and it ends up being used
incorrectly by pcibios_root_bridge_prepare().

Thanks!


---

Rafael J. Wysocki (1):
  PCI / ACPI: Do not set ACPI companions for host bridges with parents

---

 arch/ia64/pci/pci.c | 13 ++---
 arch/x86/pci/acpi.c | 13 ++---
 2 files changed, 20 insertions(+), 6 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/

Re: [PATCH] psmouse - focaltech report finger width to userspace

[Dmitry Torokhov]

On Sat, May 30, 2015 at 02:00:59AM +0300, Dmitry Tunin wrote:
> Focaltech touchpads report finger width in packet[5] of absolute packet.
> Range for width in raw format is 0x10 - 0x70. Second half-byte is always 0.
> 0xff is reported, when a large contact area is detected.
> This can be handled in userspace.
> 
> Signed-off-by: Dmitry Tunin 

Let's add a few people...

> ---
>  drivers/input/mouse/focaltech.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/mouse/focaltech.c b/drivers/input/mouse/focaltech.c
> index 23d2594..0c3b698 100644
> --- a/drivers/input/mouse/focaltech.c
> +++ b/drivers/input/mouse/focaltech.c
> @@ -105,6 +105,16 @@ struct focaltech_hw_state {
>  
>   /* True if the clickpad has been pressed. */
>   bool pressed;
> +
> + /*
> + * Finger width 0-7 and 15 for a very big contact area.
> + * 15 value stays until the finger is released.
> + * Width is reported only in absolute packets.
> + * Since hardware reports width only for last touching finger,
> + * there is no need to store width for every specific finger, so 
> + * we keep only last value reported.
> + */
> + unsigned int width;
>  };
>  
>  struct focaltech_data {
> @@ -112,7 +122,7 @@ struct focaltech_data {
>   struct focaltech_hw_state state;
>  };
>  
> -static void focaltech_report_state(struct psmouse *psmouse)
> +static void focaltech_report_state(struct psmouse *psmouse, bool abs)
>  {
>   struct focaltech_data *priv = psmouse->private;
>   struct focaltech_hw_state *state = >state;
> @@ -137,6 +147,7 @@ static void focaltech_report_state(struct psmouse 
> *psmouse)
>   input_report_abs(dev, ABS_MT_POSITION_X, clamped_x);
>   input_report_abs(dev, ABS_MT_POSITION_Y,
>priv->y_max - clamped_y);
> + if (abs) input_report_abs(dev, ABS_TOOL_WIDTH, 
> state->width);

I am not sure this condition and the change in focaltech_process_packet
are needed. The relative packets augment absolute one and we expect
width not change so we can always report state->width (either updated or
cached) and input core will drop dupes.

>   }
>   }
>   input_mt_report_pointer_emulation(dev, true);
> @@ -187,6 +198,7 @@ static void focaltech_process_abs_packet(struct psmouse 
> *psmouse,
>  
>   state->fingers[finger].x = ((packet[1] & 0xf) << 8) | packet[2];
>   state->fingers[finger].y = (packet[3] << 8) | packet[4];
> + state->width = packet[5] >> 4;
>   state->fingers[finger].valid = true;
>  }
>  
> @@ -228,22 +240,23 @@ static void focaltech_process_packet(struct psmouse 
> *psmouse)
>   switch (packet[0] & 0xf) {
>   case FOC_TOUCH:
>   focaltech_process_touch_packet(psmouse, packet);
> + focaltech_report_state(psmouse, false);
>   break;
>  
>   case FOC_ABS:
>   focaltech_process_abs_packet(psmouse, packet);
> + focaltech_report_state(psmouse, true);
>   break;
>  
>   case FOC_REL:
>   focaltech_process_rel_packet(psmouse, packet);
> + focaltech_report_state(psmouse, false);
>   break;
>  
>   default:
>   psmouse_err(psmouse, "Unknown packet type: %02x\n", packet[0]);
>   break;
>   }
> -
> - focaltech_report_state(psmouse);
>  }
>  
>  static psmouse_ret_t focaltech_process_byte(struct psmouse *psmouse)
> @@ -331,6 +344,7 @@ static void focaltech_set_input_params(struct psmouse 
> *psmouse)
>   __set_bit(EV_ABS, dev->evbit);
>   input_set_abs_params(dev, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0);
>   input_set_abs_params(dev, ABS_MT_POSITION_Y, 0, priv->y_max, 0, 0);
> + input_set_abs_params(dev, ABS_TOOL_WIDTH, 0, 15, 0, 0);
>   input_mt_init_slots(dev, 5, INPUT_MT_POINTER);
>   __set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
>  }
> -- 
> 1.9.1
> 

Thanks.

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

You have been pick for a personal donation from me. Email ( leon.hirt...@mail.com ) for more info.‏

[Fernandez, Mercedes M.]

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

Re: [PATCH v2 0/2] ACPI / PCI: Fix _PRT lookup for ARI enabled devices

[Rafael J. Wysocki]

On Friday, May 29, 2015 05:18:48 PM Bjorn Helgaas wrote:
> On Tue, May 26, 2015 at 03:11:38PM -0600, Alex Williamson wrote:
> > v2: don't modify entry->id.device
> > 
> > In most cases we only use ARI with SR-IOV VFs, which do not support
> > INTx and therefore never hit this problem.  However, some non-SR-IOV
> > implementations create multiple PFs, extending beyond the standard
> > 3-bit function numbers with ARI, and do support INTx for those
> > additional functions.  This can happen with Solarflare SFC9120
> > adapters.  The host driver typically doesn't use INTx, so we also
> > haven't noticed this problem on bare metal, but when we attempt to
> > assign the device to a VM using vfio-pci, we fail trying to setup
> > default INTx signaling.  Thanks,
> > 
> > Alex
> > 
> > ---
> > 
> > Alex Williamson (2):
> >   PCI: Move pci_ari_enabled() to global header
> >   ACPI / PCI: Account for ARI in _PRT lookups
> 
> Rafael, do you want this or should I take it?
> 
> I put it on my pci/virtualization branch for v4.2.

That's fine.  Please feel free to add my ACKs to those if that helps.

Rafael

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

[PATCH v11 5/12] x86, asm: Change is_new_memtype_allowed() for WT

[Toshi Kani]

From: Toshi Kani 

__ioremap_caller() calls reserve_memtype() to set new_pcm
(existing map type if any), and then calls
is_new_memtype_allowed() to verify if converting to new_pcm
is allowed when pcm (request type) is different from new_pcm.

When WT is requested, the caller expects that writes are
ordered and uncached.  Therefore, this patch changes
is_new_memtype_allowed() to disallow the following cases.

 - If the request is WT, mapping type cannot be WB
 - If the request is WT, mapping type cannot be WC

Signed-off-by: Toshi Kani 
Reviewed-by: Thomas Gleixner 
---
 arch/x86/include/asm/pgtable.h |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index fe57e7a..2562e30 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -398,11 +398,17 @@ static inline int is_new_memtype_allowed(u64 paddr, 
unsigned long size,
 * requested memtype:
 * - request is uncached, return cannot be write-back
 * - request is write-combine, return cannot be write-back
+* - request is write-through, return cannot be write-back
+* - request is write-through, return cannot be write-combine
 */
if ((pcm == _PAGE_CACHE_MODE_UC_MINUS &&
 new_pcm == _PAGE_CACHE_MODE_WB) ||
(pcm == _PAGE_CACHE_MODE_WC &&
-new_pcm == _PAGE_CACHE_MODE_WB)) {
+new_pcm == _PAGE_CACHE_MODE_WB) ||
+   (pcm == _PAGE_CACHE_MODE_WT &&
+new_pcm == _PAGE_CACHE_MODE_WB) ||
+   (pcm == _PAGE_CACHE_MODE_WT &&
+new_pcm == _PAGE_CACHE_MODE_WC)) {
return 0;
}
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 10/12] x86, mm, asm: Add WT support to set_page_memtype()

[Toshi Kani]

From: Toshi Kani 

As set_memory_wb() calls free_ram_pages_type(), which then calls
set_page_memtype() with -1, _PGMT_DEFAULT is used for tracking
the WB type.  _PGMT_WB is defined but unused.  Hence, this patch
renames _PGMT_DEFAULT to _PGMT_WB to clarify the usage, and
releases the slot used by _PGMT_WB before.  free_ram_pages_type()
is changed to call set_page_memtype() with _PGMT_WB, and
get_page_memtype() returns _PAGE_CACHE_MODE_WB for _PGMT_WB.

This patch then defines _PGMT_WT to the released slot.  This enables
set_page_memtype() to track the WT type.

Signed-off-by: Toshi Kani 
---
 arch/x86/mm/pat.c |   60 +++--
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 1a2c84c..15d37c3 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -70,18 +70,22 @@ static u64 __read_mostly boot_pat_state;
 
 #ifdef CONFIG_X86_PAT
 /*
- * X86 PAT uses page flags WC and Uncached together to keep track of
- * memory type of pages that have backing page struct. X86 PAT supports 3
- * different memory types, _PAGE_CACHE_MODE_WB, _PAGE_CACHE_MODE_WC and
- * _PAGE_CACHE_MODE_UC_MINUS and fourth state where page's memory type has not
- * been changed from its default (value of -1 used to denote this).
- * Note we do not support _PAGE_CACHE_MODE_UC here.
+ * X86 PAT uses page flags arch_1 and uncached together to keep track of
+ * memory type of pages that have backing page struct.
+ *
+ * X86 PAT supports 4 different memory types:
+ *  - _PAGE_CACHE_MODE_WB
+ *  - _PAGE_CACHE_MODE_WC
+ *  - _PAGE_CACHE_MODE_UC_MINUS
+ *  - _PAGE_CACHE_MODE_WT
+ *
+ * _PAGE_CACHE_MODE_WB is the default type.
  */
 
-#define _PGMT_DEFAULT  0
+#define _PGMT_WB   0
 #define _PGMT_WC   (1UL << PG_arch_1)
 #define _PGMT_UC_MINUS (1UL << PG_uncached)
-#define _PGMT_WB   (1UL << PG_uncached | 1UL << PG_arch_1)
+#define _PGMT_WT   (1UL << PG_uncached | 1UL << PG_arch_1)
 #define _PGMT_MASK (1UL << PG_uncached | 1UL << PG_arch_1)
 #define _PGMT_CLEAR_MASK   (~_PGMT_MASK)
 
@@ -89,14 +93,14 @@ static inline enum page_cache_mode get_page_memtype(struct 
page *pg)
 {
unsigned long pg_flags = pg->flags & _PGMT_MASK;
 
-   if (pg_flags == _PGMT_DEFAULT)
-   return -1;
+   if (pg_flags == _PGMT_WB)
+   return _PAGE_CACHE_MODE_WB;
else if (pg_flags == _PGMT_WC)
return _PAGE_CACHE_MODE_WC;
else if (pg_flags == _PGMT_UC_MINUS)
return _PAGE_CACHE_MODE_UC_MINUS;
else
-   return _PAGE_CACHE_MODE_WB;
+   return _PAGE_CACHE_MODE_WT;
 }
 
 static inline void set_page_memtype(struct page *pg,
@@ -113,11 +117,12 @@ static inline void set_page_memtype(struct page *pg,
case _PAGE_CACHE_MODE_UC_MINUS:
memtype_flags = _PGMT_UC_MINUS;
break;
-   case _PAGE_CACHE_MODE_WB:
-   memtype_flags = _PGMT_WB;
+   case _PAGE_CACHE_MODE_WT:
+   memtype_flags = _PGMT_WT;
break;
+   case _PAGE_CACHE_MODE_WB:
default:
-   memtype_flags = _PGMT_DEFAULT;
+   memtype_flags = _PGMT_WB;
break;
}
 
@@ -389,8 +394,11 @@ static int pat_pagerange_is_ram(resource_size_t start, 
resource_size_t end)
 
 /*
  * For RAM pages, we use page flags to mark the pages with appropriate type.
- * The page flags are limited to three types, WB, WC and UC-.
- * WT and WP requests fail with -EINVAL, and UC gets redirected to UC-.
+ * The page flags are limited to four types, WB (default), WC, WT and UC-.
+ * WP request fails with -EINVAL, and UC gets redirected to UC-.  Setting
+ * a new memory type is only allowed to a page mapped with the default WB
+ * type.
+ *
  * Here we do two pass:
  * - Find the memtype of all the pages in the range, look for any conflicts
  * - In case of no conflicts, set the new memtype for pages in the range
@@ -402,8 +410,7 @@ static int reserve_ram_pages_type(u64 start, u64 end,
struct page *page;
u64 pfn;
 
-   if ((req_type == _PAGE_CACHE_MODE_WT) ||
-   (req_type == _PAGE_CACHE_MODE_WP)) {
+   if (req_type == _PAGE_CACHE_MODE_WP) {
if (new_type)
*new_type = _PAGE_CACHE_MODE_UC_MINUS;
return -EINVAL;
@@ -420,7 +427,7 @@ static int reserve_ram_pages_type(u64 start, u64 end,
 
page = pfn_to_page(pfn);
type = get_page_memtype(page);
-   if (type != -1) {
+   if (type != _PAGE_CACHE_MODE_WB) {
pr_info("x86/PAT: reserve_ram_pages_type failed [mem 
%#010Lx-%#010Lx], track 0x%x, req 0x%x\n",
start, end - 1, type, req_type);
if (new_type)
@@ -447,7 +454,7 @@ static int free_ram_pages_type(u64 start, u64 end)
 
  

[PATCH v11 9/12] x86, mm, pat: Add pgprot_writethrough() for WT

[Toshi Kani]

From: Toshi Kani 

This patch adds pgprot_writethrough() for setting WT to a given
pgprot_t.

Signed-off-by: Toshi Kani 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Thomas Gleixner 
---
 arch/x86/include/asm/pgtable_types.h |3 +++
 arch/x86/mm/pat.c|7 +++
 include/asm-generic/pgtable.h|4 
 3 files changed, 14 insertions(+)

diff --git a/arch/x86/include/asm/pgtable_types.h 
b/arch/x86/include/asm/pgtable_types.h
index 78f0c8c..13f310b 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -367,6 +367,9 @@ extern int nx_enabled;
 #define pgprot_writecombinepgprot_writecombine
 extern pgprot_t pgprot_writecombine(pgprot_t prot);
 
+#define pgprot_writethroughpgprot_writethrough
+extern pgprot_t pgprot_writethrough(pgprot_t prot);
+
 /* Indicate that x86 has its own track and untrack pfn vma functions */
 #define __HAVE_PFNMAP_TRACKING
 
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 85c9fcb..1a2c84c 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -987,6 +987,13 @@ pgprot_t pgprot_writecombine(pgprot_t prot)
 }
 EXPORT_SYMBOL_GPL(pgprot_writecombine);
 
+pgprot_t pgprot_writethrough(pgprot_t prot)
+{
+   return __pgprot(pgprot_val(prot) |
+   cachemode2protval(_PAGE_CACHE_MODE_WT));
+}
+EXPORT_SYMBOL_GPL(pgprot_writethrough);
+
 #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_X86_PAT)
 
 static struct memtype *memtype_get_idx(loff_t pos)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 39f1d6a..bd910ce 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -262,6 +262,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
 #define pgprot_writecombine pgprot_noncached
 #endif
 
+#ifndef pgprot_writethrough
+#define pgprot_writethrough pgprot_noncached
+#endif
+
 #ifndef pgprot_device
 #define pgprot_device pgprot_noncached
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 4/12] x86, mm, pat: Change reserve_memtype() for WT

[Toshi Kani]

From: Toshi Kani 

When a RAM range is requested to reserve_memtype(), it calls
reserve_ram_pages_type() to verify the requested type.
reserve_ram_pages_type() is changed to fail WT and WP requests
with -EINVAL since set_page_memtype() is limited to handle
three types, WB, WC and UC-.

Signed-off-by: Toshi Kani 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Thomas Gleixner 
---
Patch 10/12 enhances set_page_memtype() to support WT.
---
 arch/x86/mm/pat.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 3d9f125..85c9fcb 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -389,6 +389,8 @@ static int pat_pagerange_is_ram(resource_size_t start, 
resource_size_t end)
 
 /*
  * For RAM pages, we use page flags to mark the pages with appropriate type.
+ * The page flags are limited to three types, WB, WC and UC-.
+ * WT and WP requests fail with -EINVAL, and UC gets redirected to UC-.
  * Here we do two pass:
  * - Find the memtype of all the pages in the range, look for any conflicts
  * - In case of no conflicts, set the new memtype for pages in the range
@@ -400,6 +402,13 @@ static int reserve_ram_pages_type(u64 start, u64 end,
struct page *page;
u64 pfn;
 
+   if ((req_type == _PAGE_CACHE_MODE_WT) ||
+   (req_type == _PAGE_CACHE_MODE_WP)) {
+   if (new_type)
+   *new_type = _PAGE_CACHE_MODE_UC_MINUS;
+   return -EINVAL;
+   }
+
if (req_type == _PAGE_CACHE_MODE_UC) {
/* We do not support strong UC */
WARN_ON_ONCE(1);
@@ -449,6 +458,7 @@ static int free_ram_pages_type(u64 start, u64 end)
  * - _PAGE_CACHE_MODE_WC
  * - _PAGE_CACHE_MODE_UC_MINUS
  * - _PAGE_CACHE_MODE_UC
+ * - _PAGE_CACHE_MODE_WT
  *
  * If new_type is NULL, function will return an error if it cannot reserve the
  * region with req_type. If new_type is non-NULL, function will return
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 1/12] x86, mm, pat: Cleanup init flags in pat_init()

[Toshi Kani]

From: Toshi Kani 

pat_init() uses two flags, 'boot_cpu' and 'boot_pat_state', for
tracking the boot CPU's initialization status.  'boot_pat_state'
is also overloaded to carry the boot PAT value.

This patch cleans this up by replacing them with a new single
flag, 'boot_cpu_done', to track the boot CPU's initialization
status.  'boot_pat_state' is only used to carry the boot PAT
value as a result.

Suggested-by: Thomas Gleixner 
Signed-off-by: Toshi Kani 
---
 arch/x86/mm/pat.c |   40 +++-
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index a1c9654..e1ec6a7 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -197,24 +197,29 @@ void pat_init_cache_modes(void)
 void pat_init(void)
 {
u64 pat;
-   bool boot_cpu = !boot_pat_state;
+   static bool boot_cpu_done;
 
if (!pat_enabled())
return;
 
-   if (!cpu_has_pat) {
-   if (!boot_pat_state) {
+   if (!boot_cpu_done) {
+   if (!cpu_has_pat) {
pat_disable("PAT not supported by CPU.");
return;
-   } else {
-   /*
-* If this happens we are on a secondary CPU, but
-* switched to PAT on the boot CPU. We have no way to
-* undo PAT.
-*/
-   pr_err("x86/PAT: PAT enabled, but not supported by 
secondary CPU\n");
-   BUG();
}
+
+   rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
+   if (!boot_pat_state) {
+   pat_disable("PAT read returns always zero, disabled.");
+   return;
+   }
+   } else if (!cpu_has_pat) {
+   /*
+* If this happens we are on a secondary CPU, but
+* switched to PAT on the boot CPU. We have no way to
+* undo PAT.
+*/
+   panic("PAT enabled, but not supported by secondary CPU\n");
}
 
/* Set PWT to Write-Combining. All other bits stay the same */
@@ -233,19 +238,12 @@ void pat_init(void)
pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
  PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
 
-   /* Boot CPU check */
-   if (!boot_pat_state) {
-   rdmsrl(MSR_IA32_CR_PAT, boot_pat_state);
-   if (!boot_pat_state) {
-   pat_disable("PAT read returns always zero, disabled.");
-   return;
-   }
-   }
-
wrmsrl(MSR_IA32_CR_PAT, pat);
 
-   if (boot_cpu)
+   if (!boot_cpu_done) {
pat_init_cache_modes();
+   boot_cpu_done = true;
+   }
 }
 
 #undef PAT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 3/12] x86, mm, pat: Set WT to PA7 slot of PAT MSR

[Toshi Kani]

From: Toshi Kani 

This patch sets WT to the PA7 slot in the PAT MSR when the processor
is not affected by the PAT errata.  The PA7 slot is chosen to improve
robustness in the presence of errata that might cause the high PAT bit
to be ignored.  This way a buggy PA7 slot access will hit the PA3 slot,
which is UC, so at worst we lose performance without causing a correctness
issue.

The following Intel processors are affected by the PAT errata.

   errata   cpuid
   
   Pentium 2, A52   family 0x6, model 0x5
   Pentium 3, E27   family 0x6, model 0x7, 0x8
   Pentium 3 Xenon, G26 family 0x6, model 0x7, 0x8, 0xa
   Pentium M, Y26   family 0x6, model 0x9
   Pentium M 90nm, X9   family 0x6, model 0xd
   Pentium 4, N46   family 0xf, model 0x0

Instead of making sharp boundary checks, this patch makes conservative
checks to exclude all Pentium 2, 3, M and 4 family processors.  For
such processors, _PAGE_CACHE_MODE_WT is redirected to UC- per the
default setup in __cachemode2pte_tbl[].

Signed-off-by: Toshi Kani 
Reviewed-by: Juergen Gross 
Reviewed-by: Thomas Gleixner 
---
 arch/x86/mm/pat.c |   57 ++---
 1 file changed, 49 insertions(+), 8 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 819ae28..3d9f125 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -201,6 +201,7 @@ void pat_init_cache_modes(void)
 void pat_init(void)
 {
u64 pat;
+   struct cpuinfo_x86 *c = _cpu_data;
static bool boot_cpu_done;
 
if (!boot_cpu_done) {
@@ -246,21 +247,61 @@ void pat_init(void)
  PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC);
if (!boot_pat_state)
boot_pat_state = pat;
-   } else {
+
+   } else if ((c->x86_vendor == X86_VENDOR_INTEL) &&
+  (((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
+   ((c->x86 == 0xf) && (c->x86_model <= 0x6 {
/*
-* PTE encoding used in Linux:
+* PAT support with the lower four entries. Intel Pentium 2,
+* 3, M, and 4 are affected by PAT errata, which makes the
+* upper four entries unusable.  We do not use the upper four
+* entries for all the affected processor families for safe.
+*
+*  PTE encoding used in Linux:
 *  PAT
 *  |PCD
-*  ||PWT
-*  |||
-*  000 WB  _PAGE_CACHE_WB
-*  001 WC  _PAGE_CACHE_WC
-*  010 UC- _PAGE_CACHE_UC_MINUS
-*  011 UC  _PAGE_CACHE_UC
+*  ||PWT  PAT
+*  |||slot
+*  0000WB : _PAGE_CACHE_MODE_WB
+*  0011WC : _PAGE_CACHE_MODE_WC
+*  0102UC-: _PAGE_CACHE_MODE_UC_MINUS
+*  0113UC : _PAGE_CACHE_MODE_UC
 * PAT bit unused
+*
+* NOTE: When WT or WP is used, it is redirected to UC- per
+* the default setup in __cachemode2pte_tbl[].
 */
pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
  PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, UC);
+   } else {
+   /*
+* PAT full support.  We put WT in slot 7 to improve
+* robustness in the presence of errata that might cause
+* the high PAT bit to be ignored.  This way a buggy slot 7
+* access will hit slot 3, and slot 3 is UC, so at worst
+* we lose performance without causing a correctness issue.
+* Pentium 4 erratum N46 is an example of such an erratum,
+* although we try not to use PAT at all on affected CPUs.
+*
+*  PTE encoding used in Linux:
+*  PAT
+*  |PCD
+*  ||PWT  PAT
+*  |||slot
+*  0000WB : _PAGE_CACHE_MODE_WB
+*  0011WC : _PAGE_CACHE_MODE_WC
+*  0102UC-: _PAGE_CACHE_MODE_UC_MINUS
+*  0113UC : _PAGE_CACHE_MODE_UC
+*  1004WB : Reserved
+*  1015WC : Reserved
+*  1106UC-: Reserved
+*  1117WT : _PAGE_CACHE_MODE_WT
+*
+* The reserved slots are unused, but mapped to their
+* corresponding types in the presence of PAT errata.
+*/
+   pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
+   

[PATCH v11 11/12] x86, mm: Add set_memory_wt() for WT

[Toshi Kani]

From: Toshi Kani 

Now that reserve_ram_pages_type() accepts the WT type, this
patch adds set_memory_wt(), set_memory_array_wt() and
set_pages_array_wt() for setting the WT type to the regular
memory.

ioremap_change_attr() is also extended to accept the WT type.

Signed-off-by: Toshi Kani 
---
 Documentation/x86/pat.txt |9 -
 arch/x86/include/asm/cacheflush.h |6 +++-
 arch/x86/mm/ioremap.c |3 ++
 arch/x86/mm/pageattr.c|   62 +
 4 files changed, 63 insertions(+), 17 deletions(-)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index db0de6c..54944c7 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -48,6 +48,9 @@ set_memory_uc  |UC-   |--  |   -- 
|
 set_memory_wc  |WC|--  |   -- |
  set_memory_wb |  ||  |
|  ||  |
+set_memory_wt  |WT|--  |   -- |
+ set_memory_wb |  ||  |
+   |  ||  |
 pci sysfs resource |--|--  |   UC-|
|  ||  |
 pci sysfs resource_wc  |--|--  |   WC |
@@ -150,8 +153,8 @@ can be more restrictive, in case of any existing aliasing 
for that address.
 For example: If there is an existing uncached mapping, a new ioremap_wc can
 return uncached mapping in place of write-combine requested.
 
-set_memory_[uc|wc] and set_memory_wb should be used in pairs, where driver will
-first make a region uc or wc and switch it back to wb after use.
+set_memory_[uc|wc|wt] and set_memory_wb should be used in pairs, where driver
+will first make a region uc, wc or wt and switch it back to wb after use.
 
 Over time writes to /proc/mtrr will be deprecated in favor of using PAT based
 interfaces. Users writing to /proc/mtrr are suggested to use above interfaces.
@@ -159,7 +162,7 @@ interfaces. Users writing to /proc/mtrr are suggested to 
use above interfaces.
 Drivers should use ioremap_[uc|wc] to access PCI BARs with [uc|wc] access
 types.
 
-Drivers should use set_memory_[uc|wc] to set access type for RAM ranges.
+Drivers should use set_memory_[uc|wc|wt] to set access type for RAM ranges.
 
 
 PAT debugging
diff --git a/arch/x86/include/asm/cacheflush.h 
b/arch/x86/include/asm/cacheflush.h
index 47c8e32..b6f7457 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -8,7 +8,7 @@
 /*
  * The set_memory_* API can be used to change various attributes of a virtual
  * address range. The attributes include:
- * Cachability   : UnCached, WriteCombining, WriteBack
+ * Cachability   : UnCached, WriteCombining, WriteThrough, WriteBack
  * Executability : eXeutable, NoteXecutable
  * Read/Write: ReadOnly, ReadWrite
  * Presence  : NotPresent
@@ -35,9 +35,11 @@
 
 int _set_memory_uc(unsigned long addr, int numpages);
 int _set_memory_wc(unsigned long addr, int numpages);
+int _set_memory_wt(unsigned long addr, int numpages);
 int _set_memory_wb(unsigned long addr, int numpages);
 int set_memory_uc(unsigned long addr, int numpages);
 int set_memory_wc(unsigned long addr, int numpages);
+int set_memory_wt(unsigned long addr, int numpages);
 int set_memory_wb(unsigned long addr, int numpages);
 int set_memory_x(unsigned long addr, int numpages);
 int set_memory_nx(unsigned long addr, int numpages);
@@ -48,10 +50,12 @@ int set_memory_4k(unsigned long addr, int numpages);
 
 int set_memory_array_uc(unsigned long *addr, int addrinarray);
 int set_memory_array_wc(unsigned long *addr, int addrinarray);
+int set_memory_array_wt(unsigned long *addr, int addrinarray);
 int set_memory_array_wb(unsigned long *addr, int addrinarray);
 
 int set_pages_array_uc(struct page **pages, int addrinarray);
 int set_pages_array_wc(struct page **pages, int addrinarray);
+int set_pages_array_wt(struct page **pages, int addrinarray);
 int set_pages_array_wb(struct page **pages, int addrinarray);
 
 /*
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 779b1a2..cc5ccc4 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -42,6 +42,9 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long 
size,
case _PAGE_CACHE_MODE_WC:
err = _set_memory_wc(vaddr, nrpages);
break;
+   case _PAGE_CACHE_MODE_WT:
+   err = _set_memory_wt(vaddr, nrpages);
+   break;
case _PAGE_CACHE_MODE_WB:
err = _set_memory_wb(vaddr, nrpages);
break;
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 94aae76..d908f19 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1502,12 +1502,10 @@ EXPORT_SYMBOL(set_memory_uc);
 static 

[PATCH v11 2/12] x86, mm, pat: Refactor !pat_enabled handling

[Toshi Kani]

From: Toshi Kani 

This patch refactors the !pat_enabled code paths and integrates
them into the PAT abstraction code.  The PAT table is emulated by
corresponding to the two cache attribute bits, PWT (Write Through)
and PCD (Cache Disable).  The emulated PAT table is the same as the
BIOS default setup when the system has PAT but the "nopat" boot
option is specified.  The emulated PAT table is also used when
MSR_IA32_CR_PAT returns 0 -- 9d34cfdf4796 ("x86: Don't rely on
VMWare emulating PAT MSR correctly").

Signed-off-by: Toshi Kani 
Reviewed-by: Juergen Gross 
---
 arch/x86/mm/init.c |6 ++-
 arch/x86/mm/iomap_32.c |   12 +++---
 arch/x86/mm/ioremap.c  |5 +--
 arch/x86/mm/pageattr.c |3 --
 arch/x86/mm/pat.c  |   95 +---
 5 files changed, 67 insertions(+), 54 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 1d55318..8533b46 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -40,7 +40,7 @@
  */
 uint16_t __cachemode2pte_tbl[_PAGE_CACHE_MODE_NUM] = {
[_PAGE_CACHE_MODE_WB  ] = 0 | 0,
-   [_PAGE_CACHE_MODE_WC  ] = _PAGE_PWT | 0,
+   [_PAGE_CACHE_MODE_WC  ] = 0 | _PAGE_PCD,
[_PAGE_CACHE_MODE_UC_MINUS] = 0 | _PAGE_PCD,
[_PAGE_CACHE_MODE_UC  ] = _PAGE_PWT | _PAGE_PCD,
[_PAGE_CACHE_MODE_WT  ] = 0 | _PAGE_PCD,
@@ -50,11 +50,11 @@ EXPORT_SYMBOL(__cachemode2pte_tbl);
 
 uint8_t __pte2cachemode_tbl[8] = {
[__pte2cm_idx( 0| 0 | 0)] = _PAGE_CACHE_MODE_WB,
-   [__pte2cm_idx(_PAGE_PWT | 0 | 0)] = _PAGE_CACHE_MODE_WC,
+   [__pte2cm_idx(_PAGE_PWT | 0 | 0)] = 
_PAGE_CACHE_MODE_UC_MINUS,
[__pte2cm_idx( 0| _PAGE_PCD | 0)] = 
_PAGE_CACHE_MODE_UC_MINUS,
[__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | 0)] = _PAGE_CACHE_MODE_UC,
[__pte2cm_idx( 0| 0 | _PAGE_PAT)] = _PAGE_CACHE_MODE_WB,
-   [__pte2cm_idx(_PAGE_PWT | 0 | _PAGE_PAT)] = _PAGE_CACHE_MODE_WC,
+   [__pte2cm_idx(_PAGE_PWT | 0 | _PAGE_PAT)] = 
_PAGE_CACHE_MODE_UC_MINUS,
[__pte2cm_idx(0 | _PAGE_PCD | _PAGE_PAT)] = 
_PAGE_CACHE_MODE_UC_MINUS,
[__pte2cm_idx(_PAGE_PWT | _PAGE_PCD | _PAGE_PAT)] = _PAGE_CACHE_MODE_UC,
 };
diff --git a/arch/x86/mm/iomap_32.c b/arch/x86/mm/iomap_32.c
index 37d2ba2..9c0ff04 100644
--- a/arch/x86/mm/iomap_32.c
+++ b/arch/x86/mm/iomap_32.c
@@ -78,13 +78,13 @@ void __iomem *
 iomap_atomic_prot_pfn(unsigned long pfn, pgprot_t prot)
 {
/*
-* For non-PAT systems, promote PAGE_KERNEL_WC to PAGE_KERNEL_UC_MINUS.
-* PAGE_KERNEL_WC maps to PWT, which translates to uncached if the
-* MTRR is UC or WC.  UC_MINUS gets the real intention, of the
-* user, which is "WC if the MTRR is WC, UC if you can't do that."
+* For non-PAT systems, translate non-WB request to UC- just in
+* case the caller set the PWT bit to prot directly without using
+* pgprot_writecombine(). UC- translates to uncached if the MTRR
+* is UC or WC. UC- gets the real intention, of the user, which is
+* "WC if the MTRR is WC, UC if you can't do that."
 */
-   if (!pat_enabled() && pgprot_val(prot) ==
-   (__PAGE_KERNEL | cachemode2protval(_PAGE_CACHE_MODE_WC)))
+   if (!pat_enabled() && pgprot2cachemode(prot) != _PAGE_CACHE_MODE_WB)
prot = __pgprot(__PAGE_KERNEL |
cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS));
 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 938609e..078c270 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -292,11 +292,8 @@ EXPORT_SYMBOL_GPL(ioremap_uc);
  */
 void __iomem *ioremap_wc(resource_size_t phys_addr, unsigned long size)
 {
-   if (pat_enabled())
-   return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WC,
+   return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WC,
__builtin_return_address(0));
-   else
-   return ioremap_nocache(phys_addr, size);
 }
 EXPORT_SYMBOL(ioremap_wc);
 
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 70d221f..94aae76 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1571,9 +1571,6 @@ int set_memory_wc(unsigned long addr, int numpages)
 {
int ret;
 
-   if (!pat_enabled())
-   return set_memory_uc(addr, numpages);
-
ret = reserve_memtype(__pa(addr), __pa(addr) + numpages * PAGE_SIZE,
_PAGE_CACHE_MODE_WC, NULL);
if (ret)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index e1ec6a7..819ae28 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -182,7 +182,11 @@ void pat_init_cache_modes(void)
char pat_msg[33];
u64 pat;
 
-   rdmsrl(MSR_IA32_CR_PAT, pat);
+   

[PATCH v11 8/12] video/fbdev, asm/io.h: Remove ioremap_writethrough()

[Toshi Kani]

From: Toshi Kani 

This patch removes the callers of ioremap_writethrough() by
replacing them with ioremap_wt() in three drivers under
drivers/video/fbdev.  It then removes ioremap_writethrough()
defined in some architecture's asm/io.h, frv, m68k, microblaze,
and tile.

Signed-off-by: Toshi Kani 
---
 arch/frv/include/asm/io.h|5 -
 arch/m68k/include/asm/io_mm.h|5 -
 arch/m68k/include/asm/io_no.h|4 
 arch/microblaze/include/asm/io.h |1 -
 arch/tile/include/asm/io.h   |1 -
 drivers/video/fbdev/amifb.c  |4 ++--
 drivers/video/fbdev/atafb.c  |3 +--
 drivers/video/fbdev/hpfb.c   |4 ++--
 8 files changed, 5 insertions(+), 22 deletions(-)

diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index 1fe98fe..a31b63e 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -267,11 +267,6 @@ static inline void __iomem *ioremap_nocache(unsigned long 
physaddr, unsigned lon
return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
 }
 
-static inline void __iomem *ioremap_writethrough(unsigned long physaddr, 
unsigned long size)
-{
-   return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
-}
-
 static inline void __iomem *ioremap_wt(unsigned long physaddr, unsigned long 
size)
 {
return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
diff --git a/arch/m68k/include/asm/io_mm.h b/arch/m68k/include/asm/io_mm.h
index 7c12138..618c85d3 100644
--- a/arch/m68k/include/asm/io_mm.h
+++ b/arch/m68k/include/asm/io_mm.h
@@ -467,11 +467,6 @@ static inline void __iomem *ioremap_nocache(unsigned long 
physaddr, unsigned lon
 {
return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
 }
-static inline void __iomem *ioremap_writethrough(unsigned long physaddr,
-unsigned long size)
-{
-   return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
-}
 static inline void __iomem *ioremap_wt(unsigned long physaddr,
 unsigned long size)
 {
diff --git a/arch/m68k/include/asm/io_no.h b/arch/m68k/include/asm/io_no.h
index 5fff9a2..ad7bd40 100644
--- a/arch/m68k/include/asm/io_no.h
+++ b/arch/m68k/include/asm/io_no.h
@@ -155,10 +155,6 @@ static inline void *ioremap_nocache(unsigned long 
physaddr, unsigned long size)
 {
return __ioremap(physaddr, size, IOMAP_NOCACHE_SER);
 }
-static inline void *ioremap_writethrough(unsigned long physaddr, unsigned long 
size)
-{
-   return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
-}
 static inline void *ioremap_wt(unsigned long physaddr, unsigned long size)
 {
return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
diff --git a/arch/microblaze/include/asm/io.h b/arch/microblaze/include/asm/io.h
index ec3da11..39b6315 100644
--- a/arch/microblaze/include/asm/io.h
+++ b/arch/microblaze/include/asm/io.h
@@ -39,7 +39,6 @@ extern resource_size_t isa_mem_base;
 extern void iounmap(void __iomem *addr);
 
 extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
-#define ioremap_writethrough(addr, size)   ioremap((addr), (size))
 #define ioremap_nocache(addr, size)ioremap((addr), (size))
 #define ioremap_fullcache(addr, size)  ioremap((addr), (size))
 #define ioremap_wc(addr, size) ioremap((addr), (size))
diff --git a/arch/tile/include/asm/io.h b/arch/tile/include/asm/io.h
index 9c3d950..dc61de1 100644
--- a/arch/tile/include/asm/io.h
+++ b/arch/tile/include/asm/io.h
@@ -55,7 +55,6 @@ extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(physaddr, size)ioremap(physaddr, size)
 #define ioremap_wc(physaddr, size) ioremap(physaddr, size)
 #define ioremap_wt(physaddr, size) ioremap(physaddr, size)
-#define ioremap_writethrough(physaddr, size)   ioremap(physaddr, size)
 #define ioremap_fullcache(physaddr, size)  ioremap(physaddr, size)
 
 #define mmiowb()
diff --git a/drivers/video/fbdev/amifb.c b/drivers/video/fbdev/amifb.c
index 35f7900..ee3a703 100644
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -3705,8 +3705,8 @@ default_chipset:
 * access the videomem with writethrough cache
 */
info->fix.smem_start = (u_long)ZTWO_PADDR(videomemory);
-   videomemory = (u_long)ioremap_writethrough(info->fix.smem_start,
-  info->fix.smem_len);
+   videomemory = (u_long)ioremap_wt(info->fix.smem_start,
+info->fix.smem_len);
if (!videomemory) {
dev_warn(>dev,
 "Unable to map videomem cached writethrough\n");
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index cb9ee25..d6ce613 100644
--- a/drivers/video/fbdev/atafb.c
+++ b/drivers/video/fbdev/atafb.c
@@ -3185,8 +3185,7 @@ int __init atafb_init(void)
/* Map the video memory (physical address given) to somewhere

[PATCH v11 7/12] arch/*/asm/io.h: Add ioremap_wt() to all architectures

[Toshi Kani]

From: Toshi Kani 

This patch adds ioremap_wt() to all arch-specific asm/io.h which
define ioremap_wc() locally.  These arch-specific asm/io.h do not
include .  Some of them include
, but ioremap_wt() is defined for consistency
since they define all ioremap_xxx locally.

ioremap_wt() is defined indentical to ioremap_nocache() to all
architectures without WT support.

frv and m68k already have ioremap_writethrough().  This patch
implements ioremap_wt() indetical to ioremap_writethrough() and
defines ARCH_HAS_IOREMAP_WT in both architectures.

This patch allows generic drivers to use ioremap_wt().

Signed-off-by: Toshi Kani 
---
 arch/arc/include/asm/io.h|1 +
 arch/arm/include/asm/io.h|1 +
 arch/arm64/include/asm/io.h  |1 +
 arch/avr32/include/asm/io.h  |1 +
 arch/frv/include/asm/io.h|7 +++
 arch/m32r/include/asm/io.h   |1 +
 arch/m68k/include/asm/io_mm.h|7 +++
 arch/m68k/include/asm/io_no.h|6 ++
 arch/metag/include/asm/io.h  |3 +++
 arch/microblaze/include/asm/io.h |1 +
 arch/mn10300/include/asm/io.h|1 +
 arch/nios2/include/asm/io.h  |1 +
 arch/s390/include/asm/io.h   |1 +
 arch/sparc/include/asm/io_32.h   |1 +
 arch/sparc/include/asm/io_64.h   |1 +
 arch/tile/include/asm/io.h   |1 +
 arch/xtensa/include/asm/io.h |1 +
 17 files changed, 36 insertions(+)

diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index cabd518..7cc4ced 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -20,6 +20,7 @@ extern void iounmap(const void __iomem *addr);
 
 #define ioremap_nocache(phy, sz)   ioremap(phy, sz)
 #define ioremap_wc(phy, sz)ioremap(phy, sz)
+#define ioremap_wt(phy, sz)ioremap(phy, sz)
 
 /* Change struct page to physical address */
 #define page_to_phys(page) (page_to_pfn(page) << PAGE_SHIFT)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index db58deb..1b7677d 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -336,6 +336,7 @@ extern void _memset_io(volatile void __iomem *, int, 
size_t);
 #define ioremap_nocache(cookie,size)   __arm_ioremap((cookie), (size), 
MT_DEVICE)
 #define ioremap_cache(cookie,size) __arm_ioremap((cookie), (size), 
MT_DEVICE_CACHED)
 #define ioremap_wc(cookie,size)__arm_ioremap((cookie), (size), 
MT_DEVICE_WC)
+#define ioremap_wt(cookie,size)__arm_ioremap((cookie), (size), 
MT_DEVICE)
 #define iounmap__arm_iounmap
 
 /*
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 540f7c0..7116d39 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -170,6 +170,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, 
size_t size);
 #define ioremap(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_nocache(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_wc(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_NORMAL_NC))
+#define ioremap_wt(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define iounmap__iounmap
 
 /*
diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index 4f5ec2b..e998ff5 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -296,6 +296,7 @@ extern void __iounmap(void __iomem *addr);
__iounmap(addr)
 
 #define ioremap_wc ioremap_nocache
+#define ioremap_wt ioremap_nocache
 
 #define cached(addr) P1SEGADDR(addr)
 #define uncached(addr) P2SEGADDR(addr)
diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index 0b78bc8..1fe98fe 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -17,6 +17,8 @@
 
 #ifdef __KERNEL__
 
+#define ARCH_HAS_IOREMAP_WT
+
 #include 
 #include 
 #include 
@@ -270,6 +272,11 @@ static inline void __iomem *ioremap_writethrough(unsigned 
long physaddr, unsigne
return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
 }
 
+static inline void __iomem *ioremap_wt(unsigned long physaddr, unsigned long 
size)
+{
+   return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
+}
+
 static inline void __iomem *ioremap_fullcache(unsigned long physaddr, unsigned 
long size)
 {
return __ioremap(physaddr, size, IOMAP_FULL_CACHING);
diff --git a/arch/m32r/include/asm/io.h b/arch/m32r/include/asm/io.h
index 9cc00db..0c3f25e 100644
--- a/arch/m32r/include/asm/io.h
+++ b/arch/m32r/include/asm/io.h
@@ -68,6 +68,7 @@ static inline void __iomem *ioremap(unsigned long offset, 
unsigned long size)
 extern void iounmap(volatile void __iomem *addr);
 #define ioremap_nocache(off,size) ioremap(off,size)
 #define ioremap_wc ioremap_nocache
+#define ioremap_wt ioremap_nocache
 
 /*
  * IO bus memory addresses are also 1:1 with the physical address
diff 

[PATCH v11 12/12] drivers/block/pmem: Map NVDIMM with ioremap_wt()

[Toshi Kani]

From: Toshi Kani 

The pmem driver maps NVDIMM with ioremap_nocache() as we cannot
write back the contents of the CPU caches in case of a crash.

This patch changes to use ioremap_wt(), which provides uncached
writes but cached reads, for improving read performance.

Signed-off-by: Toshi Kani 
---
 drivers/block/pmem.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/block/pmem.c b/drivers/block/pmem.c
index eabf4a8..095dfaa 100644
--- a/drivers/block/pmem.c
+++ b/drivers/block/pmem.c
@@ -139,11 +139,11 @@ static struct pmem_device *pmem_alloc(struct device *dev, 
struct resource *res)
}
 
/*
-* Map the memory as non-cachable, as we can't write back the contents
+* Map the memory as write-through, as we can't write back the contents
 * of the CPU caches in case of a crash.
 */
err = -ENOMEM;
-   pmem->virt_addr = ioremap_nocache(pmem->phys_addr, pmem->size);
+   pmem->virt_addr = ioremap_wt(pmem->phys_addr, pmem->size);
if (!pmem->virt_addr)
goto out_release_region;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 6/12] x86, mm, asm-gen: Add ioremap_wt() for WT

[Toshi Kani]

From: Toshi Kani 

This patch adds ioremap_wt() for creating WT mapping on x86.
It follows the same model as ioremap_wc() for multi-architecture
support.  ARCH_HAS_IOREMAP_WT is defined in the x86 version of
io.h to indicate that ioremap_wt() is implemented on x86.

Also update the PAT documentation file to cover ioremap_wt().

Signed-off-by: Toshi Kani 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Thomas Gleixner 
---
 Documentation/x86/pat.txt   |4 +++-
 arch/x86/include/asm/io.h   |2 ++
 arch/x86/mm/ioremap.c   |   21 +
 include/asm-generic/io.h|9 +
 include/asm-generic/iomap.h |4 
 5 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index 521bd8a..db0de6c 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -12,7 +12,7 @@ virtual addresses.
 
 PAT allows for different types of memory attributes. The most commonly used
 ones that will be supported at this time are Write-back, Uncached,
-Write-combined and Uncached Minus.
+Write-combined, Write-through and Uncached Minus.
 
 
 PAT APIs
@@ -40,6 +40,8 @@ ioremap_nocache|--|UC- |   UC-
|
|  ||  |
 ioremap_wc |--|--  |   WC |
|  ||  |
+ioremap_wt |--|--  |   WT |
+   |  ||  |
 set_memory_uc  |UC-   |--  |   -- |
  set_memory_wb |  ||  |
|  ||  |
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index a2b9740..6c3a130 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -35,6 +35,7 @@
   */
 
 #define ARCH_HAS_IOREMAP_WC
+#define ARCH_HAS_IOREMAP_WT
 
 #include 
 #include 
@@ -321,6 +322,7 @@ extern void unxlate_dev_mem_ptr(phys_addr_t phys, void 
*addr);
 extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
enum page_cache_mode pcm);
 extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
+extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size);
 
 extern bool is_early_ioremap_ptep(pte_t *ptep);
 
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 078c270..779b1a2 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -172,6 +172,10 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
prot = __pgprot(pgprot_val(prot) |
cachemode2protval(_PAGE_CACHE_MODE_WC));
break;
+   case _PAGE_CACHE_MODE_WT:
+   prot = __pgprot(pgprot_val(prot) |
+   cachemode2protval(_PAGE_CACHE_MODE_WT));
+   break;
case _PAGE_CACHE_MODE_WB:
break;
}
@@ -297,6 +301,23 @@ void __iomem *ioremap_wc(resource_size_t phys_addr, 
unsigned long size)
 }
 EXPORT_SYMBOL(ioremap_wc);
 
+/**
+ * ioremap_wt  -   map memory into CPU space write through
+ * @phys_addr: bus address of the memory
+ * @size:  size of the resource to map
+ *
+ * This version of ioremap ensures that the memory is marked write through.
+ * Write through stores data into memory while keeping the cache up-to-date.
+ *
+ * Must be freed with iounmap.
+ */
+void __iomem *ioremap_wt(resource_size_t phys_addr, unsigned long size)
+{
+   return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WT,
+   __builtin_return_address(0));
+}
+EXPORT_SYMBOL(ioremap_wt);
+
 void __iomem *ioremap_cache(resource_size_t phys_addr, unsigned long size)
 {
return __ioremap_caller(phys_addr, size, _PAGE_CACHE_MODE_WB,
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 90ccba7..f56094c 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -785,8 +785,17 @@ static inline void __iomem *ioremap_wc(phys_addr_t offset, 
size_t size)
 }
 #endif
 
+#ifndef ioremap_wt
+#define ioremap_wt ioremap_wt
+static inline void __iomem *ioremap_wt(phys_addr_t offset, size_t size)
+{
+   return ioremap_nocache(offset, size);
+}
+#endif
+
 #ifndef iounmap
 #define iounmap iounmap
+
 static inline void iounmap(void __iomem *addr)
 {
 }
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 1b41011..d8f8622 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -66,6 +66,10 @@ extern void ioport_unmap(void __iomem *);
 #define ioremap_wc ioremap_nocache
 #endif
 
+#ifndef ARCH_HAS_IOREMAP_WT
+#define ioremap_wt ioremap_nocache
+#endif
+
 #ifdef CONFIG_PCI
 /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
 struct pci_dev;
--
To 

[PATCH v11 0/12] Support Write-Through mapping on x86

[Toshi Kani]

This patchset adds support of Write-Through (WT) mapping on x86.
The study below shows that using WT mapping may be useful for
non-volatile memory.

http://www.hpl.hp.com/techreports/2012/HPL-2012-236.pdf

The patchset consists of the following changes.
 - Patch 1/12 to 2/12 refactor !pat_enable paths
 - Patch 3/12 to 8/12 add ioremap_wt()
 - Patch 9/12 adds pgprot_writethrough()
 - Patch 10/12 to 11/12 add set_memory_wt()
 - Patch 12/12 changes the pmem driver to call ioremap_wt()

All new/modified interfaces have been tested.

---
v11:
- Reordered the refactor changes from patch 10-11 to 1-2.
  (Borislav Petkov)
- Changed BUG() to panic(). (Borislav Petkov)
- Rebased to tip/master and resolved conflicts. 

v10:
- Removed ioremap_writethrough(). (Thomas Gleixner)
- Clarified and cleaned up multiple comments and functions.
  (Thomas Gleixner) 
- Changed ioremap_change_attr() to accept the WT type.

v9:
- Changed to export the set_xxx_wt() interfaces with GPL.
  (Ingo Molnar)
- Changed is_new_memtype_allowed() to handle WT cases.
- Changed arch-specific io.h to define ioremap_wt().
- Changed the pmem driver to use ioremap_wt().
- Rebased to 4.1-rc3 and resolved minor conflicts.

v8:
- Rebased to 4.0-rc1 and resolved conflicts with 9d34cfdf4 in
  patch 5/7.

v7:
- Rebased to 3.19-rc3 as Juergen's patchset for the PAT management
  has been accepted.

v6:
- Dropped the patch moving [set|get]_page_memtype() to pat.c
  since the tip branch already has this change.
- Fixed an issue when CONFIG_X86_PAT is not defined.

v5:
- Clarified comment of why using slot 7. (Andy Lutomirski,
  Thomas Gleixner)
- Moved [set|get]_page_memtype() to pat.c. (Thomas Gleixner)
- Removed BUG() from set_page_memtype(). (Thomas Gleixner)

v4:
- Added set_memory_wt() by adding WT support of regular memory.

v3:
- Dropped the set_memory_wt() patch. (Andy Lutomirski)
- Refactored the !pat_enabled handling. (H. Peter Anvin,
  Andy Lutomirski)
- Added the picture of PTE encoding. (Konrad Rzeszutek Wilk)

v2:
- Changed WT to use slot 7 of the PAT MSR. (H. Peter Anvin,
  Andy Lutomirski)
- Changed to have conservative checks to exclude all Pentium 2, 3,
  M, and 4 families. (Ingo Molnar, Henrique de Moraes Holschuh,
  Andy Lutomirski)
- Updated documentation to cover WT interfaces and usages.
  (Andy Lutomirski, Yigal Korman)

---
Toshi Kani (12):
 1/12 x86, mm, pat: Cleanup init flags in pat_init()
 2/12 x86, mm, pat: Refactor !pat_enable handling
 3/12 x86, mm, pat: Set WT to PA7 slot of PAT MSR
 4/12 x86, mm, pat: Change reserve_memtype() for WT
 5/12 x86, asm: Change is_new_memtype_allowed() for WT
 6/12 x86, mm, asm-gen: Add ioremap_wt() for WT
 7/12 arch/*/asm/io.h: Add ioremap_wt() to all architectures
 8/12 video/fbdev, asm/io.h: Remove ioremap_writethrough()
 9/12 x86, mm, pat: Add pgprot_writethrough() for WT
10/12 x86, mm, asm: Add WT support to set_page_memtype()
11/12 x86, mm: Add set_memory_wt() for WT
12/12 drivers/block/pmem: Map NVDIMM with ioremap_wt()

---
 Documentation/x86/pat.txt|  13 +-
 arch/arc/include/asm/io.h|   1 +
 arch/arm/include/asm/io.h|   1 +
 arch/arm64/include/asm/io.h  |   1 +
 arch/avr32/include/asm/io.h  |   1 +
 arch/frv/include/asm/io.h|   4 +-
 arch/m32r/include/asm/io.h   |   1 +
 arch/m68k/include/asm/io_mm.h|   4 +-
 arch/m68k/include/asm/io_no.h|   4 +-
 arch/metag/include/asm/io.h  |   3 +
 arch/microblaze/include/asm/io.h |   2 +-
 arch/mn10300/include/asm/io.h|   1 +
 arch/nios2/include/asm/io.h  |   1 +
 arch/s390/include/asm/io.h   |   1 +
 arch/sparc/include/asm/io_32.h   |   1 +
 arch/sparc/include/asm/io_64.h   |   1 +
 arch/tile/include/asm/io.h   |   2 +-
 arch/x86/include/asm/cacheflush.h|   6 +-
 arch/x86/include/asm/io.h|   2 +
 arch/x86/include/asm/pgtable.h   |   8 +-
 arch/x86/include/asm/pgtable_types.h |   3 +
 arch/x86/mm/init.c   |   6 +-
 arch/x86/mm/iomap_32.c   |  12 +-
 arch/x86/mm/ioremap.c|  29 -
 arch/x86/mm/pageattr.c   |  65 +++---
 arch/x86/mm/pat.c| 229 +++
 arch/xtensa/include/asm/io.h |   1 +
 drivers/block/pmem.c |   4 +-
 drivers/video/fbdev/amifb.c  |   4 +-
 drivers/video/fbdev/atafb.c  |   3 +-
 drivers/video/fbdev/hpfb.c   |   4 +-
 include/asm-generic/io.h |   9 ++
 include/asm-generic/iomap.h  |   4 +
 include/asm-generic/pgtable.h|   4 +
 34 files changed, 310 insertions(+), 125 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/

Re: [PATCH] perf probe: Fix segfault when glob matching function without debuginfo

[Masami Hiramatsu]

On 2015/05/29 18:45, Wang Nan wrote:
> Commit 4c859351226c920b227fec040a3b447f0d482af3 ("perf probe: Support
> glob wildcards for function name") introduces segfault problems when
> debuginfo is not available:
> 
>  # perf probe 'sys_w*'
>   Added new events:
>   Segmentation fault
> 
> The first problem resides in find_probe_trace_events_from_map(). In
> that function, find_probe_functions() is called to match each symbol
> against glob to find the number of matching functions, but still use
> map__for_each_symbol_by_name() to find 'struct symbol' for matching
> functions. Unfortunately, map__for_each_symbol_by_name() does
> exact matching by searching in an rbtree. It doesn't know glob
> matching, and not easy for it to support it because it use rbtree based
> binary search, but we are unable to ensure all names matched by the
> glob (any glob passed by user) reside in one subtree.
> 
> This patch drops map__for_each_symbol_by_name(). Since there is no
> rbtree again, re-matching all symbols costs a lot. This patch avoid it
> by saving all matching results into an array (syms).
> 
> The second problem is the lost of tp->realname. In
> __add_probe_trace_events(), if pev->point.function is glob, the event
> name should be set to tev->point.realname. This patch ensures its
> existence by strdup sym->name instead of leaving a NULL pointer there.

Good catch!

Acked-by: Masami Hiramatsu 

Thank you!

> 
> After this patch:
> 
>  # perf probe 'sys_w*'
>  Added new events:
>probe:sys_waitid (on sys_w*)
>probe:sys_wait4  (on sys_w*)
>probe:sys_waitpid(on sys_w*)
>probe:sys_write  (on sys_w*)
>probe:sys_writev (on sys_w*)
> 
>  You can now use it in all perf tools, such as:
> 
>  perf record -e probe:sys_writev -aR sleep 1
> 
> Signed-off-by: Wang Nan 
> ---
>  tools/perf/util/probe-event.c | 26 +-
>  1 file changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 9052e7b..4f1bc78 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -2493,7 +2493,8 @@ close_out:
>   return ret;
>  }
>  
> -static int find_probe_functions(struct map *map, char *name)
> +static int find_probe_functions(struct map *map, char *name,
> + struct symbol **syms)
>  {
>   int found = 0;
>   struct symbol *sym;
> @@ -2503,8 +2504,11 @@ static int find_probe_functions(struct map *map, char 
> *name)
>   return 0;
>  
>   map__for_each_symbol(map, sym, tmp) {
> - if (strglobmatch(sym->name, name))
> + if (strglobmatch(sym->name, name)) {
>   found++;
> + if (syms && found < probe_conf.max_probes)
> + syms[found - 1] = sym;
> + }
>   }
>  
>   return found;
> @@ -2527,11 +2531,12 @@ static int find_probe_trace_events_from_map(struct 
> perf_probe_event *pev,
>   struct map *map = NULL;
>   struct ref_reloc_sym *reloc_sym = NULL;
>   struct symbol *sym;
> + struct symbol **syms = NULL;
>   struct probe_trace_event *tev;
>   struct perf_probe_point *pp = >point;
>   struct probe_trace_point *tp;
>   int num_matched_functions;
> - int ret, i;
> + int ret, i, j;
>  
>   map = get_target_map(pev->target, pev->uprobes);
>   if (!map) {
> @@ -2539,11 +2544,17 @@ static int find_probe_trace_events_from_map(struct 
> perf_probe_event *pev,
>   goto out;
>   }
>  
> + syms = malloc(sizeof(struct symbol *) * probe_conf.max_probes);
> + if (!syms) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
>   /*
>* Load matched symbols: Since the different local symbols may have
>* same name but different addresses, this lists all the symbols.
>*/
> - num_matched_functions = find_probe_functions(map, pp->function);
> + num_matched_functions = find_probe_functions(map, pp->function, syms);
>   if (num_matched_functions == 0) {
>   pr_err("Failed to find symbol %s in %s\n", pp->function,
>   pev->target ? : "kernel");
> @@ -2574,7 +2585,9 @@ static int find_probe_trace_events_from_map(struct 
> perf_probe_event *pev,
>  
>   ret = 0;
>  
> - map__for_each_symbol_by_name(map, pp->function, sym) {
> + for (j = 0; j < num_matched_functions; j++) {
> + sym = syms[j];
> +
>   tev = (*tevs) + ret;
>   tp = >point;
>   if (ret == num_matched_functions) {
> @@ -2598,6 +2611,8 @@ static int find_probe_trace_events_from_map(struct 
> perf_probe_event *pev,
>   tp->symbol = strdup_or_goto(sym->name, nomem_out);
>   tp->offset = pp->offset;
>   }
> + tp->realname = strdup_or_goto(sym->name, nomem_out);
> +
>   tp->retprobe = 

[PATCH] gcov: add support for GCC 5.1

[Lorenzo Stoakes]

This patch fixes kernel gcov support for GCC 5.1. Similar to commit
a992bf836f9c3039a16f4bd068d161c86c6c3e2c this patch takes into account
the existence of a new gcov counter (see gcc's gcc/gcov-counter.def.)

Firstly, it increments GCOV_COUNTERS (to 10), which makes the data
structure struct gcov_info compatible with GCC 5.1.

Secondly, a corresponding counter function __gcov_merge_icall_topn (Top
 N value tracking for indirect calls) is included in base.c with the
other gcov counters unused for kernel profiling.

Signed-off-by: Lorenzo Stoakes 
---
 kernel/gcov/base.c| 6 ++
 kernel/gcov/gcc_4_7.c | 4 +++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/kernel/gcov/base.c b/kernel/gcov/base.c
index a744098..7080ae1 100644
--- a/kernel/gcov/base.c
+++ b/kernel/gcov/base.c
@@ -92,6 +92,12 @@ void __gcov_merge_time_profile(gcov_type *counters, unsigned 
int n_counters)
 }
 EXPORT_SYMBOL(__gcov_merge_time_profile);

+void __gcov_merge_icall_topn(gcov_type *counters, unsigned int n_counters)
+{
+   /* Unused. */
+}
+EXPORT_SYMBOL(__gcov_merge_icall_topn);
+
 /**
  * gcov_enable_events - enable event reporting through gcov_event()
  *
diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
index 826ba9f..e25e92f 100644
--- a/kernel/gcov/gcc_4_7.c
+++ b/kernel/gcov/gcc_4_7.c
@@ -18,7 +18,9 @@
 #include 
 #include "gcov.h"

-#if __GNUC__ == 4 && __GNUC_MINOR__ >= 9
+#if __GNUC__ == 5 && __GNUC_MINOR__ >= 1
+#define GCOV_COUNTERS  10
+#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
 #define GCOV_COUNTERS  9
 #else
 #define GCOV_COUNTERS  8
--
2.4.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] psmouse - focaltech report finger width to userspace

[Dmitry Tunin]

Focaltech touchpads report finger width in packet[5] of absolute packet.
Range for width in raw format is 0x10 - 0x70. Second half-byte is always 0.
0xff is reported, when a large contact area is detected.
This can be handled in userspace.

Signed-off-by: Dmitry Tunin 
---
 drivers/input/mouse/focaltech.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/input/mouse/focaltech.c b/drivers/input/mouse/focaltech.c
index 23d2594..0c3b698 100644
--- a/drivers/input/mouse/focaltech.c
+++ b/drivers/input/mouse/focaltech.c
@@ -105,6 +105,16 @@ struct focaltech_hw_state {
 
/* True if the clickpad has been pressed. */
bool pressed;
+
+   /*
+   * Finger width 0-7 and 15 for a very big contact area.
+   * 15 value stays until the finger is released.
+   * Width is reported only in absolute packets.
+   * Since hardware reports width only for last touching finger,
+   * there is no need to store width for every specific finger, so 
+   * we keep only last value reported.
+   */
+   unsigned int width;
 };
 
 struct focaltech_data {
@@ -112,7 +122,7 @@ struct focaltech_data {
struct focaltech_hw_state state;
 };
 
-static void focaltech_report_state(struct psmouse *psmouse)
+static void focaltech_report_state(struct psmouse *psmouse, bool abs)
 {
struct focaltech_data *priv = psmouse->private;
struct focaltech_hw_state *state = >state;
@@ -137,6 +147,7 @@ static void focaltech_report_state(struct psmouse *psmouse)
input_report_abs(dev, ABS_MT_POSITION_X, clamped_x);
input_report_abs(dev, ABS_MT_POSITION_Y,
 priv->y_max - clamped_y);
+   if (abs) input_report_abs(dev, ABS_TOOL_WIDTH, 
state->width);
}
}
input_mt_report_pointer_emulation(dev, true);
@@ -187,6 +198,7 @@ static void focaltech_process_abs_packet(struct psmouse 
*psmouse,
 
state->fingers[finger].x = ((packet[1] & 0xf) << 8) | packet[2];
state->fingers[finger].y = (packet[3] << 8) | packet[4];
+   state->width = packet[5] >> 4;
state->fingers[finger].valid = true;
 }
 
@@ -228,22 +240,23 @@ static void focaltech_process_packet(struct psmouse 
*psmouse)
switch (packet[0] & 0xf) {
case FOC_TOUCH:
focaltech_process_touch_packet(psmouse, packet);
+   focaltech_report_state(psmouse, false);
break;
 
case FOC_ABS:
focaltech_process_abs_packet(psmouse, packet);
+   focaltech_report_state(psmouse, true);
break;
 
case FOC_REL:
focaltech_process_rel_packet(psmouse, packet);
+   focaltech_report_state(psmouse, false);
break;
 
default:
psmouse_err(psmouse, "Unknown packet type: %02x\n", packet[0]);
break;
}
-
-   focaltech_report_state(psmouse);
 }
 
 static psmouse_ret_t focaltech_process_byte(struct psmouse *psmouse)
@@ -331,6 +344,7 @@ static void focaltech_set_input_params(struct psmouse 
*psmouse)
__set_bit(EV_ABS, dev->evbit);
input_set_abs_params(dev, ABS_MT_POSITION_X, 0, priv->x_max, 0, 0);
input_set_abs_params(dev, ABS_MT_POSITION_Y, 0, priv->y_max, 0, 0);
+   input_set_abs_params(dev, ABS_TOOL_WIDTH, 0, 15, 0, 0);
input_mt_init_slots(dev, 5, INPUT_MT_POINTER);
__set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
 }
-- 
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] Drivers: staging: Fixed comment and helpline spelling errors

[Colin Cronin]

Fixed a few spelling errors in commented code, helpline text, and a TODO list
Files changed:
drivers/staging/dgnc/TODO
drivers/staging/dgnc/dgnc_driver.h
drivers/staging/dgnc/dgnc_tty.c
drivers/staging/emxx_udc/emxx_udc.c
drivers/staging/fbtft/Kconfig

Signed-off-by: Colin Cronin 
---
 drivers/staging/dgnc/TODO   | 4 ++--
 drivers/staging/dgnc/dgnc_driver.h  | 2 +-
 drivers/staging/dgnc/dgnc_tty.c | 2 +-
 drivers/staging/emxx_udc/emxx_udc.c | 2 +-
 drivers/staging/fbtft/Kconfig   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/dgnc/TODO b/drivers/staging/dgnc/TODO
index 2b2c6ea..cbc679d 100644
--- a/drivers/staging/dgnc/TODO
+++ b/drivers/staging/dgnc/TODO
@@ -1,6 +1,6 @@
 * checkpatch fixes
-* remove unecessary comments
-* remove unecessary error messages. Example kzalloc() has its
+* remove unnecessary comments
+* remove unnecessary error messages. Example kzalloc() has its
   own error message. Adding an extra one is useless.
 * use goto statements for error handling when appropriate
 * there is a lot of unecessary code in the driver. It was
diff --git a/drivers/staging/dgnc/dgnc_driver.h 
b/drivers/staging/dgnc/dgnc_driver.h
index f77fed5..e3e3cdc 100644
--- a/drivers/staging/dgnc/dgnc_driver.h
+++ b/drivers/staging/dgnc/dgnc_driver.h
@@ -73,7 +73,7 @@
 /*
  * Define a local default termios struct. All ports will be created
  * with this termios initially.  This is the same structure that is defined
- * as the default in tty_io.c with the same settings overriden as in serial.c
+ * as the default in tty_io.c with the same settings overridden as in serial.c
  *
  * In short, this should match the internal serial ports' defaults.
  */
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index ce4187f..b62f781 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -436,7 +436,7 @@ void dgnc_tty_uninit(struct dgnc_board *brd)
  * dgnc_wmove - Write data to transmit queue.
  *
  * ch  - Pointer to channel structure.
- * buf - Poiter to characters to be moved.
+ * buf - Pointer to characters to be moved.
  * n   - Number of characters to move.
  *
  *===*/
diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index fbf82bc..18e30d2 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -1223,7 +1223,7 @@ static int _nbu2ss_epn_in_transfer(
}
 
/*-*/
-   /* Start tranfer */
+   /* Start transfer */
iBufSize = req->req.length - req->req.actual;
if (iBufSize > 0)
result = _nbu2ss_epn_in_data(udc, ep, req, iBufSize);
diff --git a/drivers/staging/fbtft/Kconfig b/drivers/staging/fbtft/Kconfig
index 6cf0c58..346f189 100644
--- a/drivers/staging/fbtft/Kconfig
+++ b/drivers/staging/fbtft/Kconfig
@@ -12,7 +12,7 @@ config FB_TFT_AGM1264K_FL
tristate "FB driver for the AGM1264K-FL LCD display"
depends on FB_TFT
help
- Framebuffer support for the AGM1264K-FL LCD display (two Samsung 
KS0108 compatable chips)
+ Framebuffer support for the AGM1264K-FL LCD display (two Samsung 
KS0108 compatible chips)
 
 config FB_TFT_BD663474
tristate "FB driver for the BD663474 LCD Controller"
-- 
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 v8 0/7] arm64,hi6220: Enable Hisilicon Hi6220 SoC

[Kevin Hilman]

Hi Bintian,

Bintian Wang  writes:

> From: Bintian Wang 
>
> Hi6220 is one mobile solution of Hisilicon, this patchset contains
> initial support for Hi6220 SoC and HiKey development board, which
> supports octal ARM Cortex A53 cores. Initial support is minimal and
> includes just the arch configuration, clock driver, device tree
> configuration.
>
> PSCI is enabled in device tree and there is no problem to boot all the
> octal cores, and the CPU hotplug is also working now, you can download
> and compile the latest firmware based on the following link to run this
> patch set:
> https://github.com/96boards/documentation/wiki/UEFI
>
> Changes v6~v8:
> This three versions only modified the clock drivers based on the
> Stephen's review advices.
> * clk-hi6220.c:
>   ** Split the clock header file from clock driver
>   ** Delete setting the parents clock of UART1 to HI6220_150M in clock
>  driver, we can do that using assigned-clock in dts when enable
>  UART1 in the future.
> * clkdivider-hi6220.c: 
>   ** Reuse some functions exported by clk-divider.c
>   ** Remove "pr_err" and CLK_IS_BASIC flag
>   ** Fix some programing style problems
> * hisilicon/clk.h: remove the "__init" markings on some funcition
>   prototypes.

It's not clear what kernel this series is meant to apply to.  It doesn't
apply cleanly to v4.1-rc2 (the version stated for v5) or the current -rc
(v4.1-rc5) it also doesn't apply cleanly to linus/master or linux-next.

If the series doesn't apply to Linus tree, please state clearly in the
changelog what tree it should apply to as well as any dependncies.

Also, this version is missing patch 1 from the v6 series, which adds the
Kconfig/defconfig changes. Without that patch, nothing in this series is
even compiled (clk driver or DTS files.)

So my recommendation, since the clock driver is very close to being
merged:

Please create a v9 series with *only* the patches that are not already
queued up on the clk tree[1].  That should be patches 1-3 and 7 of this
series, plus patch 1 from v6.

That series should apply cleanly to v4.1-rc1 (or a newer -rc if there
are dependencies.)  In the changelog to that series, state the version
that it applies to, and also state that it depends on the clk-next
branch where the clock maintainers have queued up the driver[1].

Then all that's left is to collect an ack from a DT maintainer, and
these can be queued up via the arm-soc tree.

FWIW, I've boot tested patches 1-3 and 7 of this series, plus patch 1
from v6 combined with the clk-next-hi6220 branch[1] on my board (which
uses ATF + mainline u-boot) and all 8 A53 cores are coming up, so feel
free to add:

Tested-by: Kevin Hilman 

to your v9 series.

Thanks,

Kevin

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

A Must See!

[Pastor Chris Online]

Click to have an experience of a lifetime



If you no longer wish to receive these emails, kindly click
http://lmtransmissions.com/mailinglist/lists/lt.php?id=YxgFCgFUD1xcXB0DUwJIBARUVwYB


To forward this email to someone, kindly click
http://lmtransmissions.com/mailinglist/lists/lt.php?id=YxgFCgFUD1xcXR0DUwJIBARUVwYB



--
Powered by PHPlist, www.phplist.com --


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

[GIT PULL] xfs: update for v4.1-rc6

[Dave Chinner]

Hi Linus,

Can you please pull the fixes from the tag below? It's a little
larger than I'd like late in the release cycle, but all the fixes
are for regressions introduced in the 4.1-rc1 merge, or are needed
back in -stable kernels fairly quickly as they are filesystem
corruption or userspace visible correctness issues.

Thanks!

-Dave.

The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22:

  Linux 4.1-rc2 (2015-05-03 19:22:23 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git 
tags/xfs-for-linus-4.1-rc6

for you to fetch changes up to 22419ac9fe5e79483596cebdbd1d1209c18bac1a:

  xfs: fix broken i_nlink accounting for whiteout tmpfile inode (2015-05-29 
08:14:55 +1000)


xfs: update for 4.1-rc6

Changes in this update:
o regression fix for new rename whiteout code
o regression fixes for new superblock generic per-cpu counter code
o fix for incorrect error return sign introduced in 3.17
o metadata corruption fixes that need to go back to -stable kernels


Brian Foster (1):
  xfs: fix broken i_nlink accounting for whiteout tmpfile inode

Dave Chinner (5):
  percpu_counter: batch size aware __percpu_counter_compare()
  xfs: inode and free block counters need to use __percpu_counter_compare
  xfs: extent size hints can round up extents past MAXEXTLEN
  xfs: xfs_attr_inactive leaves inconsistent attr fork state behind
  xfs: xfs_iozero can return positive errno

George Wang (1):
  xfs: use percpu_counter_read_positive for mp->m_icount

 fs/xfs/libxfs/xfs_attr_leaf.c  |8 ++--
 fs/xfs/libxfs/xfs_attr_leaf.h  |2 +-
 fs/xfs/libxfs/xfs_bmap.c   |   31 +--
 fs/xfs/libxfs/xfs_ialloc.c |9 +++--
 fs/xfs/xfs_attr_inactive.c |   83 
 fs/xfs/xfs_file.c  |2 +-
 fs/xfs/xfs_inode.c |   22 ++-
 fs/xfs/xfs_mount.c |   34 +---
 include/linux/percpu_counter.h |   13 ++-
 lib/percpu_counter.c   |6 +--
 10 files changed, 127 insertions(+), 83 deletions(-)

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

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

[Andrew Morton]

On Sat, 16 May 2015 19:48:18 -0400 Mathieu Desnoyers 
 wrote:

> Here is an implementation of a new system call, sys_membarrier(), which
> executes a memory barrier on all threads running on the system. It is
> implemented by calling synchronize_sched(). It can be used to distribute
> the cost of user-space memory barriers asymmetrically by transforming
> pairs of memory barriers into pairs consisting of sys_membarrier() and a
> compiler barrier. For synchronization primitives that distinguish
> between read-side and write-side (e.g. userspace RCU [1], rwlocks), the
> read-side can be accelerated significantly by moving the bulk of the
> memory barrier overhead to the write-side.
>
> ...
>

It would be nice to hear about the real world value of this syscall to
our users.  I'm seeing test results for a microbenchmark but so what. 
What actual applications or application classes are calling for this and
what results can they expect to see?

> 
> membarrier(2) man page:
> --- snip ---
> MEMBARRIER(2)  Linux Programmer's Manual MEMBARRIER(2)
> 
> NAME
>membarrier - issue memory barriers on a set of threads
> 
> SYNOPSIS
>#include 
> 
>int membarrier(int cmd, int flags);
> 
> DESCRIPTION
>The cmd argument is one of the following:
> 
>MEMBARRIER_CMD_QUERY
>   Query  the  set  of  supported commands. It returns a bitmask of
>   supported commands.
> 
>MEMBARRIER_CMD_SHARED
>   Execute a memory barrier on all threads running on  the  system.
>   Upon  return from system call, the caller thread is ensured that
>   all running threads have passed through a state where all memory
>   accesses  to  user-space  addresses  match program order between
>   entry to and return from the system  call  (non-running  threads
>   are de facto in such a state). This covers threads from all 
> pro___
>   cesses running on the system.  This command returns 0.
> 
>The flags argument needs to be 0. For future extensions.
> 
>All memory accesses performed  in  program  order  from  each  targeted
>thread is guaranteed to be ordered with respect to sys_membarrier(). If
>we use the semantic "barrier()" to represent a compiler barrier forcing
>memory  accesses  to  be performed in program order across the barrier,
>and smp_mb() to represent explicit memory barriers forcing full  memory
>ordering  across  the barrier, we have the following ordering table for
>each pair of barrier(), sys_membarrier() and smp_mb():
> 
>The pair ordering is detailed as (O: ordered, X: not ordered):
> 
>   barrier()   smp_mb() sys_membarrier()
>   barrier()  X   XO
>   smp_mb()   X   OO
>   sys_membarrier()   O   OO
> 
> RETURN VALUE
>On success, these system calls return zero.  On error, -1 is  returned,
>and errno is set appropriately. For a given command, with flags
>argument set to 0, this system call is guaranteed to always return the
>same value until reboot.

I suggest "with flags argument set to MEMBARRIER_CMD_QUERY" here.

> 
> ERRORS
>ENOSYS System call is not implemented.
> 
>EINVAL Invalid arguments.
> 
> ...
>
> +SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
> +{
> + if (flags)
> + return -EINVAL;

I'm not a huge fan of this "add a flags arg to syscalls" rule.  Is
there any realistic expectation that we'll ever *use* this thing?  If
not, why add it?

You may as well put an unlikely() in there btw.

> + switch (cmd) {
> + case MEMBARRIER_CMD_QUERY:
> + return MEMBARRIER_CMD_BITMASK;
> + case MEMBARRIER_CMD_SHARED:
> + if (num_online_cpus() > 1)
> + synchronize_sched();
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}

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

[PATCH 03/19] x86, mpx: Use new get_xsave_field_ptr()

[Dave Hansen]

From: Dave Hansen 

The MPX registers (bndcsr/bndcfgu/bndstatus) are not directly
accessible via normal instructions.  They essentially act as
if they were floating point registers and are saved/restored
along with those registers.

There are two main paths in the MPX code where we care about
the contents of these registers:
1. #BR (bounds) faults
2. the prctl() code where we are setting MPX up

Both of those paths _might_ be called without the FPU having
been used.  That means that 'tsk->thread.fpu.state' might
never be allocated.

Also, fpu_save_init() is not preempt-safe.  It was a bug to
call it without disabling preemption.  The new
get_xsave_addr() calls unlazy_fpu() instead and properly
disables preemption.

Signed-off-by: Dave Hansen 
Reviewed-by: Thomas Gleixner 
Cc: Oleg Nesterov 
Cc: b...@alien8.de
Cc: Rik van Riel 
Cc: Suresh Siddha 
Cc: Andy Lutomirski 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Fenghua Yu 
Cc: the arch/x86 maintainers 
Cc: linux-kernel 

---

Changes from v21:
 * rename get_xsave_field() to get_xsave_field_ptr()
---

 b/arch/x86/include/asm/mpx.h |8 
 b/arch/x86/kernel/traps.c|   15 +++
 b/arch/x86/mm/mpx.c  |   24 
 3 files changed, 23 insertions(+), 24 deletions(-)

diff -puN arch/x86/include/asm/mpx.h~use-new-tsk_get_xsave_addr 
arch/x86/include/asm/mpx.h
--- a/arch/x86/include/asm/mpx.h~use-new-tsk_get_xsave_addr 2015-05-27 
09:32:15.346481924 -0700
+++ b/arch/x86/include/asm/mpx.h2015-05-27 09:32:15.353482240 -0700
@@ -60,8 +60,8 @@
 
 #ifdef CONFIG_X86_INTEL_MPX
 siginfo_t *mpx_generate_siginfo(struct pt_regs *regs,
-   struct xregs_state *xsave_buf);
-int mpx_handle_bd_fault(struct xregs_state *xsave_buf);
+   struct task_struct *tsk);
+int mpx_handle_bd_fault(struct task_struct *tsk);
 static inline int kernel_managing_mpx_tables(struct mm_struct *mm)
 {
return (mm->bd_addr != MPX_INVALID_BOUNDS_DIR);
@@ -78,11 +78,11 @@ void mpx_notify_unmap(struct mm_struct *
  unsigned long start, unsigned long end);
 #else
 static inline siginfo_t *mpx_generate_siginfo(struct pt_regs *regs,
- struct xregs_state *xsave_buf)
+ struct task_struct *tsk)
 {
return NULL;
 }
-static inline int mpx_handle_bd_fault(struct xregs_state *xsave_buf)
+static inline int mpx_handle_bd_fault(struct task_struct *tsk)
 {
return -EINVAL;
 }
diff -puN arch/x86/kernel/traps.c~use-new-tsk_get_xsave_addr 
arch/x86/kernel/traps.c
--- a/arch/x86/kernel/traps.c~use-new-tsk_get_xsave_addr2015-05-27 
09:32:15.348482015 -0700
+++ b/arch/x86/kernel/traps.c   2015-05-27 09:32:15.353482240 -0700
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_X86_64
@@ -371,7 +372,6 @@ dotraplinkage void do_double_fault(struc
 dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
 {
struct task_struct *tsk = current;
-   struct xregs_state *xsave_buf;
enum ctx_state prev_state;
struct bndcsr *bndcsr;
siginfo_t *info;
@@ -392,12 +392,11 @@ dotraplinkage void do_bounds(struct pt_r
 
/*
 * We need to look at BNDSTATUS to resolve this exception.
-* It is not directly accessible, though, so we need to
-* do an xsave and then pull it out of the xsave buffer.
+* A NULL here might mean that it is in its 'init state',
+* which is all zeros which indicates MPX was not
+* responsible for the exception.
 */
-   copy_fpregs_to_fpstate(>thread.fpu);
-   xsave_buf = &(tsk->thread.fpu.state.xsave);
-   bndcsr = get_xsave_addr(xsave_buf, XSTATE_BNDCSR);
+   bndcsr = get_xsave_field_ptr(XSTATE_BNDCSR);
if (!bndcsr)
goto exit_trap;
 
@@ -408,11 +407,11 @@ dotraplinkage void do_bounds(struct pt_r
 */
switch (bndcsr->bndstatus & MPX_BNDSTA_ERROR_CODE) {
case 2: /* Bound directory has invalid entry. */
-   if (mpx_handle_bd_fault(xsave_buf))
+   if (mpx_handle_bd_fault(tsk))
goto exit_trap;
break; /* Success, it was handled */
case 1: /* Bound violation. */
-   info = mpx_generate_siginfo(regs, xsave_buf);
+   info = mpx_generate_siginfo(regs, tsk);
if (IS_ERR(info)) {
/*
 * We failed to decode the MPX instruction.  Act as if
diff -puN arch/x86/mm/mpx.c~use-new-tsk_get_xsave_addr arch/x86/mm/mpx.c
--- a/arch/x86/mm/mpx.c~use-new-tsk_get_xsave_addr  2015-05-27 
09:32:15.349482059 -0700
+++ b/arch/x86/mm/mpx.c 2015-05-27 09:32:15.354482285 -0700
@@ -272,7 +272,7 @@ bad_opcode:
  * The caller is expected to kfree() the returned siginfo_t.
  */
 siginfo_t *mpx_generate_siginfo(struct pt_regs *regs,

[PATCH 05/19] x86, mpx: remove redundant MPX_BNDCFG_ADDR_MASK

[Dave Hansen]

From: Qiaowei Ren 

MPX_BNDCFG_ADDR_MASK is defined two times, so this patch removes
redundant one.

Signed-off-by: Qiaowei Ren 
Signed-off-by: Dave Hansen 
Reviewed-by: Thomas Gleixner 
---

 b/arch/x86/include/asm/mpx.h |1 -
 1 file changed, 1 deletion(-)

diff -puN 
arch/x86/include/asm/mpx.h~0001-x86-mpx-remove-redundant-MPX_BNDCFG_ADDR_MASK 
arch/x86/include/asm/mpx.h
--- 
a/arch/x86/include/asm/mpx.h~0001-x86-mpx-remove-redundant-MPX_BNDCFG_ADDR_MASK 
2015-05-27 09:32:16.296524773 -0700
+++ b/arch/x86/include/asm/mpx.h2015-05-27 09:32:16.299524908 -0700
@@ -45,7 +45,6 @@
 #define MPX_BNDSTA_TAIL2
 #define MPX_BNDCFG_TAIL12
 #define MPX_BNDSTA_ADDR_MASK   (~((1UL

[PATCH 04/19] x86, mpx: Cleanup: Do not pass task around when unnecessary

[Dave Hansen]

From: Dave Hansen 

The MPX code can only work on the current task.  You can not, for
instance, enable MPX management in another process or thread.
You can also not handle a fault for another process or thread.

Despite this, we pass a task_struct around prolifically.  This
patch removes all of the task struct passing for code paths where
the code can not deal with another task (which turns out to be
all of them).

This has no functional changes.  It's just a cleanup.

Signed-off-by: Dave Hansen 
Reviewed-by: Thomas Gleixner 
Cc: Oleg Nesterov 
Cc: b...@alien8.de
Cc: the arch/x86 maintainers 
Cc: linux-kernel 
---

 b/arch/x86/include/asm/mpx.h   |   10 --
 b/arch/x86/include/asm/processor.h |   12 ++--
 b/arch/x86/kernel/traps.c  |5 ++---
 b/arch/x86/mm/mpx.c|   19 +--
 b/kernel/sys.c |8 
 5 files changed, 25 insertions(+), 29 deletions(-)

diff -puN arch/x86/include/asm/mpx.h~x86-mpx-dont-pass-current-around 
arch/x86/include/asm/mpx.h
--- a/arch/x86/include/asm/mpx.h~x86-mpx-dont-pass-current-around   
2015-05-27 09:32:15.793502086 -0700
+++ b/arch/x86/include/asm/mpx.h2015-05-27 09:32:15.804502582 -0700
@@ -59,9 +59,8 @@
MPX_BT_ENTRY_MASK) << MPX_BT_ENTRY_SHIFT)
 
 #ifdef CONFIG_X86_INTEL_MPX
-siginfo_t *mpx_generate_siginfo(struct pt_regs *regs,
-   struct task_struct *tsk);
-int mpx_handle_bd_fault(struct task_struct *tsk);
+siginfo_t *mpx_generate_siginfo(struct pt_regs *regs);
+int mpx_handle_bd_fault(void);
 static inline int kernel_managing_mpx_tables(struct mm_struct *mm)
 {
return (mm->bd_addr != MPX_INVALID_BOUNDS_DIR);
@@ -77,12 +76,11 @@ static inline void mpx_mm_init(struct mm
 void mpx_notify_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
  unsigned long start, unsigned long end);
 #else
-static inline siginfo_t *mpx_generate_siginfo(struct pt_regs *regs,
- struct task_struct *tsk)
+static inline siginfo_t *mpx_generate_siginfo(struct pt_regs *regs)
 {
return NULL;
 }
-static inline int mpx_handle_bd_fault(struct task_struct *tsk)
+static inline int mpx_handle_bd_fault(void)
 {
return -EINVAL;
 }
diff -puN arch/x86/include/asm/processor.h~x86-mpx-dont-pass-current-around 
arch/x86/include/asm/processor.h
--- a/arch/x86/include/asm/processor.h~x86-mpx-dont-pass-current-around 
2015-05-27 09:32:15.795502176 -0700
+++ b/arch/x86/include/asm/processor.h  2015-05-27 09:32:15.804502582 -0700
@@ -802,18 +802,18 @@ extern int get_tsc_mode(unsigned long ad
 extern int set_tsc_mode(unsigned int val);
 
 /* Register/unregister a process' MPX related resource */
-#define MPX_ENABLE_MANAGEMENT(tsk) mpx_enable_management((tsk))
-#define MPX_DISABLE_MANAGEMENT(tsk)mpx_disable_management((tsk))
+#define MPX_ENABLE_MANAGEMENT()mpx_enable_management()
+#define MPX_DISABLE_MANAGEMENT()   mpx_disable_management()
 
 #ifdef CONFIG_X86_INTEL_MPX
-extern int mpx_enable_management(struct task_struct *tsk);
-extern int mpx_disable_management(struct task_struct *tsk);
+extern int mpx_enable_management(void);
+extern int mpx_disable_management(void);
 #else
-static inline int mpx_enable_management(struct task_struct *tsk)
+static inline int mpx_enable_management(void)
 {
return -EINVAL;
 }
-static inline int mpx_disable_management(struct task_struct *tsk)
+static inline int mpx_disable_management(void)
 {
return -EINVAL;
 }
diff -puN arch/x86/kernel/traps.c~x86-mpx-dont-pass-current-around 
arch/x86/kernel/traps.c
--- a/arch/x86/kernel/traps.c~x86-mpx-dont-pass-current-around  2015-05-27 
09:32:15.797502266 -0700
+++ b/arch/x86/kernel/traps.c   2015-05-27 09:32:15.805502627 -0700
@@ -371,7 +371,6 @@ dotraplinkage void do_double_fault(struc
 
 dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
 {
-   struct task_struct *tsk = current;
enum ctx_state prev_state;
struct bndcsr *bndcsr;
siginfo_t *info;
@@ -407,11 +406,11 @@ dotraplinkage void do_bounds(struct pt_r
 */
switch (bndcsr->bndstatus & MPX_BNDSTA_ERROR_CODE) {
case 2: /* Bound directory has invalid entry. */
-   if (mpx_handle_bd_fault(tsk))
+   if (mpx_handle_bd_fault())
goto exit_trap;
break; /* Success, it was handled */
case 1: /* Bound violation. */
-   info = mpx_generate_siginfo(regs, tsk);
+   info = mpx_generate_siginfo(regs);
if (IS_ERR(info)) {
/*
 * We failed to decode the MPX instruction.  Act as if
diff -puN arch/x86/mm/mpx.c~x86-mpx-dont-pass-current-around arch/x86/mm/mpx.c
--- a/arch/x86/mm/mpx.c~x86-mpx-dont-pass-current-around2015-05-27 
09:32:15.799502356 -0700
+++ b/arch/x86/mm/mpx.c 2015-05-27 09:32:15.806502672 -0700
@@ 

[PATCH 02/19] x86, fpu: Wrap get_xsave_addr() to make it safer

[Dave Hansen]

From: Dave Hansen 

The MPX code appears to be saving off the FPU in a potntially
unsafe way (if eagerfpu=off).  It does not disable preemption or
ensure that the FPU state has been allocated.  All of the
preemption safety comes from the unfortunatley-named
'unlazy_fpu()'.

This patch introduces a new helper which will do both of those
things internally.

Signed-off-by: Dave Hansen 
Reviewed-by: Thomas Gleixner 
Cc: Oleg Nesterov 
Cc: b...@alien8.de
Cc: Rik van Riel 
Cc: Suresh Siddha 
Cc: Andy Lutomirski 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Fenghua Yu 
Cc: the arch/x86 maintainers 

---

Changes from v21:
 * add comments about preemption
 * rename helper to get_xsave_field_ptr()

Changes from "v19":
 * remove 'tsk' argument to get_xsave_addr() since the code
   can only realistically work on 'current', and fix up the
   comment a bit to match.

Changes from "v17":
 * fix s/xstate/xsave_field/ in the function comment
 * remove EXPORT_SYMBOL_GPL()

---

 b/arch/x86/include/asm/fpu/xstate.h |1 +
 b/arch/x86/kernel/fpu/xstate.c  |   32 
 2 files changed, 33 insertions(+)

diff -puN arch/x86/include/asm/fpu/xstate.h~tsk_get_xsave_addr 
arch/x86/include/asm/fpu/xstate.h
--- a/arch/x86/include/asm/fpu/xstate.h~tsk_get_xsave_addr  2015-05-28 
08:49:45.191271502 -0700
+++ b/arch/x86/include/asm/fpu/xstate.h 2015-05-29 13:43:34.291184369 -0700
@@ -41,5 +41,6 @@ extern u64 xstate_fx_sw_bytes[USER_XSTAT
 extern void update_regset_xstate_info(unsigned int size, u64 xstate_mask);
 
 void *get_xsave_addr(struct xregs_state *xsave, int xstate);
+const void *get_xsave_field_ptr(int xstate_field);
 
 #endif
diff -puN arch/x86/kernel/fpu/xstate.c~tsk_get_xsave_addr 
arch/x86/kernel/fpu/xstate.c
--- a/arch/x86/kernel/fpu/xstate.c~tsk_get_xsave_addr   2015-05-28 
08:49:45.192271546 -0700
+++ b/arch/x86/kernel/fpu/xstate.c  2015-05-29 12:32:47.869662576 -0700
@@ -427,3 +427,35 @@ void *get_xsave_addr(struct xregs_state
return (void *)xsave + xstate_comp_offsets[feature_nr];
 }
 EXPORT_SYMBOL_GPL(get_xsave_addr);
+
+/*
+ * This wraps up the common operations that need to occur when retrieving
+ * data from xsave state.  It first ensures that the current task was
+ * using the FPU and retrieves the data in to a buffer.  It then calculates
+ * the offset of the requested field in the buffer.
+ *
+ * This function is safe to call whether the FPU is in use or not.
+ *
+ * Note that this only works on the current task.
+ *
+ * Inputs:
+ * @xsave_state: state which is defined in xsave.h (e.g. XSTATE_FP,
+ * XSTATE_SSE, etc...)
+ * Output:
+ * address of the state in the xsave area or NULL if the state
+ * is not present or is in its 'init state'.
+ */
+const void *get_xsave_field_ptr(int xsave_state)
+{
+   struct fpu *fpu = >thread.fpu;
+
+   if (!fpu->fpstate_active)
+   return NULL;
+   /*
+* fpu__save() takes the CPU's xstate registers
+* and saves them off to the 'fpu memory buffer.
+*/
+   fpu__save(fpu);
+
+   return get_xsave_addr(>xstate->xsave, xsave_state);
+}
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/19] x86, mpx updates for 4.2 (take 8)

[Dave Hansen]

Changes from take 7 / v22:
 * Add Thomas's reviewed-by
 * merge with tip/x86/fpu changes
 * Fix tiny spelling nit

Changes from take 6 / v21:
 * Address a bunch of Thomas's review comments.

Changes from take 5 / v20:

 * Fix get_xsave_addr() to consult xstate_bv in anticipation
   of fixes to xsave code.
 * Bug fix for when an VMA being unmapped has neighbors which
   are bounds tables.
 * Rewrite unmapping code.  I didn't do this lightly. It was
   not originally my own code, and I resisted changing it
   because it worked.  But, I started bug chasing and decided
   it was unmaintainable.  The rewrite ended up removing
   about 20% of the unmapping code and made it much simpler.

Changes from take 4 / v19:

 * Do not pass a task_struct around when we are
   really just going to operate on current

Changes from take 3 / v18 (all minor):

 * use DECLARE_EVENT_CLASS()/DEFINE_EVENT() for
   the ranged tracepoints to save 10 lines of code.

Changes from take 2 / v17 (all minor):

 * fix a couple of whitespace borkages caught by checkpatch,
   and a spelling error or two.
 * replace printk with pr_info() for boot disable
 * change trace print format for address intervals
 * fix up variable name in tsk_get_xsave_addr() comment
 * remove tsk_get_xsave_field() GPL export
 * fix up Qiaowei's From:

--

Hi x86 maintainers,

There are a few basic things going on here:
1. Make FPU/xsave code preempt safe and work properly
2. Add trace points to make kernel and app debugging easier
3. Add a boot-time disable for mpx
4. Rewrite the unmapping code.
5. Support 32-bit binaries to run on 64-bit kernels

This set is also available against tip/x86/fpu (8c05f05edb) in git:

  git://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-mpx.git mpx-v23

Dave Hansen (19):
  x86, mpx, xsave: Fix up bad get_xsave_addr() assumptions
  x86, fpu: Wrap get_xsave_addr() to make it safer
  x86, mpx: Use new get_xsave_field_ptr()
  x86, mpx: Cleanup: Do not pass task around when unnecessary
  x86, mpx: remove redundant MPX_BNDCFG_ADDR_MASK
  x86, mpx: Restrict mmap size check to bounds tables
  x86, mpx: boot-time disable
  x86, mpx: trace #BR exceptions
  x86, mpx: trace entry to bounds exception paths
  x86, mpx: Trace the attempts to find bounds tables
  x86, mpx: trace allocation of new bounds tables
  x86: make is_64bit_mm() widely available
  x86, mpx: Add temporary variable to reduce masking
  x86, mpx: new directory entry to addr helper
  x86, mpx: do 32-bit-only cmpxchg for 32-bit apps
  x86, mpx: support 32-bit binaries on 64-bit kernel
  x86, mpx: rewrite unmap code
  x86, mpx: do not count MPX VMAs as neighbors when unmapping
  x86, mpx: allow mixed binaries again

 Documentation/kernel-parameters.txt |   4 +
 arch/x86/include/asm/fpu/xstate.h   |   1 +
 arch/x86/include/asm/mmu_context.h  |  13 +
 arch/x86/include/asm/mpx.h  |  74 +++---
 arch/x86/include/asm/processor.h|  12 +-
 arch/x86/include/asm/trace/mpx.h| 131 ++
 arch/x86/kernel/cpu/common.c|  16 ++
 arch/x86/kernel/fpu/xstate.c|  78 +-
 arch/x86/kernel/traps.c |  18 +-
 arch/x86/kernel/uprobes.c   |  10 +-
 arch/x86/mm/mpx.c   | 508 ++--
 kernel/sys.c|   8 +-
 12 files changed, 606 insertions(+), 267 deletions(-)
 create mode 100644 arch/x86/include/asm/trace/mpx.h

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

[PATCH 01/19] x86, mpx, xsave: Fix up bad get_xsave_addr() assumptions

[Dave Hansen]

From: Dave Hansen 

get_xsave_addr() assumes that if an xsave bit is present in the
hardware (pcntxt_mask) that it is present in a given xsave
buffer.  Due to an bug in the xsave code on all of the systems
that have MPX (and thus all the users of this code), that has
been a true assumption.

But, the bug is getting fixed, so our assumption is not going
to hold any more.

It's quite possible (and normal) for an enabled state to be
present on 'pcntxt_mask', but *not* in 'xstate_bv'.  We need
to consult 'xstate_bv'.

Signed-off-by: Dave Hansen 
Reviewed-by: Thomas Gleixner 
---

 b/arch/x86/kernel/fpu/xstate.c |   45 +
 1 file changed, 37 insertions(+), 8 deletions(-)

diff -puN arch/x86/kernel/fpu/xstate.c~consullt-xstate_bv 
arch/x86/kernel/fpu/xstate.c
--- a/arch/x86/kernel/fpu/xstate.c~consullt-xstate_bv   2015-05-27 
09:32:14.540445571 -0700
+++ b/arch/x86/kernel/fpu/xstate.c  2015-05-27 09:32:14.543445706 -0700
@@ -382,19 +382,48 @@ void fpu__resume_cpu(void)
  * This is the API that is called to get xstate address in either
  * standard format or compacted format of xsave area.
  *
+ * Note that if there is no data for the field in the xsave buffer
+ * this will return NULL.
+ *
  * Inputs:
- * xsave: base address of the xsave area;
- * xstate: state which is defined in xsave.h (e.g. XSTATE_FP, XSTATE_SSE,
- * etc.)
+ * xstate: the thread's storage area for all FPU data
+ * xstate_feature: state which is defined in xsave.h (e.g.
+ * XSTATE_FP, XSTATE_SSE, etc...)
  * Output:
- * address of the state in the xsave area.
+ * address of the state in the xsave area, or NULL if the
+ * field is not present in the xsave buffer.
  */
-void *get_xsave_addr(struct xregs_state *xsave, int xstate)
+void *get_xsave_addr(struct xregs_state *xsave, int xstate_feature)
 {
-   int feature = fls64(xstate) - 1;
-   if (!test_bit(feature, (unsigned long *)_mask))
+   int feature_nr = fls64(xstate_feature) - 1;
+   /*
+* Do we even *have* xsave state?
+*/
+   if (!boot_cpu_has(X86_FEATURE_XSAVE))
+   return NULL;
+
+   xsave = >thread.fpu.state.xsave;
+   /*
+* We should not ever be requesting features that we
+* have not enabled.  Remember that pcntxt_mask is
+* what we write to the XCR0 register.
+*/
+   WARN_ONCE(!(xfeatures_mask & xstate_feature),
+ "get of unsupported state");
+   /*
+* This assumes the last 'xsave*' instruction to
+* have requested that 'xstate_feature' be saved.
+* If it did not, we might be seeing and old value
+* of the field in the buffer.
+*
+* This can happen because the last 'xsave' did not
+* request that this feature be saved (unlikely)
+* or because the "init optimization" caused it
+* to not be saved.
+*/
+   if (!(xsave->header.xfeatures & xstate_feature))
return NULL;
 
-   return (void *)xsave + xstate_comp_offsets[feature];
+   return (void *)xsave + xstate_comp_offsets[feature_nr];
 }
 EXPORT_SYMBOL_GPL(get_xsave_addr);
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/12] drivers/block/pmem: Map NVDIMM with ioremap_wt()

[H. Peter Anvin]

Nontemporal stores to WB memory is fine in such a way that it doesn't pollute 
the cache.  This can be done by denoting to WC or by forcing cache allocation 
out of only a subset of the cache.

On May 29, 2015 2:46:19 PM PDT, Andy Lutomirski  wrote:
>On Fri, May 29, 2015 at 2:29 PM, Elliott, Robert (Server Storage)
> wrote:
>>> -Original Message-
>>> From: Andy Lutomirski [mailto:l...@amacapital.net]
>>> Sent: Friday, May 29, 2015 1:35 PM
>> ...
>>> Whoa, there!  Why would we use non-temporal stores to WB memory to
>>> access persistent memory?  I can see two reasons not to:
>>
>> Data written to a block storage device (here, the NVDIMM) is unlikely
>> to be read or written again any time soon.  It's not like the code
>> and data that a program has in memory, where there might be a loop
>> accessing the location every CPU clock; it's storage I/O to
>> historically very slow (relative to the CPU clock speed) devices.
>> The source buffer for that data might be frequently accessed,
>> but not the NVDIMM storage itself.
>>
>> Non-temporal stores avoid wasting cache space on these "one-time"
>> accesses.  The same applies for reads and non-temporal loads.
>> Keep the CPU data cache lines free for the application.
>>
>> DAX and mmap() do change that; the application is now free to
>> store frequently accessed data structures directly in persistent
>> memory.  But, that's not available if btt is used, and
>> application loads and stores won't go through the memcpy()
>> calls inside pmem anyway.  The non-temporal instructions are
>> cache coherent, so data integrity won't get confused by them
>> if I/O going through pmem's block storage APIs happens
>> to overlap with the application's mmap() regions.
>>
>
>You answered the wrong question. :)  I understand the point of the
>non-temporal stores -- I don't understand the point of using
>non-temporal stores to *WB memory*.  I think we should be okay with
>having the kernel mapping use WT instead.
>
>--Andy

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

Re: [PATCH 1/2] PCI: Add pci_bus_addr_t

[Bjorn Helgaas]

[+cc David, linux-arch, linux-kernel]

TL;DR: Use the new pci_bus_addr_t to contain raw PCI bus addresses.  This
is of interest primarily in the PCI core because arch code mostly uses
resources (CPU physical addresses) and drivers mostly use ioremap to obtain
CPU virtual addresses.

On Wed, May 27, 2015 at 05:23:51PM -0700, Yinghai Lu wrote:
> David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
> to fit in upstream windows") fails to boot on sparc/T5-8:
> 
> pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 
> 0x110204000)
> 
> The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
> addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
> etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
> including raw BAR values.  On sparc64, all DMA addresses fit in 32 bits, so
> dma_addr_t is a 32-bit type.  However, BAR values can be 64 bits wide, so
> they don't fit in a dma_addr_t.  d63e2e1f3df9 added new checking that
> tripped over this mismatch.
> 
> Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
> including both raw BAR values and DMA addresses.  This will be 64 bits
> on 64-bit platforms and on platforms with a 64-bit dma_addr_t.  Then
> dma_addr_t only needs to be wide enough to hold addresses from the DMA API.
> 
> Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream 
> windows")
> Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 
> 4GB")
> Link: 
> http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
> Link: 
> http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-ying...@kernel.org
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
> Reported-by: David Ahern 
> Tested-by: David Ahern 
> Signed-off-by: Yinghai Lu 
> [bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at least 
> as wide as dma_addr_t]
> Signed-off-by: Bjorn Helgaas 
> Acked-by: David S. Miller 
> CC: sta...@vger.kernel.org# v3.19+

I applied these both to pci/resources for v4.2.  I combined them into one
patch so the code and corresponding documentation changes are all together.

> ---
>  drivers/pci/Kconfig |4 
>  drivers/pci/bus.c   |   10 +-
>  drivers/pci/probe.c |   12 ++--
>  include/linux/pci.h |   12 +---
>  4 files changed, 24 insertions(+), 14 deletions(-)
> 
> Index: linux-2.6/drivers/pci/Kconfig
> ===
> --- linux-2.6.orig/drivers/pci/Kconfig
> +++ linux-2.6/drivers/pci/Kconfig
> @@ -1,6 +1,10 @@
>  #
>  # PCI configuration
>  #
> +config PCI_BUS_ADDR_T_64BIT
> + def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
> + depends on PCI
> +
>  config PCI_MSI
>   bool "Message Signaled Interrupts (MSI and MSI-X)"
>   depends on PCI
> Index: linux-2.6/drivers/pci/bus.c
> ===
> --- linux-2.6.orig/drivers/pci/bus.c
> +++ linux-2.6/drivers/pci/bus.c
> @@ -92,11 +92,11 @@ void pci_bus_remove_resources(struct pci
>  }
>  
>  static struct pci_bus_region pci_32_bit = {0, 0xULL};
> -#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> +#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
>  static struct pci_bus_region pci_64_bit = {0,
> - (dma_addr_t) 0xULL};
> -static struct pci_bus_region pci_high = {(dma_addr_t) 0x1ULL,
> - (dma_addr_t) 0xULL};
> + (pci_bus_addr_t) 0xULL};
> +static struct pci_bus_region pci_high = {(pci_bus_addr_t) 0x1ULL,
> + (pci_bus_addr_t) 0xULL};
>  #endif
>  
>  /*
> @@ -200,7 +200,7 @@ int pci_bus_alloc_resource(struct pci_bu
> resource_size_t),
>   void *alignf_data)
>  {
> -#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> +#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
>   int rc;
>  
>   if (res->flags & IORESOURCE_MEM_64) {
> Index: linux-2.6/drivers/pci/probe.c
> ===
> --- linux-2.6.orig/drivers/pci/probe.c
> +++ linux-2.6/drivers/pci/probe.c
> @@ -254,8 +254,8 @@ int __pci_read_base(struct pci_dev *dev,
>   }
>  
>   if (res->flags & IORESOURCE_MEM_64) {
> - if ((sizeof(dma_addr_t) < 8 || sizeof(resource_size_t) < 8) &&
> - sz64 > 0x1ULL) {
> + if ((sizeof(pci_bus_addr_t) < 8 || sizeof(resource_size_t) < 8)
> + && sz64 > 0x1ULL) {
>   res->flags |= IORESOURCE_UNSET | IORESOURCE_DISABLED;
>   res->start = 0;
>   res->end = 0;
> @@ -264,7 +264,7 @@ int __pci_read_base(struct pci_dev *dev,
>   goto out;
>   }
>  
> - if ((sizeof(dma_addr_t) < 8) && l) {
> + 

[PATCH] staging/lustre: Update header license for lustre_dlm_flags.h

[green]

From: Oleg Drokin 

lustre_dlm_flags.h was autogenerated with a wrong script that
mistakenly stated it is GPLv3 when in fact it should be GPLv2.

Also since we are no longer autogenerating this header, drop
all such mentionings.

Reported by: George G. Davis 

Signed-off-by: Oleg Drokin 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6599
Reviewed-on: http://review.whamcloud.com/14797
Reviewed-by: Andreas Dilger 
CC: George G. Davis 
---
 .../staging/lustre/lustre/include/lustre_dlm_flags.h| 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h 
b/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
index 16dcdbf..d4cc096 100644
--- a/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
+++ b/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h
@@ -1,17 +1,10 @@
 /*  -*- buffer-read-only: t -*- vi: set ro:
  *
- * DO NOT EDIT THIS FILE   (lustre_dlm_flags.h)
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 only,
+ * as published by the Free Software Foundation.
  *
- * It has been AutoGen-ed
- * From the definitionslustre_dlm_flags.def
- * and the template file   lustre_dlm_flags.tpl
- *
- * lustre 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 3 of the License, or
- * (at your option) any later version.
- *
- * lustre is distributed in the hope that it will be useful, but
+ * Lustre 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.
@@ -22,8 +15,6 @@
 /**
  * \file lustre_dlm_flags.h
  * The flags and collections of flags (masks) for \see struct ldlm_lock.
- * This file is derived from flag definitions in lustre_dlm_flags.def.
- * The format is defined in the lustre_dlm_flags.tpl template file.
  *
  * \addtogroup LDLM Lustre Distributed Lock Manager
  * @{
-- 
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 12/12] drivers/block/pmem: Map NVDIMM with ioremap_wt()

[Elliott, Robert (Server Storage)]

---
Robert Elliott, HP Server Storage

> -Original Message-
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Friday, May 29, 2015 4:46 PM
> To: Elliott, Robert (Server Storage)
> Cc: Dan Williams; Kani, Toshimitsu; Borislav Petkov; Ross Zwisler;
> H. Peter Anvin; Thomas Gleixner; Ingo Molnar; Andrew Morton; Arnd
> Bergmann; linux...@kvack.org; linux-kernel@vger.kernel.org; X86 ML;
> linux-nvd...@lists.01.org; Juergen Gross; Stefan Bader; Henrique de
> Moraes Holschuh; Yigal Korman; Konrad Rzeszutek Wilk; Luis
> Rodriguez; Christoph Hellwig; Matthew Wilcox
> Subject: Re: [PATCH v10 12/12] drivers/block/pmem: Map NVDIMM with
> ioremap_wt()
> 
> On Fri, May 29, 2015 at 2:29 PM, Elliott, Robert (Server Storage)
>  wrote:
> >> -Original Message-
> >> From: Andy Lutomirski [mailto:l...@amacapital.net]
> >> Sent: Friday, May 29, 2015 1:35 PM
> > ...
> >> Whoa, there!  Why would we use non-temporal stores to WB memory
> to
> >> access persistent memory?  I can see two reasons not to:
> >
> > Data written to a block storage device (here, the NVDIMM) is
> unlikely
> > to be read or written again any time soon.  It's not like the code
> > and data that a program has in memory, where there might be a loop
> > accessing the location every CPU clock; it's storage I/O to
> > historically very slow (relative to the CPU clock speed) devices.
> > The source buffer for that data might be frequently accessed,
> > but not the NVDIMM storage itself.
> >
> > Non-temporal stores avoid wasting cache space on these "one-time"
> > accesses.  The same applies for reads and non-temporal loads.
> > Keep the CPU data cache lines free for the application.
> >
> > DAX and mmap() do change that; the application is now free to
> > store frequently accessed data structures directly in persistent
> > memory.  But, that's not available if btt is used, and
> > application loads and stores won't go through the memcpy()
> > calls inside pmem anyway.  The non-temporal instructions are
> > cache coherent, so data integrity won't get confused by them
> > if I/O going through pmem's block storage APIs happens
> > to overlap with the application's mmap() regions.
> >
> 
> You answered the wrong question. :)  I understand the point of the
> non-temporal stores -- I don't understand the point of using
> non-temporal stores to *WB memory*.  I think we should be okay with
> having the kernel mapping use WT instead.

The cache type that the application chooses for its mmap()
view has to be compatible with that already selected by the 
kernel, or we run into:

Intel SDM 11.12.4 Programming the PAT
...
"The PAT allows any memory type to be specified in the page tables,
and therefore it is possible to have a single physical page mapped
to two or more different linear addresses, each with different
memory types. Intel does not support this practice because it may
lead to undefined operations that can result in a system failure. 
In particular, a WC page must never be aliased to a cacheable page
because WC writes may not check the processor caches."

Right now, application memory is always WB, so WB is the
only safe choice from this perspective (the system must have
ADR for safety from other perspectives). That might not be 
the best choice for all applications, though; some applications
might not want CPU caching all the data they run through here 
and prefer WC.  On a non-ADR system, WT might be the only 
safe choice.

Should there be a way for the application to specify a cache
type in its mmap() call? The type already selected by the
kernel driver could (carefully) be changed on the fly if 
it's different.

Non-temporal store performance is excellent under WB, WC, and WT;
if anything, I think WC edges ahead because it need not snoop
the cache. It's still poor under UC.

[PATCH 4/4] mfd: 88pm800: allocate pdata->rtc if not allocated earlier

[Vaibhav Hiremath]

RTC in pmic 88PM800 can run even the core is powered off, and user
can set alarm in RTC. When the alarm is timed out, the PMIC will power up
the core, and the whole system will boot up. And during PMIC driver probe,
it will read some register to find out whether this boot is caused by RTC
timeout or not, and pass on this information to the RTC driver.

So we need rtc platform data to be existed in PMIC driver to pass this
information.

Signed-off-by: Chao Xie 
Signed-off-by: Vaibhav Hiremath 
---
 drivers/mfd/88pm800.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 8ea4467..34546a1 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -586,6 +586,25 @@ static int pm800_probe(struct i2c_client *client,
return ret;
}
 
+   /*
+* RTC in pmic can run even the core is powered off, and user can set
+* alarm in RTC. When the alarm is time out, the PMIC will power up
+* the core, and the whole system will boot up. When PMIC driver is
+* probed, it will read out some register to find out whether this
+* boot is caused by RTC timeout or not, and it need pass this
+* information to RTC driver.
+* So we need rtc platform data to be existed to pass this information.
+*/
+   if (!pdata->rtc) {
+   pdata->rtc = devm_kzalloc(>dev,
+ sizeof(*(pdata->rtc)), GFP_KERNEL);
+   if (!pdata->rtc) {
+   dev_err(>dev,
+   "failed to allocate memory for rtc\n");
+   return -ENOMEM;
+   }
+   }
+
ret = pm80x_init(client);
if (ret) {
dev_err(>dev, "pm800_init fail\n");
-- 
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: Device Tree Blob (DTB) licence

[David Lang]

On Fri, 29 May 2015, Enrico Weigelt, metux IT consult wrote:

Important Notice: This message may contain confidential or privileged 
information. It is intended only for the person it was addressed to. If you 
are not the intended recipient of this email you may not copy, forward, 
disclose or otherwise use it or any part of it in any form whatsoever. If 
you received this email in error please notify the sender by replying and 
delete this message and any attachments without retaining a copy.


P.S. some of us actually care about licenses being appropriate to what
they're applied to, and at least theoretically capable of being
honored. Your email footer may be very slightly undermining your
position here.


This is just a dumb auto-generated footer, coming from my client's
mail server over here ... I'm just too lazy for setting up an own
MTA on my workstation. You can safely ignore that.


Arguing license issues and at the same time claiming that you should ignore a 
legal statement like the footer is a bit odd.


David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] /proc/$PID/status : show list NSpid data based on current process namespace.

[Andrew Morton]

On Fri, 29 May 2015 11:57:21 +0900 Kuenhwan Kwak  wrote:

> This patch helps creating a pid mapping data to parent processes.
> 
> Reading 'NSpid' field in '/proc/$PID/status' is currently a simple
> way to getting child pid from parent pid in userspace. But this field
> supplies only single direction mapping('parent pid' to 'child pid').
> If parent process want to translate child pid to current namespace pid,
> there is no way to get except full searching in current procfs.
> 
> This patch will helps in getting current namespace pid by reading child
> procfs file without any side effects.
> 
> For example, Process id is 24771 in level 0, 435 in level 1.
> a) The output of '/proc/24771/status' in level 0 namespace.
> NSpid : 24771 435
> 
> b) The output of '/proc/435/status' in level 1 namespace.
> NSpid : 435
> 
> c) Process in level 0 mount level1 proc to '/var/child/proc'
> after setns(). The output of '/var/child/proc/435/status' is
> NSpid : 24771 435
> 
> ...
>
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -83,6 +83,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -149,6 +150,9 @@ static inline void task_state(struct seq_file *m, struct 
> pid_namespace *ns,
>   const struct cred *cred;
>   pid_t ppid, tpid = 0, tgid, ngid;
>   unsigned int max_fds = 0;
> +#ifdef CONFIG_PID_NS
> + struct pid_namespace *current_pid_ns = task_active_pid_ns(current);
> +#endif
>  
>   rcu_read_lock();
>   ppid = pid_alive(p) ?
> @@ -198,19 +202,19 @@ static inline void task_state(struct seq_file *m, 
> struct pid_namespace *ns,
>  
>  #ifdef CONFIG_PID_NS
>   seq_puts(m, "\nNStgid:");
> - for (g = ns->level; g <= pid->level; g++)
> + for (g = current_pid_ns->level; g <= pid->level; g++)
>   seq_printf(m, "\t%d",
>   task_tgid_nr_ns(p, pid->numbers[g].ns));
>   seq_puts(m, "\nNSpid:");
> - for (g = ns->level; g <= pid->level; g++)
> + for (g = current_pid_ns->level; g <= pid->level; g++)
>   seq_printf(m, "\t%d",
>   task_pid_nr_ns(p, pid->numbers[g].ns));
>   seq_puts(m, "\nNSpgid:");
> - for (g = ns->level; g <= pid->level; g++)
> + for (g = current_pid_ns->level; g <= pid->level; g++)
>   seq_printf(m, "\t%d",
>   task_pgrp_nr_ns(p, pid->numbers[g].ns));
>   seq_puts(m, "\nNSsid:");
> - for (g = ns->level; g <= pid->level; g++)
> + for (g = current_pid_ns->level; g <= pid->level; g++)
>   seq_printf(m, "\t%d",
>   task_session_nr_ns(p, pid->numbers[g].ns));

These changes alter current behaviour, don't they?  How do we know this
won't impact existing userspace code?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] mfd: 88pm800: add device tree support

[Vaibhav Hiremath]

Add DT support to the 88pm800 driver along with below properties
- marvell,88pm800-irq-write-clear :
  Idicates whether interrupt status is cleared by write

Also, creates the DT binding text file,
Documentation/devicetree/bindings/mfd/88pm800.txt

Signed-off-by: Chao Xie 
Signed-off-by: Vaibhav Hiremath 
---
 Documentation/devicetree/bindings/mfd/88pm800.txt | 57 +++
 drivers/mfd/88pm800.c | 39 
 2 files changed, 96 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/88pm800.txt

diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt 
b/Documentation/devicetree/bindings/mfd/88pm800.txt
new file mode 100644
index 000..094951b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/88pm800.txt
@@ -0,0 +1,57 @@
+* Marvell 88PM800 Power Management IC
+
+Required parent device properties:
+- compatible : "marvell,88pm800"
+- reg : the I2C slave address for the 88pm800 chip
+- interrupts : IRQ line for the 88pm800 chip
+- interrupt-controller: describes the 88pm800 as an interrupt controller
+- #interrupt-cells : should be 1.
+   - The cell is the 88pm800 local IRQ number
+
+Optional parent device properties:
+- marvell,88pm800-irq-write-clr: indicates whether interrupt status is cleared 
by write
+
+88pm800 consists of a large and varied group of sub-devices:
+
+Device  Supply NamesDescription
+--  ---
+88pm80x-onkey  :   : On key
+88pm80x-rtc:   : RTC
+88pm80x:   : Regulators
+
+Note: More device list will follow
+
+Example:
+
+   pmic: 88pm800@30 {
+   compatible = "marvell,88pm800";
+   reg = <0x30>;
+   interrupts = <0 77 0x4>;
+   interrupt-parent = <>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   marvell,88pm800-irq-write-clr;
+
+   regulators {
+   compatible = "marvell,88pm80x-regulator";
+
+   buck1a: BUCK1A {
+   regulator-compatible = "88PM800-BUCK1A";
+   regulator-min-microvolt = <60>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   ldo1: LDO1 {
+   regulator-compatible = "88PM800-LDO1";
+   regulator-min-microvolt = <170>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   };
+   rtc {
+   compatible = "marvell,88pm80x-rtc";
+   };
+   };
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 841717a..06ee058 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Interrupt Registers */
 #define PM800_INT_STATUS1  (0x05)
@@ -121,6 +122,11 @@ static const struct i2c_device_id pm80x_id_table[] = {
 };
 MODULE_DEVICE_TABLE(i2c, pm80x_id_table);
 
+static const struct of_device_id pm80x_of_match_table[] = {
+   { .compatible = "marvell,88pm800", },
+   {},
+};
+
 static struct resource rtc_resources[] = {
{
 .name = "88pm80x-rtc",
@@ -133,6 +139,7 @@ static struct resource rtc_resources[] = {
 static struct mfd_cell rtc_devs[] = {
{
 .name = "88pm80x-rtc",
+.of_compatible = "marvell,88pm80x-rtc",
 .num_resources = ARRAY_SIZE(rtc_resources),
 .resources = _resources[0],
 .id = -1,
@@ -151,6 +158,7 @@ static struct resource onkey_resources[] = {
 static const struct mfd_cell onkey_devs[] = {
{
 .name = "88pm80x-onkey",
+.of_compatible = "marvell,88pm80x-onkey",
 .num_resources = 1,
 .resources = _resources[0],
 .id = -1,
@@ -160,6 +168,7 @@ static const struct mfd_cell onkey_devs[] = {
 static const struct mfd_cell regulator_devs[] = {
{
 .name = "88pm80x-regulator",
+.of_compatible = "marvell,88pm80x-regulator",
 .id = -1,
},
 };
@@ -538,14 +547,43 @@ out:
return ret;
 }
 
+static int pm800_probe_dt(struct device_node *np,
+struct device *dev,
+struct pm80x_platform_data *pdata)
+{
+   pdata->irq_mode =
+   of_property_read_bool(np, "marvell,88pm800-irq-write-clear");
+
+   return 0;
+}
+
+
 static int pm800_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
int ret = 0;
struct pm80x_chip 

[PATCH 3/4] rtc: 88pm80x: add device tree support

[Vaibhav Hiremath]

Along with DT support, this patch also cleans up the unnecessary
code around 'rtc_wakeup' initialization.

Signed-off-by: Chao Xie 
Signed-off-by: Vaibhav Hiremath 
---
 drivers/rtc/rtc-88pm80x.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index 7df0579..8f66519 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -251,17 +251,26 @@ static SIMPLE_DEV_PM_OPS(pm80x_rtc_pm_ops, 
pm80x_rtc_suspend, pm80x_rtc_resume);
 static int pm80x_rtc_probe(struct platform_device *pdev)
 {
struct pm80x_chip *chip = dev_get_drvdata(pdev->dev.parent);
-   struct pm80x_platform_data *pm80x_pdata =
-   dev_get_platdata(pdev->dev.parent);
-   struct pm80x_rtc_pdata *pdata = NULL;
+   struct pm80x_rtc_pdata *pdata = dev_get_platdata(>dev);
struct pm80x_rtc_info *info;
+   struct device_node *node = pdev->dev.of_node;
struct rtc_time tm;
unsigned long ticks = 0;
int ret;
 
-   pdata = dev_get_platdata(>dev);
-   if (pdata == NULL)
-   dev_warn(>dev, "No platform data!\n");
+   if (!pdata && !node) {
+   dev_err(>dev,
+   "pm80x-rtc requires platform data or of_node\n");
+   return -EINVAL;
+   }
+
+   if (!pdata) {
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   dev_err(>dev, "failed to allocate memory\n");
+   return -ENOMEM;
+   }
+   }
 
info =
devm_kzalloc(>dev, sizeof(struct pm80x_rtc_info), GFP_KERNEL);
@@ -327,11 +336,8 @@ static int pm80x_rtc_probe(struct platform_device *pdev)
regmap_update_bits(info->map, PM800_RTC_CONTROL, PM800_RTC1_USE_XO,
   PM800_RTC1_USE_XO);
 
-   if (pm80x_pdata) {
-   pdata = pm80x_pdata->rtc;
-   if (pdata)
-   info->rtc_dev->dev.platform_data = >rtc_wakeup;
-   }
+   /* remeber whether this power up is caused by PMIC RTC or not */
+   info->rtc_dev->dev.platform_data = >rtc_wakeup;
 
device_init_wakeup(>dev, 1);
 
-- 
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 2/4] mfd: 88pm800: use irq_mode to configure interrupt status reg clear method

[Vaibhav Hiremath]

>From the spec, bit 1 of reg 0xe (page 0): IN_CLEAR_MODE controls the
method of clearing interrupt status register of 88pm800;

  0: clear on read
  1: clear on write

Signed-off-by: zhaoy 
Signed-off-by: Vaibhav Hiremath 
---
 drivers/mfd/88pm800.c   | 4 +++-
 include/linux/mfd/88pm80x.h | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index 06ee058..8ea4467 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -391,7 +391,8 @@ static int device_irq_init_800(struct pm80x_chip *chip)
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
 
-   data = PM800_WAKEUP2_INT_CLEAR;
+   data = (chip->irq_mode) ?
+   PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
 
if (ret < 0)
@@ -514,6 +515,7 @@ static int device_800_init(struct pm80x_chip *chip,
}
 
chip->regmap_irq_chip = _irq_chip;
+   chip->irq_mode = pdata->irq_mode;
 
ret = device_irq_init_800(chip);
if (ret < 0) {
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 97cb283..6ed6c16 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -77,6 +77,8 @@ enum {
 #define PM800_WAKEUP2  (0x0E)
 #define PM800_WAKEUP2_INV_INT  (1 << 0)
 #define PM800_WAKEUP2_INT_CLEAR(1 << 1)
+#define PM800_WAKEUP2_INT_READ_CLEAR   (0 << 1)
+#define PM800_WAKEUP2_INT_WRITE_CLEAR  (1 << 1)
 #define PM800_WAKEUP2_INT_MASK (1 << 2)
 
 #define PM800_POWER_UP_LOG (0x10)
-- 
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 0/4] Add Device tree support for 88PM800 mfd and rtc driver

[Vaibhav Hiremath]

This patch-series adds support for Device tree to 88PM800 mfd and rtc driver.
It also creates the DT binding for 88pm800 driver.

Testing::
 - Boot tested on PXA1928 based platform.
 - probe of mfd, rtc and regulator function passing.


Attempt has been made to push some of the patches to the list sometime
back in 2013.

Link to previous patch submission:
https://lkml.org/lkml/2013/8/14/86


Vaibhav Hiremath (4):
  mfd: 88pm800: add device tree support
  mfd: 88pm800: use irq_mode to configure interrupt status reg clear
method
  rtc: 88pm80x: add device tree support
  mfd: 88pm800: allocate pdata->rtc if not allocated earlier

 Documentation/devicetree/bindings/mfd/88pm800.txt | 57 +
 drivers/mfd/88pm800.c | 62 ++-
 drivers/rtc/rtc-88pm80x.c | 28 ++
 include/linux/mfd/88pm80x.h   |  2 +
 4 files changed, 137 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/88pm800.txt

-- 
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: Device Tree Blob (DTB) licence

[David Lang]

On Fri, 29 May 2015, Enrico Weigelt, metux IT consult wrote:


And why should they fear "poisoning" ?


Search for "GPL contamination", the problem is quite common, GPL
can turn anything GPL-compatible into GPL. So for a non-GPL project
it's very hard to adopt GPL code.


Yes, that's the whole purpose of the GPL. The deal is pretty simple:
if you take some GPL'ed software and change it, you'll have to publish
your changes under the same rules. For entirely separate entities
(eg. dedicated programs) that's not an big issue. And for libraries,
we have LGPL.

If the DTS license would be a problem, it would be worse w/ ACPI
and any proprietary firmware/BIOSes.


not true, with a proprietary bios it's a clear "pay this much money and don't 
worry about it" while with GPL there's a nagging fear that someone you never 
heard of may sue you a decade from now claiming you need to give them the source 
to your OS.


Is having the DTB GPL so impartant that you would rather let things fall into 
the windows trap ("well it booted windows, so it must be right") instead of 
allowing a proprietary OS to use your description of the hardware?


note, this whole discussion assumes that the DTB is even copyrightable. Since 
it's intended to be strictly a functional description of what the hardware is 
able to do, that could be questioned


David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] ACPI / PCI: Fix _PRT lookup for ARI enabled devices

[Bjorn Helgaas]

On Tue, May 26, 2015 at 03:11:38PM -0600, Alex Williamson wrote:
> v2: don't modify entry->id.device
> 
> In most cases we only use ARI with SR-IOV VFs, which do not support
> INTx and therefore never hit this problem.  However, some non-SR-IOV
> implementations create multiple PFs, extending beyond the standard
> 3-bit function numbers with ARI, and do support INTx for those
> additional functions.  This can happen with Solarflare SFC9120
> adapters.  The host driver typically doesn't use INTx, so we also
> haven't noticed this problem on bare metal, but when we attempt to
> assign the device to a VM using vfio-pci, we fail trying to setup
> default INTx signaling.  Thanks,
> 
> Alex
> 
> ---
> 
> Alex Williamson (2):
>   PCI: Move pci_ari_enabled() to global header
>   ACPI / PCI: Account for ARI in _PRT lookups

Rafael, do you want this or should I take it?

I put it on my pci/virtualization branch for v4.2.  If you want it, let me
know and I'll drop it and you can add my:

Acked-by: Bjorn Helgaas 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] trace/events: add chip name and hwirq to irq entry tracepoint

[Ankit Gupta]

> Add chip name and hw-irq number to the trace_irq_handler_entry()
> tracepoint. When tracing interrupt events the chip-name and hw-irq
> numbers are stable and known in advance. This makes them a better
> choice as a filtering criteria for the trace buffer dump. On the
> flipside, the os-irq numbers are dynamically allocated which makes
> them difficult to use for the same purpose.
>
> Dump message will look like:
> ...irq_handler_entry: irq=22 name=msm_serial0 domain=GIC hwirq=140
>
> Suggested-by: Stephen Boyd 
> Signed-off-by: Gilad Avidov 
> Signed-off-by: Ankit Gupta 
> ---
>  include/trace/events/irq.h | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/include/trace/events/irq.h b/include/trace/events/irq.h
> index 3608beb..5370075 100644
> --- a/include/trace/events/irq.h
> +++ b/include/trace/events/irq.h
> @@ -23,6 +23,17 @@ struct softirq_action;
>softirq_name(HRTIMER), \
>softirq_name(RCU))
>
> +
> +#define show_chip_name(irq)  \
> + (irq_get_irq_data(irq)  \
> +  ? irq_get_irq_data(irq)->chip->name\
> +  : "NULL")
> +
> +#define show_hwirq(irq)  \
> + (irq_get_irq_data(irq)  \
> +  ? irq_get_irq_data(irq)->hwirq \
> +  : -ENODEV)
> +
>  /**
>   * irq_handler_entry - called immediately before the irq action handler
>   * @irq: irq number
> @@ -50,7 +61,9 @@ TRACE_EVENT(irq_handler_entry,
>   __assign_str(name, action->name);
>   ),
>
> - TP_printk("irq=%d name=%s", __entry->irq, __get_str(name))
> + TP_printk("irq=%d name=%s chip_name=%s hwirq=%ld", __entry->irq,
> +   __get_str(name), show_chip_name(__entry->irq),
> +   show_hwirq(__entry->irq))
>  );
>
>  /**
> --
> 1.8.5.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 v3 5/6] Watchdog: introduce ARM SBSA watchdog driver

[Guenter Roeck]

On 05/29/2015 08:46 AM, Timur Tabi wrote:

On 05/29/2015 09:32 AM, Fu Wei wrote:

It is a SPI, every CPU can get it,
But maybe I miss something, but please let me know if other CPU can
not get the interrupt.


There's only one watchdog device, so there's only one interrupt.  I don't know 
which CPU will get the interrupt, but the watchdog is not a per-CPU device.


Plus, that one interrupt is not shared, and the driver returns
IRQ_HANDLED even if the bit is not set. So _something_ is definitely
wrong. Either the interrupt is shared, then it needs to be requested
as shared and the handler should only return IRQ_HANDLED if it actually
handles the interrupt. Or it is not shared and the handler should always
handle it.

Guenter

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

[PATCH v5 3/17] video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Jingoo Han 
Cc: Daniel Vetter 
Cc: Masanari Iida 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fb...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/video/fbdev/gbefb.c | 30 +-
 1 file changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 4e54faa06..b63d55f 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -22,9 +22,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_X86
-#include 
-#endif
 #ifdef CONFIG_MIPS
 #include 
 #endif
@@ -1176,8 +1173,8 @@ static int gbefb_probe(struct platform_device *p_dev)
 
if (gbe_mem_phys) {
/* memory was allocated at boot time */
-   gbe_mem = devm_ioremap_nocache(_dev->dev, gbe_mem_phys,
-  gbe_mem_size);
+   gbe_mem = devm_ioremap_wc(_dev->dev, gbe_mem_phys,
+ gbe_mem_size);
if (!gbe_mem) {
printk(KERN_ERR "gbefb: couldn't map framebuffer\n");
ret = -ENOMEM;
@@ -1188,8 +1185,8 @@ static int gbefb_probe(struct platform_device *p_dev)
} else {
/* try to allocate memory with the classical allocator
 * this has high chance to fail on low memory machines */
-   gbe_mem = dma_alloc_coherent(NULL, gbe_mem_size, _dma_addr,
-GFP_KERNEL);
+   gbe_mem = dma_alloc_writecombine(NULL, gbe_mem_size,
+_dma_addr, GFP_KERNEL);
if (!gbe_mem) {
printk(KERN_ERR "gbefb: couldn't allocate framebuffer 
memory\n");
ret = -ENOMEM;
@@ -1200,10 +1197,7 @@ static int gbefb_probe(struct platform_device *p_dev)
}
 
par = info->par;
-#ifdef CONFIG_X86
-   par->wc_cookie = mtrr_add(gbe_mem_phys, gbe_mem_size,
-  MTRR_TYPE_WRCOMB, 1);
-#endif
+   par->wc_cookie = arch_phys_wc_add(gbe_mem_phys, gbe_mem_size);
 
/* map framebuffer memory into tiles table */
for (i = 0; i < (gbe_mem_size >> TILE_SHIFT); i++)
@@ -1242,12 +1236,9 @@ static int gbefb_probe(struct platform_device *p_dev)
return 0;
 
 out_gbe_unmap:
-#ifdef CONFIG_MTRR
-   if (par->wc_cookie >= 0)
-   mtrr_del(par->wc_cookie, 0, 0);
-#endif
+   arch_phys_wc_del(par->wc_cookie);
if (gbe_dma_addr)
-   dma_free_coherent(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
+   dma_free_writecombine(NULL, gbe_mem_size, gbe_mem, 
gbe_mem_phys);
 out_tiles_free:
  

[PATCH v5 0/17] framebuffer: simple conversions to arch_phys_wc_add()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" 

Tomi,

this v5 series goes with the patch 3/17 titled "video: fbdev: gbefb:
use arch_phys_wc_add() and devm_ioremap_wc()" with a change from
dma_free_coherent() to dma_free_writecombine() for the area now allocated
with dma_alloc_writecombine(). The remaining patches remain the same.

As for the pull request all I did was reset my tree to yours, and
then reset it to the same old commit 36520841a443d5ee966f9632c417fcc8a25e07e3,
then applied the new series. The only delta from the v4 seires is the
patch 3/17. The new branch changes from simple-arch_phys-20150528 to
simple-arch_phys-20150529. Pull request below for your convenience.

Luis R. Rodriguez (1):
  video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()

 drivers/video/fbdev/gbefb.c | 30 +-
 1 file changed, 9 insertions(+), 21 deletions(-)

The following changes since commit 36520841a443d5ee966f9632c417fcc8a25e07e3:

  video/console: use swap() in newport_bmove() (2015-05-27 12:54:49 +0300)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-framebuffer.git 
simple-arch_phys-20150529

for you to fetch changes up to d8328b5f2175f1ae2f9dc4db6140af67c9196989:

  video: fbdev: geode gxfb: use ioremap_wc() for framebuffer (2015-05-29 
14:57:49 -0700)


Luis R. Rodriguez (17):
  video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: gbefb: add missing mtrr_del() calls
  video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
  video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: i810: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
  video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
  video: fbdev: geode gxfb: use ioremap_wc() for framebuffer

 drivers/video/fbdev/atmel_lcdfb.c|  3 +-
 drivers/video/fbdev/aty/aty128fb.c   | 36 
 drivers/video/fbdev/aty/radeon_base.c| 29 
 drivers/video/fbdev/aty/radeonfb.h   |  2 +-
 drivers/video/fbdev/gbefb.c  | 25 -
 drivers/video/fbdev/geode/gxfb_core.c|  3 +-
 drivers/video/fbdev/i810/i810.h  |  3 +-
 drivers/video/fbdev/i810/i810_main.c | 11 +---
 drivers/video/fbdev/i810/i810_main.h | 26 --
 drivers/video/fbdev/intelfb/intelfb.h|  4 +--
 drivers/video/fbdev/intelfb/intelfbdrv.c | 38 +++---
 drivers/video/fbdev/matrox/matroxfb_base.c   | 36 +---
 drivers/video/fbdev/matrox/matroxfb_base.h   | 27 +-
 drivers/video/fbdev/neofb.c  | 26 +-
 drivers/video/fbdev/nvidia/nv_type.h |  7 +
 drivers/video/fbdev/nvidia/nvidia.c  | 37 -
 drivers/video/fbdev/pm2fb.c  | 31 -
 drivers/video/fbdev/pm3fb.c  | 30 
 drivers/video/fbdev/riva/fbdev.c | 39 +-
 drivers/video/fbdev/riva/rivafb.h|  4 +--
 drivers/video/fbdev/savage/savagefb.h|  4 +--
 drivers/video/fbdev/savage/savagefb_driver.c | 17 ++--
 drivers/video/fbdev/sis/sis.h|  2 +-
 drivers/video/fbdev/sis/sis_main.c   | 27 --
 drivers/video/fbdev/tdfxfb.c | 41 
 include/video/neomagic.h |  5 +---
 include/video/tdfx.h |  2 +-
 27 files changed, 108 insertions(+), 407 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/

Re: [PATCH] frontswap: allow multiple backends

[Andrew Morton]

On Thu, 28 May 2015 16:28:37 -0400 Dan Streetman  wrote:

> Change frontswap single pointer to a singly linked list of frontswap
> implementations.  Update Xen tmem implementation as register no longer
> returns anything.
> 
> Frontswap only keeps track of a single implementation; any implementation
> that registers second (or later) will replace the previously registered
> implementation, and gets a pointer to the previous implementation that
> the new implementation is expected to pass all frontswap functions to
> if it can't handle the function itself.  However that method doesn't
> really make much sense, as passing that work on to every implementation
> adds unnecessary work to implementations; instead, frontswap should
> simply keep a list of all registered implementations and try each
> implementation for any function.  Most importantly, neither of the
> two currently existing frontswap implementations in the kernel actually
> do anything with any previous frontswap implementation that they
> replace when registering.
> 
> This allows frontswap to successfully manage multiple implementations
> by keeping a list of them all.

Looks OK to me.  The "you can never deregister" thing makes life
simpler.

But we need to have a fight over style issues.  Just because you *can*
do something doesn't mean you should.  Don't make you poor readers sit
there going crosseyed at elaborate `for' statements.  Try to keep the
code as simple and straightforward as possible.

> ...
>
>  /*
> - * Register operations for frontswap, returning previous thus allowing
> - * detection of multiple backends and possible nesting.
> + * Register operations for frontswap
>   */
> -struct frontswap_ops *frontswap_register_ops(struct frontswap_ops *ops)
> +void frontswap_register_ops(struct frontswap_ops *ops)
>  {
> - struct frontswap_ops *old = frontswap_ops;
> - int i;
> -
> - for (i = 0; i < MAX_SWAPFILES; i++) {
> - if (test_and_clear_bit(i, need_init)) {
> - struct swap_info_struct *sis = swap_info[i];
> - /* __frontswap_init _should_ have set it! */
> - if (!sis->frontswap_map)
> - return ERR_PTR(-EINVAL);
> - ops->init(i);
> + DECLARE_BITMAP(a, MAX_SWAPFILES);
> + DECLARE_BITMAP(b, MAX_SWAPFILES);
> + struct swap_info_struct *si;
> + unsigned int i;
> +
> + spin_lock(_lock);
> + plist_for_each_entry(si, _active_head, list) {
> + if (!WARN_ON(!si->frontswap_map))
> + set_bit(si->type, a);
> + }
> + spin_unlock(_lock);
> +
> + for (i = find_first_bit(a, MAX_SWAPFILES);
> +  i < MAX_SWAPFILES;
> +  i = find_next_bit(a, MAX_SWAPFILES, i + 1))
> + ops->init(i);

i = find_first_bit(a, MAX_SWAPFILES);
while (i < MAX_SWAPFILES) {
ops->init(i);
i = find_next_bit(a, MAX_SWAPFILES, i + 1);
}

> + do {
> + ops->next = frontswap_ops;
> + } while (cmpxchg(_ops, ops->next, ops) != ops->next);
> +
> + spin_lock(_lock);
> + plist_for_each_entry(si, _active_head, list) {
> + if (si->frontswap_map)
> + set_bit(si->type, b);
> + }
> + spin_unlock(_lock);
> +
> + if (!bitmap_equal(a, b, MAX_SWAPFILES)) {
> + for (i = 0; i < MAX_SWAPFILES; i++) {
> + if (!test_bit(i, a) && test_bit(i, b))
> + ops->init(i);
> + else if (test_bit(i, a) && !test_bit(i, b))
> + ops->invalidate_area(i);
>   }
> ...
>
> @@ -215,24 +216,25 @@ static inline void __frontswap_clear(struct 
> swap_info_struct *sis,
>   */
>  int __frontswap_store(struct page *page)
>  {
> - int ret = -1, dup = 0;
> + int ret, dup;
>   swp_entry_t entry = { .val = page_private(page), };
>   int type = swp_type(entry);
>   struct swap_info_struct *sis = swap_info[type];
>   pgoff_t offset = swp_offset(entry);
> + struct frontswap_ops *ops;
>  
>   /*
>* Return if no backend registed.
>* Don't need to inc frontswap_failed_stores here.
>*/
>   if (!frontswap_ops)
> - return ret;
> + return -1;
>  
>   BUG_ON(!PageLocked(page));
>   BUG_ON(sis == NULL);
> - if (__frontswap_test(sis, offset))
> - dup = 1;
> - ret = frontswap_ops->store(type, offset, page);
> + dup = __frontswap_test(sis, offset);
> + for (ops = frontswap_ops, ret = -1; ops && ret; ops = ops->next)
> + ret = ops->store(type, offset, page);

ret = -1;
for (ops = frontswap_ops; ops; ops = ops->next) {
ret = ops->store(type, offset, page);
if (!ret)
break;
}

One advantage of doing it this way is that it leaves room for comments.
And this code would benefit 

[PATCH] x86_32, entry, selftests: Add a selftest for kernel entries from vm86 mode

[Andy Lutomirski]

Test a couple of special cases in 32-bit kernels for entries from
vm86 mode.  This will OOPS both old kernels due to a bug and and
4.1-rc5 due to a regression I introduced, and it should make sure
that the SYSENTER-from-vm86-mode hack in the kernel keeps working.

Tests: 394838c96013 x86/asm/entry/32: Fix user_mode() misuses
Tests: 7ba554b5ac69 x86/asm/entry/32: Really make user_mode() work correctly 
for VM86 mode
Signed-off-by: Andy Lutomirski 
---

Ingo, Shuah: I think this should go in through -tip.  (In general, I think
new x86 tests that don't have interesting interactions with the kselftest
infrastructure should go in through -tip, especially tests such as this one
that are related to recent regressions.)

tools/testing/selftests/x86/Makefile  |   6 +-
 tools/testing/selftests/x86/entry_from_vm86.c | 114 ++
 2 files changed, 118 insertions(+), 2 deletions(-)
 create mode 100644 tools/testing/selftests/x86/entry_from_vm86.c

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index 5bdb781163d1..9b0d8baf2934 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -5,8 +5,10 @@ include ../lib.mk
 .PHONY: all all_32 all_64 warn_32bit_failure clean
 
 TARGETS_C_BOTHBITS := sigreturn single_step_syscall
+TARGETS_C_32BIT_ONLY := entry_from_vm86
 
-BINARIES_32 := $(TARGETS_C_BOTHBITS:%=%_32)
+TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
+BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
 BINARIES_64 := $(TARGETS_C_BOTHBITS:%=%_64)
 
 CFLAGS := -O2 -g -std=gnu99 -pthread -Wall
@@ -32,7 +34,7 @@ all_64: $(BINARIES_64)
 clean:
$(RM) $(BINARIES_32) $(BINARIES_64)
 
-$(TARGETS_C_BOTHBITS:%=%_32): %_32: %.c
+$(TARGETS_C_32BIT_ALL:%=%_32): %_32: %.c
$(CC) -m32 -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
 
 $(TARGETS_C_BOTHBITS:%=%_64): %_64: %.c
diff --git a/tools/testing/selftests/x86/entry_from_vm86.c 
b/tools/testing/selftests/x86/entry_from_vm86.c
new file mode 100644
index ..5c38a187677b
--- /dev/null
+++ b/tools/testing/selftests/x86/entry_from_vm86.c
@@ -0,0 +1,114 @@
+/*
+ * entry_from_vm86.c - tests kernel entries from vm86 mode
+ * Copyright (c) 2014-2015 Andrew Lutomirski
+ *
+ * This exercises a few paths that need to special-case vm86 mode.
+ *
+ * GPL v2.
+ */
+
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static unsigned long load_addr = 0x1;
+static int nerrs = 0;
+
+asm (
+   ".pushsection .rodata\n\t"
+   ".type vmcode_bound, @object\n\t"
+   "vmcode:\n\t"
+   "vmcode_bound:\n\t"
+   ".code16\n\t"
+   "bound %ax, (2048)\n\t"
+   "int3\n\t"
+   "vmcode_sysenter:\n\t"
+   "sysenter\n\t"
+   ".size vmcode, . - vmcode\n\t"
+   "end_vmcode:\n\t"
+   ".code32\n\t"
+   ".popsection"
+   );
+
+extern unsigned char vmcode[], end_vmcode[];
+extern unsigned char vmcode_bound[], vmcode_sysenter[];
+
+static void do_test(struct vm86plus_struct *v86, unsigned long eip,
+   const char *text)
+{
+   long ret;
+
+   printf("[RUN]\t%s from vm86 mode\n", text);
+   v86->regs.eip = eip;
+   ret = vm86(VM86_ENTER, v86);
+
+   if (ret == -1 && errno == ENOSYS) {
+   printf("[SKIP]\tvm86 not supported\n");
+   return;
+   }
+
+   if (VM86_TYPE(ret) == VM86_INTx) {
+   char trapname[32];
+   int trapno = VM86_ARG(ret);
+   if (trapno == 13)
+   strcpy(trapname, "GP");
+   else if (trapno == 5)
+   strcpy(trapname, "BR");
+   else if (trapno == 14)
+   strcpy(trapname, "PF");
+   else
+   sprintf(trapname, "%d", trapno);
+
+   printf("[OK]\tExited vm86 mode due to #%s\n", trapname);
+   } else if (VM86_TYPE(ret) == VM86_UNKNOWN) {
+   printf("[OK]\tExited vm86 mode due to unhandled GP fault\n");
+   } else {
+   printf("[OK]\tExited vm86 mode due to type %ld, arg %ld\n",
+  VM86_TYPE(ret), VM86_ARG(ret));
+   }
+}
+
+int main(void)
+{
+   struct vm86plus_struct v86;
+   unsigned char *addr = mmap((void *)load_addr, 4096,
+  PROT_READ | PROT_WRITE | PROT_EXEC,
+  MAP_ANONYMOUS | MAP_PRIVATE, -1,0);
+   if (addr != (unsigned char *)load_addr)
+   err(1, "mmap");
+
+   memcpy(addr, vmcode, end_vmcode - vmcode);
+   addr[2048] = 2;
+   addr[2050] = 3;
+
+   memset(, 0, sizeof(v86));
+
+   v86.regs.cs = load_addr / 16;
+   v86.regs.ss = load_addr / 16;
+   v86.regs.ds = load_addr / 16;
+   v86.regs.es = load_addr / 16;
+
+   assert((v86.regs.cs & 3) == 0); /* 

Re: 4.1 touchscreen regression on n900 -- pinpointed [was Re: linux-n900 v4.1-rc4]

[Pavel Machek]

On Fri 2015-05-29 14:36:49, Dmitry Torokhov wrote:
> On Fri, May 29, 2015 at 11:17:22PM +0200, Pavel Machek wrote:
> > On Fri 2015-05-29 21:57:40, Maxime Ripard wrote:
> > > On Fri, May 29, 2015 at 09:25:05PM +0200, Pavel Machek wrote:
> > > > On Fri 2015-05-29 21:08:16, Pavel Machek wrote:
> > > > > Hi!
> > > > > 
> > > > > > mh I remember having problems with tsc2005 before. It helped to
> > > > > > reset the controller (should actually happen automatically when it
> > > > > > hangs, but I'm not sure, that it actually works).
> > > > > 
> > > > > Ok, I did some more testing, and found out rather bogus values in
> > > > > evtest:
> > > > > 
> > > > > Input device name: "TSC2005 touchscreen"
> > > > > Supported events:
> > > > >   Event type 0 (EV_SYN)
> > > > >   Event type 1 (EV_KEY)
> > > > >   Event code 330 (BTN_TOUCH)
> > > > >   Event type 3 (EV_ABS)
> > > > >   Event code 0 (ABS_X)
> > > > >   Value   2514
> > > > >  Min0
> > > > >  Max0
> > > > >  Fuzz   4
> > > > > 
> > > > > Which made me go through the git logs, and these patches looked
> > > > > suspicious. After a revert... yes, touchscreen works as well as it
> > > > > worked before.
> > > > > 
> > > > > 0a363a380954e10fece7cd9931b66056eeb07d56
> > > > > 3eea8b5d68c801fec788b411582b803463834752
> > > > > 
> > > > > (It is impossible to revert just 3eea..)
> > > > 
> > > > Hmm, I see:
> > > > 
> > > > touchscreen-max-x = <4096>;
> > > > touchscreen-max-y = <4096>;
> > > > ...that's n900 dts.. this should be size-x/size-y... so we have a bug
> > > > in dts.
> > > > 
> > > > But the 3eea8b5d68c801fec788b411582b803463834752 is buggy, it should
> > > > not overwrite ->maximum for axis it has no devicetree data for.
> > > 
> > > What do you mean? touchscreen-max-* _is_ device tree data for an axis.
> > > 
> > > > Maybe replacing
> > > > 
> > > > +   if (maximum || fuzz)
> > > > 
> > > > in 3eea to (maximum && fuzz)... would help, but it is late in the
> > > > cycle now, so I'd suggest just reverting 3eea8b.
> > > 
> > > No, both maximum and fuzz are optional. You can perfectly have one
> > > without another.
> > 
> > Yes, which is something you got wrong.
> > 
> > Apply this on top of 3eea8b5d68c801fec788b411582b803463834752, and
> > you'll get simpler code, that works like it did before.
> > 
> > Maxime, since you caused the regression, can I ask you to put the
> > other patches on top of it, test it still works for you and submit it
> > properly?
> > 
> > [If you want to return in !test_bit case, and are sure it does not
> > break anything, feel free to do that.]
> > 
> > Thanks,
> > Pavel
> > 
> > Signed-off-by: Pavel Machek 
> > 
> > diff --git a/drivers/input/touchscreen/of_touchscreen.c 
> > b/drivers/input/touchscreen/of_touchscreen.c
> > index b82b520..e626c8a 100644
> > --- a/drivers/input/touchscreen/of_touchscreen.c
> > +++ b/drivers/input/touchscreen/of_touchscreen.c
> > @@ -11,39 +11,23 @@
> >  
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  
> > -static u32 of_get_optional_u32(struct device_node *np,
> > -  const char *property)
> > -{
> > -   u32 val = 0;
> > -
> > -   of_property_read_u32(np, property, );
> > -
> > -   return val;
> > -}
> > -
> >  static void touchscreen_set_params(struct input_dev *dev,
> >unsigned long axis,
> > -  int max, int fuzz)
> > +  char *max, char *fuzz)
> >  {
> > struct input_absinfo *absinfo;
> > +   struct device_node *np = dev->dev.parent->of_node;
> >  
> > if (!test_bit(axis, dev->absbit)) {
> > -   /*
> > -* Emit a warning only if the axis is not a multitouch
> > -* axis, which might not be set by the driver.
> > -*/
> > -   if (!input_is_mt_axis(axis))
> > -   dev_warn(>dev,
> > -"DT specifies parameters but the axis is not 
> > set up\n");
> > -   return;
> > +   dev_warn(>dev,
> > +"DT specifies parameters but the axis is not set 
> > up\n");
> 
> No, this is not right either. We do not want to bitch about axis not
> being set up if there is nothing in DT mentioning this axis.

Well, we should not bitch at all, that should have been followup patch.

> Plus the code structure won't work well if we decide to add more to it
> (such as min, or flat, or resolution).

Do you want to try to cook up something that works?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at