Re: [PATCH 1/4] w83627ehf: Use hwmon_device_register_with_info and sensor groups

2017-03-22 Thread Guenter Roeck

On 03/22/2017 05:40 PM, Peter Huewe wrote:

This patch replaces the old, deprecated call to hwmon_device_register
with the new hwmon_device_register_with_info and converts the whole
driver to the new hwmon interface using the hwmon_chip_info methods
and the attribute_group method.

Unfortunately this makes the patch quite large, but it is the most
sensible way to do so, without doing everything twice.



Not part of commit log.


All standard attributes were converted to the corresponding
hwmon_chip_info methods.
For some functions a hwmon channel to device channel conversion had to
be performed, e.g. hwmon_in_alarm has the info for alert_5 in channel 8.

All non-standard attributes are converted to the attribute_group method,
by
- adding them statically to the attribute_group if they are available
for all variants of devices supported by this driver
- adding them at probe time to the attribute_group if the availability
is depending on the actual chip type.
The appropriate count of entries was reserved.

As a pre-condition a reference to the sio_data structure was moved into
w83627ehf_data for easier retrieval of the information, since this is
much easier than trying to access the platform_data.

The driver is now much more "checkpatch clean" than it used to be, but
still not completely.
The conversion saves about 20k in the resulting .ko

Tested with a NCT6776F chip.

Signed-off-by: Peter Huewe 
---
Target-Branch: groeck/hwmon


Can you rebase to hwmon-next ? There is a non-trivial conflict.



Please cherry-pick
 46dc4a97 hwmon: Constify str parameter of hwmon_ops->read_string
before this patch series


This is in hwmon-next.

Overall looks pretty good, except for the handling of
static struct attribute *sensor_attrs[]. Otherwise mostly nitpicks.

Thanks,
Guenter



 drivers/hwmon/w83627ehf.c | 1387 +
 1 file changed, 648 insertions(+), 739 deletions(-)

diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index ab346ed142de..785ddd47c588 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -1,6 +1,7 @@
 /*
  *  w83627ehf - Driver for the hardware monitoring functionality of
  * the Winbond W83627EHF Super-I/O chip
+ *  Copyright (C) 2017  Peter Huewe 
  *  Copyright (C) 2005-2012  Jean Delvare 
  *  Copyright (C) 2006  Yuan Mu (Winbond),
  * Rudolf Marek 
@@ -420,6 +421,11 @@ static inline u8 in_to_reg(u32 val, u8 nr, const u16 
*scale_in)
 /*
  * Data structures and manipulation thereof
  */
+struct w83627ehf_sio_data {
+   int sioreg;
+   enum kinds kind;
+};
+

 struct w83627ehf_data {
int addr;   /* IO base of hw monitor block */
@@ -508,11 +514,7 @@ struct w83627ehf_data {
u8 fandiv1;
u8 fandiv2;
 #endif
-};
-
-struct w83627ehf_sio_data {
-   int sioreg;
-   enum kinds kind;
+   struct w83627ehf_sio_data *sio_data;
 };

 /*
@@ -673,7 +675,7 @@ static void w83627ehf_write_fan_div(struct w83627ehf_data 
*data, int nr)
 static void w83627ehf_write_fan_div_common(struct device *dev,
   struct w83627ehf_data *data, int nr)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
+   struct w83627ehf_sio_data *sio_data = data->sio_data;

if (sio_data->kind == nct6776)
; /* no dividers, do nothing */
@@ -724,14 +726,14 @@ static void w83627ehf_update_fan_div(struct 
w83627ehf_data *data)
 static void w83627ehf_update_fan_div_common(struct device *dev,
struct w83627ehf_data *data)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
-
-   if (sio_data->kind == nct6776)
-   ; /* no dividers, do nothing */
-   else if (sio_data->kind == nct6775)
-   nct6775_update_fan_div(data);
-   else
-   w83627ehf_update_fan_div(data);
+   if (data->sio_data) {


I am frowning on conditionals like this. It should not happen.
If it does, it would be a severe bug. Why do you think it is necessary ?


+   if (data->sio_data->kind == nct6776)
+   ; /* no dividers, do nothing */
+   else if (data->sio_data->kind == nct6775)
+   nct6775_update_fan_div(data);
+   else
+   w83627ehf_update_fan_div(data);
+   }
 }

 static void nct6775_update_pwm(struct w83627ehf_data *data)
@@ -781,7 +783,7 @@ static void w83627ehf_update_pwm(struct w83627ehf_data 
*data)
 static void w83627ehf_update_pwm_common(struct device *dev,
struct w83627ehf_data *data)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
+   struct w83627ehf_sio_data *sio_data = data->sio_data;

if (sio_data->kind == nct6775 || sio_data->kind == nct6776)

Re: [PATCH 1/4] w83627ehf: Use hwmon_device_register_with_info and sensor groups

2017-03-22 Thread Guenter Roeck

On 03/22/2017 05:40 PM, Peter Huewe wrote:

This patch replaces the old, deprecated call to hwmon_device_register
with the new hwmon_device_register_with_info and converts the whole
driver to the new hwmon interface using the hwmon_chip_info methods
and the attribute_group method.

Unfortunately this makes the patch quite large, but it is the most
sensible way to do so, without doing everything twice.



Not part of commit log.


All standard attributes were converted to the corresponding
hwmon_chip_info methods.
For some functions a hwmon channel to device channel conversion had to
be performed, e.g. hwmon_in_alarm has the info for alert_5 in channel 8.

All non-standard attributes are converted to the attribute_group method,
by
- adding them statically to the attribute_group if they are available
for all variants of devices supported by this driver
- adding them at probe time to the attribute_group if the availability
is depending on the actual chip type.
The appropriate count of entries was reserved.

As a pre-condition a reference to the sio_data structure was moved into
w83627ehf_data for easier retrieval of the information, since this is
much easier than trying to access the platform_data.

The driver is now much more "checkpatch clean" than it used to be, but
still not completely.
The conversion saves about 20k in the resulting .ko

Tested with a NCT6776F chip.

Signed-off-by: Peter Huewe 
---
Target-Branch: groeck/hwmon


Can you rebase to hwmon-next ? There is a non-trivial conflict.



Please cherry-pick
 46dc4a97 hwmon: Constify str parameter of hwmon_ops->read_string
before this patch series


This is in hwmon-next.

Overall looks pretty good, except for the handling of
static struct attribute *sensor_attrs[]. Otherwise mostly nitpicks.

Thanks,
Guenter



 drivers/hwmon/w83627ehf.c | 1387 +
 1 file changed, 648 insertions(+), 739 deletions(-)

diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index ab346ed142de..785ddd47c588 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -1,6 +1,7 @@
 /*
  *  w83627ehf - Driver for the hardware monitoring functionality of
  * the Winbond W83627EHF Super-I/O chip
+ *  Copyright (C) 2017  Peter Huewe 
  *  Copyright (C) 2005-2012  Jean Delvare 
  *  Copyright (C) 2006  Yuan Mu (Winbond),
  * Rudolf Marek 
@@ -420,6 +421,11 @@ static inline u8 in_to_reg(u32 val, u8 nr, const u16 
*scale_in)
 /*
  * Data structures and manipulation thereof
  */
+struct w83627ehf_sio_data {
+   int sioreg;
+   enum kinds kind;
+};
+

 struct w83627ehf_data {
int addr;   /* IO base of hw monitor block */
@@ -508,11 +514,7 @@ struct w83627ehf_data {
u8 fandiv1;
u8 fandiv2;
 #endif
-};
-
-struct w83627ehf_sio_data {
-   int sioreg;
-   enum kinds kind;
+   struct w83627ehf_sio_data *sio_data;
 };

 /*
@@ -673,7 +675,7 @@ static void w83627ehf_write_fan_div(struct w83627ehf_data 
*data, int nr)
 static void w83627ehf_write_fan_div_common(struct device *dev,
   struct w83627ehf_data *data, int nr)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
+   struct w83627ehf_sio_data *sio_data = data->sio_data;

if (sio_data->kind == nct6776)
; /* no dividers, do nothing */
@@ -724,14 +726,14 @@ static void w83627ehf_update_fan_div(struct 
w83627ehf_data *data)
 static void w83627ehf_update_fan_div_common(struct device *dev,
struct w83627ehf_data *data)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
-
-   if (sio_data->kind == nct6776)
-   ; /* no dividers, do nothing */
-   else if (sio_data->kind == nct6775)
-   nct6775_update_fan_div(data);
-   else
-   w83627ehf_update_fan_div(data);
+   if (data->sio_data) {


I am frowning on conditionals like this. It should not happen.
If it does, it would be a severe bug. Why do you think it is necessary ?


+   if (data->sio_data->kind == nct6776)
+   ; /* no dividers, do nothing */
+   else if (data->sio_data->kind == nct6775)
+   nct6775_update_fan_div(data);
+   else
+   w83627ehf_update_fan_div(data);
+   }
 }

 static void nct6775_update_pwm(struct w83627ehf_data *data)
@@ -781,7 +783,7 @@ static void w83627ehf_update_pwm(struct w83627ehf_data 
*data)
 static void w83627ehf_update_pwm_common(struct device *dev,
struct w83627ehf_data *data)
 {
-   struct w83627ehf_sio_data *sio_data = dev_get_platdata(dev);
+   struct w83627ehf_sio_data *sio_data = data->sio_data;

if (sio_data->kind == nct6775 || sio_data->kind == nct6776)
nct6775_update_pwm(data);
@@ -792,8 +794,7 @@ static void 

linux-next: Tree for Mar 23

2017-03-22 Thread Stephen Rothwell
Hi all,

Changes since 20170322:

The net-next tree gained a conflict against the net tree.

The usb tree gained a conflict against the usb-gadget-fixes tree.

The char-misc tree lost its build failure.

The livepatching tree gained conflicts against the s390 tree.

Non-merge commits (relative to Linus' tree): 4376
 5048 files changed, 372425 insertions(+), 84691 deletions(-)



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

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (093b995e3b55 mm, swap: Remove WARN_ON_ONCE() in 
free_swap_slot())
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (b334e19ae938 Kbuild: use cc-disable-warning 
consistently for maybe-uninitialized)
Merging arc-current/for-curr (814a585038e3 ARCv2: make unimplemented vectors as 
no-ops rather than halt core)
Merging arm-current/fixes (a1016e94cce9 ARM: wire up statx syscall)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (cc638a488a52 gcc-plugins: update architecture list 
in documentation)
Merging sparc/master (f8e6859ea9d0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c64c0b3cac4c ipv4: provide stronger user input validation 
in nl_fib_input())
Merging ipsec/master (72ef9c4125c7 dccp: fix memory leak during tear-down of 
unsuccessful connection request)
Merging netfilter/master (f83bf8da1135 netfilter: nfnl_cthelper: Fix memory 
leak)
Merging ipvs/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if 
Wake-on-LAN is enabled)
Merging wireless-drivers/master (6be3b6cce1e2 ath10k: fix incorrect 
wlan_mac_base in qca6174_regs)
Merging mac80211/master (ea90e0dc8cec nl80211: fix dumpit error path RTNL 
deadlocks)
Merging sound-current/for-linus (c520ff3d03f0 ALSA: seq: Fix racy cell 
insertions during snd_seq_pool_done())
Merging pci-current/for-linus (6e347b5e05ea PCI: iproc: Save host bridge window 
resource in struct iproc_pcie)
Merging driver-core.current/driver-core-linus (966fa72a716c kernfs: Check 
KERNFS_HAS_RELEASE before calling kernfs_release_file())
Merging tty.current/tty-linus (a4a3e061149f tty: fix data race in 
tty_ldisc_ref_wait())
Merging usb.current/usb-linus (7b2db29fbb4e usb: hub: Fix crash after failure 
to read BOS descriptor)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (436ecf5519d8 USB: serial: qcserial: add 
Dell DW5811e)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (43c49938bf72 Merge tag 
'iio-fixes-for-4.11c' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (5c1724c42dc1 Merge tag 
'extcon-fixes-for-4.11-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (47e6fb4212d0 Input: ALPS - fix trackstick 
button

linux-next: Tree for Mar 23

2017-03-22 Thread Stephen Rothwell
Hi all,

Changes since 20170322:

The net-next tree gained a conflict against the net tree.

The usb tree gained a conflict against the usb-gadget-fixes tree.

The char-misc tree lost its build failure.

The livepatching tree gained conflicts against the s390 tree.

Non-merge commits (relative to Linus' tree): 4376
 5048 files changed, 372425 insertions(+), 84691 deletions(-)



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

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (093b995e3b55 mm, swap: Remove WARN_ON_ONCE() in 
free_swap_slot())
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (b334e19ae938 Kbuild: use cc-disable-warning 
consistently for maybe-uninitialized)
Merging arc-current/for-curr (814a585038e3 ARCv2: make unimplemented vectors as 
no-ops rather than halt core)
Merging arm-current/fixes (a1016e94cce9 ARM: wire up statx syscall)
Merging m68k-current/for-linus (e3b1ebd67387 m68k: Wire up statx)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (cc638a488a52 gcc-plugins: update architecture list 
in documentation)
Merging sparc/master (f8e6859ea9d0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (c64c0b3cac4c ipv4: provide stronger user input validation 
in nl_fib_input())
Merging ipsec/master (72ef9c4125c7 dccp: fix memory leak during tear-down of 
unsuccessful connection request)
Merging netfilter/master (f83bf8da1135 netfilter: nfnl_cthelper: Fix memory 
leak)
Merging ipvs/master (5371bbf4b295 net: bcmgenet: Do not suspend PHY if 
Wake-on-LAN is enabled)
Merging wireless-drivers/master (6be3b6cce1e2 ath10k: fix incorrect 
wlan_mac_base in qca6174_regs)
Merging mac80211/master (ea90e0dc8cec nl80211: fix dumpit error path RTNL 
deadlocks)
Merging sound-current/for-linus (c520ff3d03f0 ALSA: seq: Fix racy cell 
insertions during snd_seq_pool_done())
Merging pci-current/for-linus (6e347b5e05ea PCI: iproc: Save host bridge window 
resource in struct iproc_pcie)
Merging driver-core.current/driver-core-linus (966fa72a716c kernfs: Check 
KERNFS_HAS_RELEASE before calling kernfs_release_file())
Merging tty.current/tty-linus (a4a3e061149f tty: fix data race in 
tty_ldisc_ref_wait())
Merging usb.current/usb-linus (7b2db29fbb4e usb: hub: Fix crash after failure 
to read BOS descriptor)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (436ecf5519d8 USB: serial: qcserial: add 
Dell DW5811e)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (43c49938bf72 Merge tag 
'iio-fixes-for-4.11c' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (5c1724c42dc1 Merge tag 
'extcon-fixes-for-4.11-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into 
char-misc-linus)
Merging input-current/for-linus (47e6fb4212d0 Input: ALPS - fix trackstick 
button

Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

2017-03-22 Thread Kai-Heng Feng
[snip]

> Let me explain it in more detail. rt5670 need to set a serious of
> registers to prevent the pop noise of powering up/down muting/
> unmuting headphone. That's what rt5670_hp_event() does. But,
> what rt286_hp_power_event do is only mute/unmute headphone
> which is done by "HPO L" and "HPO R" widget.

Thanks for the explanation.

[snip]

> If HPO is already muted as what we expected, it means "HPO L" and "HPO R"
> work properly. And there is no reason we create an event to do the same
> thing.

Can you advise me how to do a simple check on HPO L mute status?

>
>> >>
>> >> I found that the effect is most noticeable if the mute callback is
>> >> associated with "LDO2" and "HP Power".
>> >> But again, this is just what I observed.
>> >
>> > Could you try only associated with "LDO2"?
>> > It makes sense that will reduce the noise if a jack is plugged in/out
>> > when HPO is already powered up.
>>
>> Does it also help to reduce noise at other power events?
>
> I don't know. In theory, you shouldn't hear any sound when HPO
> is muted. If you need our help for debugging, please send a mail
> to our FAE and cc me.

Unfortunately it did happen. AMP mute did well for me and another user
- please check the bug report link.

>
>>
>> >
>> > I have question about the code below
>> > +   /* Fix headphone click noise */
>> > +   if (dmi_check_system(dmi_dell_dino))
>> > +   regmap_write(rt286->regmap,
>> > +   RT286_MIC1_DET_CTRL,
>> 0x0020);
>> > +
>> >
>> > What does this for? How did you get the value 0x0020?
>> > I just checked with Kailang, but he have no idea about that.
>>
>> It's PIN_VREFHIZ. It's from commit 3e1b0c4a9d56.
>
> snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
> 0x19 here means nid 0x19. But if you write 0x19 in rt286.c means
> write a hidden register with index 0x19. It is totally different.
> The corresponding code on rt286.c will be
> rt286->regmap(rt286->regmap,
> VERB_CMD(AC_VERB_SET_PIN_WIDGET_CONTROL, 0x19, 0x20));

Understood, will use it instead.

>>
>> >
>> >>
>> >> >
>> >> >
>> >>
>> >> --Please consider the environment before printing this e-mail.


Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

2017-03-22 Thread Kai-Heng Feng
[snip]

> Let me explain it in more detail. rt5670 need to set a serious of
> registers to prevent the pop noise of powering up/down muting/
> unmuting headphone. That's what rt5670_hp_event() does. But,
> what rt286_hp_power_event do is only mute/unmute headphone
> which is done by "HPO L" and "HPO R" widget.

Thanks for the explanation.

[snip]

> If HPO is already muted as what we expected, it means "HPO L" and "HPO R"
> work properly. And there is no reason we create an event to do the same
> thing.

Can you advise me how to do a simple check on HPO L mute status?

>
>> >>
>> >> I found that the effect is most noticeable if the mute callback is
>> >> associated with "LDO2" and "HP Power".
>> >> But again, this is just what I observed.
>> >
>> > Could you try only associated with "LDO2"?
>> > It makes sense that will reduce the noise if a jack is plugged in/out
>> > when HPO is already powered up.
>>
>> Does it also help to reduce noise at other power events?
>
> I don't know. In theory, you shouldn't hear any sound when HPO
> is muted. If you need our help for debugging, please send a mail
> to our FAE and cc me.

Unfortunately it did happen. AMP mute did well for me and another user
- please check the bug report link.

>
>>
>> >
>> > I have question about the code below
>> > +   /* Fix headphone click noise */
>> > +   if (dmi_check_system(dmi_dell_dino))
>> > +   regmap_write(rt286->regmap,
>> > +   RT286_MIC1_DET_CTRL,
>> 0x0020);
>> > +
>> >
>> > What does this for? How did you get the value 0x0020?
>> > I just checked with Kailang, but he have no idea about that.
>>
>> It's PIN_VREFHIZ. It's from commit 3e1b0c4a9d56.
>
> snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
> 0x19 here means nid 0x19. But if you write 0x19 in rt286.c means
> write a hidden register with index 0x19. It is totally different.
> The corresponding code on rt286.c will be
> rt286->regmap(rt286->regmap,
> VERB_CMD(AC_VERB_SET_PIN_WIDGET_CONTROL, 0x19, 0x20));

Understood, will use it instead.

>>
>> >
>> >>
>> >> >
>> >> >
>> >>
>> >> --Please consider the environment before printing this e-mail.


Re: [RFC 3/8] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

2017-03-22 Thread Viresh Kumar
On 22-03-17, 18:53, Leonard Crestez wrote:
> If the cpufreq driver tries to modify voltage/freq during suspend/resume
> it might need to control an external PMIC via I2C or SPI but those
> devices might be already suspended.
> 
> To avoid this scenario we just increase cpufreq to highest setpoint
> before suspend. This issue can easily be triggered by ldo-bypass but in
> theory any regulator set_voltage call can end up having to modify
> external supply voltages.
> 
> Signed-off-by: Leonard Crestez 
> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [RFC 2/8] cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator

2017-03-22 Thread Viresh Kumar
On 22-03-17, 18:53, Leonard Crestez wrote:
> From: Irina Tirdea 
> 
> If there are any errors in getting the cpu0 regulators, the driver returns
> -ENOENT. In case the regulators are not yet available, the devm_regulator_get
> calls will return -EPROBE_DEFER, so that the driver can be probed later.
> If we return -ENOENT, the driver will fail its initialization and will
> not try to probe again (when the regulators become available).
> 
> Return the actual error received from regulator_get in probe. Print a
> differentiated message in case we need to probe the device later and
> in case we actually failed. Also add a message to inform when the
> driver has been successfully registered.
> 
> Signed-off-by: Irina Tirdea 
> Signed-off-by: Leonard Crestez 
> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 7 +++
>  1 file changed, 7 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [RFC 3/8] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

2017-03-22 Thread Viresh Kumar
On 22-03-17, 18:53, Leonard Crestez wrote:
> If the cpufreq driver tries to modify voltage/freq during suspend/resume
> it might need to control an external PMIC via I2C or SPI but those
> devices might be already suspended.
> 
> To avoid this scenario we just increase cpufreq to highest setpoint
> before suspend. This issue can easily be triggered by ldo-bypass but in
> theory any regulator set_voltage call can end up having to modify
> external supply voltages.
> 
> Signed-off-by: Leonard Crestez 
> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [RFC 2/8] cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator

2017-03-22 Thread Viresh Kumar
On 22-03-17, 18:53, Leonard Crestez wrote:
> From: Irina Tirdea 
> 
> If there are any errors in getting the cpu0 regulators, the driver returns
> -ENOENT. In case the regulators are not yet available, the devm_regulator_get
> calls will return -EPROBE_DEFER, so that the driver can be probed later.
> If we return -ENOENT, the driver will fail its initialization and will
> not try to probe again (when the regulators become available).
> 
> Return the actual error received from regulator_get in probe. Print a
> differentiated message in case we need to probe the device later and
> in case we actually failed. Also add a message to inform when the
> driver has been successfully registered.
> 
> Signed-off-by: Irina Tirdea 
> Signed-off-by: Leonard Crestez 
> ---
>  drivers/cpufreq/imx6q-cpufreq.c | 7 +++
>  1 file changed, 7 insertions(+)

Acked-by: Viresh Kumar 

-- 
viresh


[PATCH] drivers/misc: Aspeed LPC control fix format string warning

2017-03-22 Thread Cyril Bur
resource_size_t is a derivative of phys_addr_t and should also be
printed with %pap:
drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects
argument of type 'unsigned int', but argument 4 has type
'resource_size_t {aka long long unsigned int}' [-Wformat=] dev_info(dev,
"Loaded at %pap (0x%08x)\n",

Reported-by: Stephen Rothwell 
Signed-off-by: Cyril Bur 
---
 drivers/misc/aspeed-lpc-ctrl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index c654651a7b6d..2f6bb2244be5 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -229,8 +229,8 @@ static int aspeed_lpc_ctrl_probe(struct platform_device 
*pdev)
if (rc)
dev_err(dev, "Unable to register device\n");
else
-   dev_info(dev, "Loaded at %pap (0x%08x)\n",
-   _ctrl->mem_base, lpc_ctrl->mem_size);
+   dev_info(dev, "Loaded at %pap (%pap)\n",
+   _ctrl->mem_base, _ctrl->mem_size);
 
return rc;
 }
-- 
2.12.1



[PATCH] drivers/misc: Aspeed LPC control fix format string warning

2017-03-22 Thread Cyril Bur
resource_size_t is a derivative of phys_addr_t and should also be
printed with %pap:
drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects
argument of type 'unsigned int', but argument 4 has type
'resource_size_t {aka long long unsigned int}' [-Wformat=] dev_info(dev,
"Loaded at %pap (0x%08x)\n",

Reported-by: Stephen Rothwell 
Signed-off-by: Cyril Bur 
---
 drivers/misc/aspeed-lpc-ctrl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/aspeed-lpc-ctrl.c b/drivers/misc/aspeed-lpc-ctrl.c
index c654651a7b6d..2f6bb2244be5 100644
--- a/drivers/misc/aspeed-lpc-ctrl.c
+++ b/drivers/misc/aspeed-lpc-ctrl.c
@@ -229,8 +229,8 @@ static int aspeed_lpc_ctrl_probe(struct platform_device 
*pdev)
if (rc)
dev_err(dev, "Unable to register device\n");
else
-   dev_info(dev, "Loaded at %pap (0x%08x)\n",
-   _ctrl->mem_base, lpc_ctrl->mem_size);
+   dev_info(dev, "Loaded at %pap (%pap)\n",
+   _ctrl->mem_base, _ctrl->mem_size);
 
return rc;
 }
-- 
2.12.1



Re: [PATCH v2] cpufreq: schedutil: Trace frequency only if it has changed

2017-03-22 Thread Viresh Kumar
On 22-03-17, 18:32, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> sugov_update_commit() calls trace_cpu_frequency() to record the
> current CPU frequency if it has not changed in the fast switch case
> to prevent utilities from getting confused (they may report that the
> CPU is idle if the frequency has not been recorded for too long, for
> example).
> 
> However, that may cause the tracepoint to be triggered quite often
> for no real reason (if the frequency doesn't change, we will not
> modify the last update time stamp and governor computations may
> run again shortly when that happens), so don't do that (arguably, it
> is done to work around a utilities bug anyway).
> 
> That allows code duplication in sugov_update_commit() to be reduced
> somewhat too.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> -> v2:
> Drop the trace_cpu_frequency() call in the sg_policy->next_freq == next_freq 
> case.
> 
> ---
>  kernel/sched/cpufreq_schedutil.c |   16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [PATCH v2] cpufreq: schedutil: Trace frequency only if it has changed

2017-03-22 Thread Viresh Kumar
On 22-03-17, 18:32, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> sugov_update_commit() calls trace_cpu_frequency() to record the
> current CPU frequency if it has not changed in the fast switch case
> to prevent utilities from getting confused (they may report that the
> CPU is idle if the frequency has not been recorded for too long, for
> example).
> 
> However, that may cause the tracepoint to be triggered quite often
> for no real reason (if the frequency doesn't change, we will not
> modify the last update time stamp and governor computations may
> run again shortly when that happens), so don't do that (arguably, it
> is done to work around a utilities bug anyway).
> 
> That allows code duplication in sugov_update_commit() to be reduced
> somewhat too.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> -> v2:
> Drop the trace_cpu_frequency() call in the sg_policy->next_freq == next_freq 
> case.
> 
> ---
>  kernel/sched/cpufreq_schedutil.c |   16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh


Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

2017-03-22 Thread Sergey Senozhatsky
Hello Peter,

thanks for taking a look.

On (03/22/17 18:59), Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 09:45:50PM +0900, Sergey Senozhatsky wrote:
> >  sysrq is potentially even trickier. can we always wake_up() kernel
> >  thread from sysrq? there probably might be cases when we can't rely
> >  on the scheduler.
> 
> sysrq runs from interrupt context, right? Should be able to do wakeups.

what I though about was -
what if there are 'misbehaving' higher prio tasks all the time?
the existing sysrq would attempt to do printing from irq context
so it doesn't care about run queues.

does it make sense to you?

so what I have currently is something like this:
(not so sure about sysrq_handle_showstate_blocked())

---
 drivers/tty/sysrq.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index c6fc7141d7b2..f0d2684fa99c 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -239,6 +240,7 @@ static DECLARE_WORK(sysrq_showallcpus, 
sysrq_showregs_othercpus);
 
 static void sysrq_handle_showallcpus(int key)
 {
+   console_printing_thread_off();
/*
 * Fall back to the workqueue based printing if the
 * backtrace printing did not succeed or the
@@ -253,6 +255,7 @@ static void sysrq_handle_showallcpus(int key)
}
schedule_work(_showallcpus);
}
+   console_printing_thread_on();
 }
 
 static struct sysrq_key_op sysrq_showallcpus_op = {
@@ -279,8 +282,10 @@ static struct sysrq_key_op sysrq_showregs_op = {
 
 static void sysrq_handle_showstate(int key)
 {
+   console_printing_thread_off();
show_state();
show_workqueue_state();
+   console_printing_thread_on();
 }
 static struct sysrq_key_op sysrq_showstate_op = {
.handler= sysrq_handle_showstate,
@@ -291,7 +296,9 @@ static struct sysrq_key_op sysrq_showstate_op = {
 
 static void sysrq_handle_showstate_blocked(int key)
 {
+   console_printing_thread_off();
show_state_filter(TASK_UNINTERRUPTIBLE);
+   console_printing_thread_on();
 }
 static struct sysrq_key_op sysrq_showstate_blocked_op = {
.handler= sysrq_handle_showstate_blocked,
-- 
2.12.1



Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

2017-03-22 Thread Sergey Senozhatsky
Hello Peter,

thanks for taking a look.

On (03/22/17 18:59), Peter Zijlstra wrote:
> On Mon, Mar 06, 2017 at 09:45:50PM +0900, Sergey Senozhatsky wrote:
> >  sysrq is potentially even trickier. can we always wake_up() kernel
> >  thread from sysrq? there probably might be cases when we can't rely
> >  on the scheduler.
> 
> sysrq runs from interrupt context, right? Should be able to do wakeups.

what I though about was -
what if there are 'misbehaving' higher prio tasks all the time?
the existing sysrq would attempt to do printing from irq context
so it doesn't care about run queues.

does it make sense to you?

so what I have currently is something like this:
(not so sure about sysrq_handle_showstate_blocked())

---
 drivers/tty/sysrq.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index c6fc7141d7b2..f0d2684fa99c 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -239,6 +240,7 @@ static DECLARE_WORK(sysrq_showallcpus, 
sysrq_showregs_othercpus);
 
 static void sysrq_handle_showallcpus(int key)
 {
+   console_printing_thread_off();
/*
 * Fall back to the workqueue based printing if the
 * backtrace printing did not succeed or the
@@ -253,6 +255,7 @@ static void sysrq_handle_showallcpus(int key)
}
schedule_work(_showallcpus);
}
+   console_printing_thread_on();
 }
 
 static struct sysrq_key_op sysrq_showallcpus_op = {
@@ -279,8 +282,10 @@ static struct sysrq_key_op sysrq_showregs_op = {
 
 static void sysrq_handle_showstate(int key)
 {
+   console_printing_thread_off();
show_state();
show_workqueue_state();
+   console_printing_thread_on();
 }
 static struct sysrq_key_op sysrq_showstate_op = {
.handler= sysrq_handle_showstate,
@@ -291,7 +296,9 @@ static struct sysrq_key_op sysrq_showstate_op = {
 
 static void sysrq_handle_showstate_blocked(int key)
 {
+   console_printing_thread_off();
show_state_filter(TASK_UNINTERRUPTIBLE);
+   console_printing_thread_on();
 }
 static struct sysrq_key_op sysrq_showstate_blocked_op = {
.handler= sysrq_handle_showstate_blocked,
-- 
2.12.1



[PATCH net-next 2/2] net: dwc-xlgmac: use dual license

2017-03-22 Thread Jie Deng
The driver "dwc-xlgmac" is dual-licensed.
Declare the dual license with MODULE_LICENSE().

Signed-off-by: Jie Deng 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index cb11928..07def2b 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -21,9 +21,10 @@
 #include "dwc-xlgmac.h"
 #include "dwc-xlgmac-reg.h"
 
+MODULE_LICENSE("Dual BSD/GPL");
+
 static int debug = -1;
 module_param(debug, int, 0644);
-MODULE_LICENSE("GPL");
 MODULE_PARM_DESC(debug, "DWC ethernet debug level (0=none,...,16=all)");
 static const u32 default_msg_level = (NETIF_MSG_LINK | NETIF_MSG_IFDOWN |
  NETIF_MSG_IFUP);
-- 
1.9.1



[PATCH net-next 2/2] net: dwc-xlgmac: use dual license

2017-03-22 Thread Jie Deng
The driver "dwc-xlgmac" is dual-licensed.
Declare the dual license with MODULE_LICENSE().

Signed-off-by: Jie Deng 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index cb11928..07def2b 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -21,9 +21,10 @@
 #include "dwc-xlgmac.h"
 #include "dwc-xlgmac-reg.h"
 
+MODULE_LICENSE("Dual BSD/GPL");
+
 static int debug = -1;
 module_param(debug, int, 0644);
-MODULE_LICENSE("GPL");
 MODULE_PARM_DESC(debug, "DWC ethernet debug level (0=none,...,16=all)");
 static const u32 default_msg_level = (NETIF_MSG_LINK | NETIF_MSG_IFDOWN |
  NETIF_MSG_IFUP);
-- 
1.9.1



[PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

2017-03-22 Thread Jie Deng
The driver "dwc-xlgmac" is dual-licensed. This patch adds
declaration of dual license in file headers.

Signed-off-by: Jie Deng 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c   | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-net.c| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-reg.h| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac.h| 6 ++
 7 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index b72196a..cb11928 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
index 39b5cb9..e9672b1 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
index 1e25a86..0dec1dc 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
index 5e8428b..6acf86c 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
index 504e80d..386bafe 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an 

[PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

2017-03-22 Thread Jie Deng
The driver "dwc-xlgmac" is dual-licensed. This patch adds
declaration of dual license in file headers.

Signed-off-by: Jie Deng 
---
 drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c   | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c | 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-net.c| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac-reg.h| 6 ++
 drivers/net/ethernet/synopsys/dwc-xlgmac.h| 6 ++
 7 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index b72196a..cb11928 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
index 39b5cb9..e9672b1 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
index 1e25a86..0dec1dc 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
index 5e8428b..6acf86c 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-net.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary work of
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c 
b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
index 504e80d..386bafe 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
@@ -2,10 +2,8 @@
  *
  * Copyright (c) 2017 Synopsys, Inc. (www.synopsys.com)
  *
- * This program is free software; you can redistribute it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
+ * This program is dual-licensed; you may select either version 2 of
+ * the GNU General Public License ("GPL") or BSD license ("BSD").
  *
  * This Synopsys DWC XLGMAC software driver and associated documentation
  * (hereinafter the "Software") is an unsupported proprietary 

[GIT] Networking

2017-03-22 Thread David Miller

1) Several netfilter fixes from Pablo and the crew:
a) Handle fragmented packets properly in netfilter conntrack,
   from Florian Westphal.
b) Fix SCTP ICMP packet handling, from Ying Xue.
c) Fix big-endian bug in nftables, from Liping Zhang.
d) Fix alignment of fake conntrack entry, from Steven Rostedt.

2) Fix feature flags setting in fjes driver, from Taku Izumi.

3) Openvswitch ipv6 tunnel source address not set properly, from
   Or Gerlitz.

4) Fix jumbo MTU handling in amd-xgbe driver, from Thomas Lendacky.

5) sk->sk_frag.page not released properly in some cases, from Eric
   Dumazet.

6) Fix RTNL deadlocks in nl80211, from Johannes Berg.

7) Fix erroneous RTNL lockdep splat in crypto, from Herbert Xu.

8) Cure improper inflight handling during AF_UNIX GC, from Andrey
   Ulanov.

9) sch_dsmark doesn't write to packet headers properly, from Eric
   Dumazet.

10) Fix SCM_TIMESTAMPING_OPT_STATS handling in TCP, from Soheil Hassas
Yeganeh.

11) Add some IDs for Motorola qmi_wwan chips, from Tony Lindgren.

12) Fix nametbl deadlock in tipc, from Ying Xue.

13) GRO and LRO packets not counted correctly in mlx5 driver, from
Gal Pressman.

14) Fix reset of internal PHYs in bcmgenet, from Doug Berger.

15) Fix hashmap allocation handling, from Alexei Starovoitov.

16) nl_fib_input() needs stronger netlink message length checking,
from Eric Dumazet.

17) Fix double-free of sk->sk_filter during sock clone, from Daniel
Borkmann.

18) Fix RX checksum offloading in aquantia driver, from Pavel Belous.

Please pull, thanks a lot!

The following changes since commit 95422dec6bd4a7c57444743f7b1bb375335a6298:

  Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2017-03-15 10:44:19 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 68c386590375b2aea5a3154f17882a30170707bf:

  net:ethernet:aquantia: Fix for RX checksum offload. (2017-03-22 19:40:52 
-0700)


Alexander Potapenko (1):
  ipv6: make sure to initialize sockc.tsflags before first use

Alexei Starovoitov (1):
  bpf: fix hashmap extra_elems logic

Amitkumar Karwar (1):
  MAINTAINERS: update for mwifiex driver maintainers

Andrey Ulanov (1):
  net: unix: properly re-increment inflight counter of GC discarded 
candidates

Arnd Bergmann (3):
  cpsw/netcp: work around reverse cpts dependency
  cpsw/netcp: cpts depends on posix_timers
  Bluetooth: btqcomsmd: fix compile-test dependency

Bjørn Mork (1):
  qmi_wwan: add Dell DW5811e

Brian Norris (3):
  mwifiex: pcie: don't leak DMA buffers when removing
  mwifiex: set adapter->dev before starting to use mwifiex_dbg()
  mwifiex: uninit wakeup info when removing device

Dan Carpenter (2):
  bna: integer overflow bug in debugfs
  sfc: cleanup a condition in efx_udp_tunnel_del()

Daniel Borkmann (1):
  socket, bpf: fix sk_filter use after free in sk_clone_lock

David Ahern (3):
  net: mpls: Fix nexthop alive tracking on down events
  net: ipv6: set route type for anycast routes
  net: vrf: Reset rt6i_idev in local dst after put

David Arcari (1):
  net: ethernet: aquantia: set net_device mtu when mtu is changed

David Howells (1):
  rxrpc: Ignore BUSY packets on old calls

David S. Miller (7):
  Merge git://git.kernel.org/.../pablo/nf
  Merge tag 'batadv-net-for-davem-20170316' of 
git://git.open-mesh.org/linux-merge
  Merge branch 'vsock-pkt-cancel'
  Merge branch 'r8152-rx-settings'
  Merge tag 'wireless-drivers-for-davem-2017-03-21' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch 'mlx5-fixes'
  Merge branch 'fjes-fixes'

Doug Berger (1):
  net: bcmgenet: remove bcmgenet_internal_phy_setup()

Eric Dumazet (6):
  net: properly release sk_frag.page
  tcp: tcp_get_info() should read tcp_time_stamp later
  sch_dsmark: fix invalid skb_cow() usage
  ipv4: provide stronger user input validation in nl_fib_input()
  tcp: initialize icsk_ack.lrcvtime at session start time
  inet: frag: release spinlock before calling icmp_send()

Florian Fainelli (1):
  net: bcmgenet: Do not suspend PHY if Wake-on-LAN is enabled

Florian Westphal (2):
  netfilter: don't track fragmented packets
  netfilter: bridge: honor frag_max_size when refragmenting

Gal Pressman (2):
  net/mlx5e: Count GSO packets correctly
  net/mlx5e: Count LRO packets correctly

Govindarajulu Varadarajan (1):
  enic: update enic maintainers

Herbert Xu (1):
  crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

Jack Morgenstein (1):
  net/mlx4_core: Avoid delays during VF driver device shutdown

Johannes Berg (1):
  nl80211: fix dumpit error path RTNL deadlocks

Kris Murphy (1):
  openvswitch: Add missing case 

[GIT] Networking

2017-03-22 Thread David Miller

1) Several netfilter fixes from Pablo and the crew:
a) Handle fragmented packets properly in netfilter conntrack,
   from Florian Westphal.
b) Fix SCTP ICMP packet handling, from Ying Xue.
c) Fix big-endian bug in nftables, from Liping Zhang.
d) Fix alignment of fake conntrack entry, from Steven Rostedt.

2) Fix feature flags setting in fjes driver, from Taku Izumi.

3) Openvswitch ipv6 tunnel source address not set properly, from
   Or Gerlitz.

4) Fix jumbo MTU handling in amd-xgbe driver, from Thomas Lendacky.

5) sk->sk_frag.page not released properly in some cases, from Eric
   Dumazet.

6) Fix RTNL deadlocks in nl80211, from Johannes Berg.

7) Fix erroneous RTNL lockdep splat in crypto, from Herbert Xu.

8) Cure improper inflight handling during AF_UNIX GC, from Andrey
   Ulanov.

9) sch_dsmark doesn't write to packet headers properly, from Eric
   Dumazet.

10) Fix SCM_TIMESTAMPING_OPT_STATS handling in TCP, from Soheil Hassas
Yeganeh.

11) Add some IDs for Motorola qmi_wwan chips, from Tony Lindgren.

12) Fix nametbl deadlock in tipc, from Ying Xue.

13) GRO and LRO packets not counted correctly in mlx5 driver, from
Gal Pressman.

14) Fix reset of internal PHYs in bcmgenet, from Doug Berger.

15) Fix hashmap allocation handling, from Alexei Starovoitov.

16) nl_fib_input() needs stronger netlink message length checking,
from Eric Dumazet.

17) Fix double-free of sk->sk_filter during sock clone, from Daniel
Borkmann.

18) Fix RX checksum offloading in aquantia driver, from Pavel Belous.

Please pull, thanks a lot!

The following changes since commit 95422dec6bd4a7c57444743f7b1bb375335a6298:

  Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2017-03-15 10:44:19 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 68c386590375b2aea5a3154f17882a30170707bf:

  net:ethernet:aquantia: Fix for RX checksum offload. (2017-03-22 19:40:52 
-0700)


Alexander Potapenko (1):
  ipv6: make sure to initialize sockc.tsflags before first use

Alexei Starovoitov (1):
  bpf: fix hashmap extra_elems logic

Amitkumar Karwar (1):
  MAINTAINERS: update for mwifiex driver maintainers

Andrey Ulanov (1):
  net: unix: properly re-increment inflight counter of GC discarded 
candidates

Arnd Bergmann (3):
  cpsw/netcp: work around reverse cpts dependency
  cpsw/netcp: cpts depends on posix_timers
  Bluetooth: btqcomsmd: fix compile-test dependency

Bjørn Mork (1):
  qmi_wwan: add Dell DW5811e

Brian Norris (3):
  mwifiex: pcie: don't leak DMA buffers when removing
  mwifiex: set adapter->dev before starting to use mwifiex_dbg()
  mwifiex: uninit wakeup info when removing device

Dan Carpenter (2):
  bna: integer overflow bug in debugfs
  sfc: cleanup a condition in efx_udp_tunnel_del()

Daniel Borkmann (1):
  socket, bpf: fix sk_filter use after free in sk_clone_lock

David Ahern (3):
  net: mpls: Fix nexthop alive tracking on down events
  net: ipv6: set route type for anycast routes
  net: vrf: Reset rt6i_idev in local dst after put

David Arcari (1):
  net: ethernet: aquantia: set net_device mtu when mtu is changed

David Howells (1):
  rxrpc: Ignore BUSY packets on old calls

David S. Miller (7):
  Merge git://git.kernel.org/.../pablo/nf
  Merge tag 'batadv-net-for-davem-20170316' of 
git://git.open-mesh.org/linux-merge
  Merge branch 'vsock-pkt-cancel'
  Merge branch 'r8152-rx-settings'
  Merge tag 'wireless-drivers-for-davem-2017-03-21' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch 'mlx5-fixes'
  Merge branch 'fjes-fixes'

Doug Berger (1):
  net: bcmgenet: remove bcmgenet_internal_phy_setup()

Eric Dumazet (6):
  net: properly release sk_frag.page
  tcp: tcp_get_info() should read tcp_time_stamp later
  sch_dsmark: fix invalid skb_cow() usage
  ipv4: provide stronger user input validation in nl_fib_input()
  tcp: initialize icsk_ack.lrcvtime at session start time
  inet: frag: release spinlock before calling icmp_send()

Florian Fainelli (1):
  net: bcmgenet: Do not suspend PHY if Wake-on-LAN is enabled

Florian Westphal (2):
  netfilter: don't track fragmented packets
  netfilter: bridge: honor frag_max_size when refragmenting

Gal Pressman (2):
  net/mlx5e: Count GSO packets correctly
  net/mlx5e: Count LRO packets correctly

Govindarajulu Varadarajan (1):
  enic: update enic maintainers

Herbert Xu (1):
  crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

Jack Morgenstein (1):
  net/mlx4_core: Avoid delays during VF driver device shutdown

Johannes Berg (1):
  nl80211: fix dumpit error path RTNL deadlocks

Kris Murphy (1):
  openvswitch: Add missing case 

Re: [PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

2017-03-22 Thread Jie Deng
On 2017/3/23 2:50, David Miller wrote:

> From: Jie Deng 
> Date: Tue, 21 Mar 2017 11:59:04 +0800
>
>> This patch adds declaration of dual license in file headers.
>>
>> Signed-off-by: Jie Deng 
> My apologies.  I applied Arnd's patches.  Could you please respin
> these two patches against net-next so that the final result is what
> you want?
>
> Thanks.
Sure. Thanks.


Re: [PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

2017-03-22 Thread Jie Deng
On 2017/3/23 2:50, David Miller wrote:

> From: Jie Deng 
> Date: Tue, 21 Mar 2017 11:59:04 +0800
>
>> This patch adds declaration of dual license in file headers.
>>
>> Signed-off-by: Jie Deng 
> My apologies.  I applied Arnd's patches.  Could you please respin
> these two patches against net-next so that the final result is what
> you want?
>
> Thanks.
Sure. Thanks.


Re: [RFC v0 0/2] Introduce on-chip interconnect API

2017-03-22 Thread Moritz Fischer
On Tue, Mar 14, 2017 at 05:41:54PM +0200, Georgi Djakov wrote:
> On 03/03/2017 08:21 AM, Rob Herring wrote:
> > On Wed, Mar 01, 2017 at 08:22:33PM +0200, Georgi Djakov wrote:
> > > Modern SoCs have multiple processors and various dedicated cores (video, 
> > > gpu,
> > > graphics, modem). These cores are talking to each other and can generate 
> > > a lot
> > > of data flowing through the on-chip interconnects. These interconnect 
> > > buses
> > > could form different topologies such as crossbar, point to point buses,
> > > hierarchical buses or use the network-on-chip concept.
> > > 
> > > These buses have been sized usually to handle use cases with high data
> > > throughput but it is not necessary all the time and consume a lot of 
> > > power.
> > > Furthermore, the priority between masters can vary depending on the 
> > > running
> > > use case like video playback or cpu intensive tasks.
> > > 
> > > Having an API to control the requirement of the system in term of 
> > > bandwidth
> > > and QoS, so we can adapt the interconnect configuration to match those by
> > > scaling the frequencies, setting link priority and tuning QoS parameters.
> > > This configuration can be a static, one-time operation done at boot for 
> > > some
> > > platforms or a dynamic set of operations that happen at run-time.
> > > 
> > > This patchset introduce a new API to get the requirement and configure the
> > > interconnect buses across the entire chipset to fit with the current 
> > > demand.
> > > The API is NOT for changing the performance of the endpoint devices, but 
> > > only
> > > the interconnect path in between them.
> > > 
> > > The API is using a consumer/provider-based model, where the providers are
> > > the interconnect controllers and the consumers could be various drivers.
> > > The consumers request interconnect resources (path) to an endpoint and set
> > > the desired constraints on this data flow path. The provider(s) receive
> > > requests from consumers and aggregate these requests for all master-slave
> > > pairs on that path. Then the providers configure each participating in the
> > > topology node according to the requested data flow path, physical links 
> > > and
> > > constraints. The topology could be complicated and multi-tiered and is SoC
> > > specific.
> > > 
> > > Below is a simplified diagram of a real-world SoC topology. The 
> > > interconnect
> > > providers are the memory front-end and the NoCs.
> > > 
> > > ++++
> > > | HW Accelerator |--->|  M NoC |<---+
> > > ++++|
> > > |  |++
> > >   +-+  V   +--+ ||
> > >   |++  | PCIe | ||
> > >   || Slaves |  +--+ ||
> > >   |++ | |   C NoC|
> > >   V   V ||
> > > +--+   ++   ||   
> > > +-+
> > > |  |-->||-->||-->| 
> > > CPU |
> > > |  |-->||<--||   
> > > +-+
> > > |  Memory  |   | S NoC  |   ++
> > > |  |<--||-+|
> > > |  |<--||<--+ ||   
> > > ++
> > > +--+   ++   | |+-->| 
> > > Slaves |
> > >^ ^^   ^ | |
> > > ++
> > >| ||   | | V
> > > +-+  |  +-++-+  +-+   ++   
> > > ++
> > > | CPU |  |  | GPU || DSP |  | Masters |-->|   P NoC|-->| 
> > > Slaves |
> > > +-+  |  +-++-+  +-+   ++   
> > > ++
> > >  |
> > >  +---+
> > >  | Modem |
> > >  +---+
> > > 
> > > This RFC does not implement all features but only main skeleton to check 
> > > the
> > > validity of the proposal. Currently it only works with device-tree and 
> > > platform
> > > devices.
> > > 
> > > TODO:
> > >  * Constraints are currently stored in internal data structure. Should PM 
> > > QoS
> > >  be used instead?
> > >  * Rework the framework to not depend on DT as frameworks cannot be tied
> > >  directly to firmware interfaces. Add support for ACPI?
> > 
> > I would start without DT even. You can always have the data you need in
> > the kernel. This will be more flexible as you're not defining an ABI as
> > this evolves. I think it will take some time to have consensus on how to
> > represent the bus master view of buses/interconnects (It's been
> > attempted before).
> > 

Re: [PATCH v2 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs

2017-03-22 Thread 陈亮

Hi, Heiko

在 2017年03月21日 16:55, Heiko Stübner 写道:

Hi,

Am Donnerstag, 16. März 2017, 21:17:22 CET schrieb c...@rock-chips.com:

+   assigned-clock-parents =
+   < HDMIPHY>, < PLL_APLL>,
+   < PLL_GPLL>, <>,
+   <>, <>;
+   assigned-clock-rates =
+   <0>, <6144>,
+   <0>, <2400>,
+   <2400>, <2400>,
+   <1500>, <1500>,
+   <1>, <1>,
+   <1>, <1>,
+   <5000>, <1>,
+   <1>, <1>,
+   <5000>, <5000>,
+   <5000>, <5000>,
+   <2400>, <6>,
+   <49152>, <12>,
+   <15000>, <7500>,
+   <7500>, <15000>,
+   <7500>, <7500>,
+   <3>, <1>,
+   <3>, <2>,
+   <4>, <5>,
+   <2>, <3>,
+   <3>, <25000>,
+   <2>, <1>,
+   <2400>, <1>,
+   <15000>, <5000>,
+   <32768>, <32768>;
+   };
+
+   gmac2io: eth@ff54 {

phandle should be gmac instead?
Node name, ethernet@ff54
RK3328 have another gmac channel with PHY in the soc, so gmac2io mean 
the channel with the PHY outside, and it is also called gmac2io in the TRM.



Heiko






Re: [RFC v0 0/2] Introduce on-chip interconnect API

2017-03-22 Thread Moritz Fischer
On Tue, Mar 14, 2017 at 05:41:54PM +0200, Georgi Djakov wrote:
> On 03/03/2017 08:21 AM, Rob Herring wrote:
> > On Wed, Mar 01, 2017 at 08:22:33PM +0200, Georgi Djakov wrote:
> > > Modern SoCs have multiple processors and various dedicated cores (video, 
> > > gpu,
> > > graphics, modem). These cores are talking to each other and can generate 
> > > a lot
> > > of data flowing through the on-chip interconnects. These interconnect 
> > > buses
> > > could form different topologies such as crossbar, point to point buses,
> > > hierarchical buses or use the network-on-chip concept.
> > > 
> > > These buses have been sized usually to handle use cases with high data
> > > throughput but it is not necessary all the time and consume a lot of 
> > > power.
> > > Furthermore, the priority between masters can vary depending on the 
> > > running
> > > use case like video playback or cpu intensive tasks.
> > > 
> > > Having an API to control the requirement of the system in term of 
> > > bandwidth
> > > and QoS, so we can adapt the interconnect configuration to match those by
> > > scaling the frequencies, setting link priority and tuning QoS parameters.
> > > This configuration can be a static, one-time operation done at boot for 
> > > some
> > > platforms or a dynamic set of operations that happen at run-time.
> > > 
> > > This patchset introduce a new API to get the requirement and configure the
> > > interconnect buses across the entire chipset to fit with the current 
> > > demand.
> > > The API is NOT for changing the performance of the endpoint devices, but 
> > > only
> > > the interconnect path in between them.
> > > 
> > > The API is using a consumer/provider-based model, where the providers are
> > > the interconnect controllers and the consumers could be various drivers.
> > > The consumers request interconnect resources (path) to an endpoint and set
> > > the desired constraints on this data flow path. The provider(s) receive
> > > requests from consumers and aggregate these requests for all master-slave
> > > pairs on that path. Then the providers configure each participating in the
> > > topology node according to the requested data flow path, physical links 
> > > and
> > > constraints. The topology could be complicated and multi-tiered and is SoC
> > > specific.
> > > 
> > > Below is a simplified diagram of a real-world SoC topology. The 
> > > interconnect
> > > providers are the memory front-end and the NoCs.
> > > 
> > > ++++
> > > | HW Accelerator |--->|  M NoC |<---+
> > > ++++|
> > > |  |++
> > >   +-+  V   +--+ ||
> > >   |++  | PCIe | ||
> > >   || Slaves |  +--+ ||
> > >   |++ | |   C NoC|
> > >   V   V ||
> > > +--+   ++   ||   
> > > +-+
> > > |  |-->||-->||-->| 
> > > CPU |
> > > |  |-->||<--||   
> > > +-+
> > > |  Memory  |   | S NoC  |   ++
> > > |  |<--||-+|
> > > |  |<--||<--+ ||   
> > > ++
> > > +--+   ++   | |+-->| 
> > > Slaves |
> > >^ ^^   ^ | |
> > > ++
> > >| ||   | | V
> > > +-+  |  +-++-+  +-+   ++   
> > > ++
> > > | CPU |  |  | GPU || DSP |  | Masters |-->|   P NoC|-->| 
> > > Slaves |
> > > +-+  |  +-++-+  +-+   ++   
> > > ++
> > >  |
> > >  +---+
> > >  | Modem |
> > >  +---+
> > > 
> > > This RFC does not implement all features but only main skeleton to check 
> > > the
> > > validity of the proposal. Currently it only works with device-tree and 
> > > platform
> > > devices.
> > > 
> > > TODO:
> > >  * Constraints are currently stored in internal data structure. Should PM 
> > > QoS
> > >  be used instead?
> > >  * Rework the framework to not depend on DT as frameworks cannot be tied
> > >  directly to firmware interfaces. Add support for ACPI?
> > 
> > I would start without DT even. You can always have the data you need in
> > the kernel. This will be more flexible as you're not defining an ABI as
> > this evolves. I think it will take some time to have consensus on how to
> > represent the bus master view of buses/interconnects (It's been
> > attempted before).
> > 

Re: [PATCH v2 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs

2017-03-22 Thread 陈亮

Hi, Heiko

在 2017年03月21日 16:55, Heiko Stübner 写道:

Hi,

Am Donnerstag, 16. März 2017, 21:17:22 CET schrieb c...@rock-chips.com:

+   assigned-clock-parents =
+   < HDMIPHY>, < PLL_APLL>,
+   < PLL_GPLL>, <>,
+   <>, <>;
+   assigned-clock-rates =
+   <0>, <6144>,
+   <0>, <2400>,
+   <2400>, <2400>,
+   <1500>, <1500>,
+   <1>, <1>,
+   <1>, <1>,
+   <5000>, <1>,
+   <1>, <1>,
+   <5000>, <5000>,
+   <5000>, <5000>,
+   <2400>, <6>,
+   <49152>, <12>,
+   <15000>, <7500>,
+   <7500>, <15000>,
+   <7500>, <7500>,
+   <3>, <1>,
+   <3>, <2>,
+   <4>, <5>,
+   <2>, <3>,
+   <3>, <25000>,
+   <2>, <1>,
+   <2400>, <1>,
+   <15000>, <5000>,
+   <32768>, <32768>;
+   };
+
+   gmac2io: eth@ff54 {

phandle should be gmac instead?
Node name, ethernet@ff54
RK3328 have another gmac channel with PHY in the soc, so gmac2io mean 
the channel with the PHY outside, and it is also called gmac2io in the TRM.



Heiko






RE: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

2017-03-22 Thread Bard Liao
> -Original Message-
> From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com]
> Sent: Wednesday, March 22, 2017 1:37 PM
> To: Bard Liao
> Cc: broo...@kernel.org; lgirdw...@gmail.com; Oder Chiou;
> alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell
> XPS 9343 I2S mode
> 
> >> What I really want to do is something rt5670's rt5670_hp_event(),
> >> maybe autodisable is not enough sometimes?
> >
> > It is different. rt5670_hp_event() is doing depop sequence for
> > headphone. And there is no other mute/unmute controls on other
> > dapm widgets. For me, what you do here is not different from
> > "HPO L" and "HPO R" do.
> 
> There are two issues - background click noise and the cracking pop noise.
> Depop is exactly what I want to do here.

Let me explain it in more detail. rt5670 need to set a serious of
registers to prevent the pop noise of powering up/down muting/
unmuting headphone. That's what rt5670_hp_event() does. But,
what rt286_hp_power_event do is only mute/unmute headphone
which is done by "HPO L" and "HPO R" widget.

> 
> >
> >>
> >> > "HPO L" and "HPO R". From my understanding, HPO will mute if "HP
> Power"
> >> > is powered down. Any specific reason for muting HPO again before "HP
> >> Power"
> >> > is powered up?
> >>
> >> You are right. Either one of them should be sufficient.
> >
> > My point is that you seem to do things that driver is already done.
> > But why and how it can reduce the click noise?
> 
> This is for the crack (pop) noise not click noise - see below.
> 
> >
> >>
> >> > Will HPO be unmuted before "HP Power" is powered up on your system?
> >>
> >> Yes.
> >> I am no audio expert here - but from what I read from HDA, there's
> >> actually no AMP unmute counterpart to AMP mute.
> >
> > I didn't get it. How did you check if HPO is muted?
> 
> I didn't. Now sure why do we need to check that?

If HPO is already muted as what we expected, it means "HPO L" and "HPO R"
work properly. And there is no reason we create an event to do the same
thing.

> >>
> >> I found that the effect is most noticeable if the mute callback is
> >> associated with "LDO2" and "HP Power".
> >> But again, this is just what I observed.
> >
> > Could you try only associated with "LDO2"?
> > It makes sense that will reduce the noise if a jack is plugged in/out
> > when HPO is already powered up.
> 
> Does it also help to reduce noise at other power events?

I don't know. In theory, you shouldn't hear any sound when HPO
is muted. If you need our help for debugging, please send a mail
to our FAE and cc me.

> 
> >
> > I have question about the code below
> > +   /* Fix headphone click noise */
> > +   if (dmi_check_system(dmi_dell_dino))
> > +   regmap_write(rt286->regmap,
> > +   RT286_MIC1_DET_CTRL,
> 0x0020);
> > +
> >
> > What does this for? How did you get the value 0x0020?
> > I just checked with Kailang, but he have no idea about that.
> 
> It's PIN_VREFHIZ. It's from commit 3e1b0c4a9d56.

snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
0x19 here means nid 0x19. But if you write 0x19 in rt286.c means
write a hidden register with index 0x19. It is totally different.
The corresponding code on rt286.c will be
rt286->regmap(rt286->regmap,
VERB_CMD(AC_VERB_SET_PIN_WIDGET_CONTROL, 0x19, 0x20));
> 
> >
> >>
> >> >
> >> >
> >>
> >> --Please consider the environment before printing this e-mail.


RE: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

2017-03-22 Thread Bard Liao
> -Original Message-
> From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com]
> Sent: Wednesday, March 22, 2017 1:37 PM
> To: Bard Liao
> Cc: broo...@kernel.org; lgirdw...@gmail.com; Oder Chiou;
> alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell
> XPS 9343 I2S mode
> 
> >> What I really want to do is something rt5670's rt5670_hp_event(),
> >> maybe autodisable is not enough sometimes?
> >
> > It is different. rt5670_hp_event() is doing depop sequence for
> > headphone. And there is no other mute/unmute controls on other
> > dapm widgets. For me, what you do here is not different from
> > "HPO L" and "HPO R" do.
> 
> There are two issues - background click noise and the cracking pop noise.
> Depop is exactly what I want to do here.

Let me explain it in more detail. rt5670 need to set a serious of
registers to prevent the pop noise of powering up/down muting/
unmuting headphone. That's what rt5670_hp_event() does. But,
what rt286_hp_power_event do is only mute/unmute headphone
which is done by "HPO L" and "HPO R" widget.

> 
> >
> >>
> >> > "HPO L" and "HPO R". From my understanding, HPO will mute if "HP
> Power"
> >> > is powered down. Any specific reason for muting HPO again before "HP
> >> Power"
> >> > is powered up?
> >>
> >> You are right. Either one of them should be sufficient.
> >
> > My point is that you seem to do things that driver is already done.
> > But why and how it can reduce the click noise?
> 
> This is for the crack (pop) noise not click noise - see below.
> 
> >
> >>
> >> > Will HPO be unmuted before "HP Power" is powered up on your system?
> >>
> >> Yes.
> >> I am no audio expert here - but from what I read from HDA, there's
> >> actually no AMP unmute counterpart to AMP mute.
> >
> > I didn't get it. How did you check if HPO is muted?
> 
> I didn't. Now sure why do we need to check that?

If HPO is already muted as what we expected, it means "HPO L" and "HPO R"
work properly. And there is no reason we create an event to do the same
thing.

> >>
> >> I found that the effect is most noticeable if the mute callback is
> >> associated with "LDO2" and "HP Power".
> >> But again, this is just what I observed.
> >
> > Could you try only associated with "LDO2"?
> > It makes sense that will reduce the noise if a jack is plugged in/out
> > when HPO is already powered up.
> 
> Does it also help to reduce noise at other power events?

I don't know. In theory, you shouldn't hear any sound when HPO
is muted. If you need our help for debugging, please send a mail
to our FAE and cc me.

> 
> >
> > I have question about the code below
> > +   /* Fix headphone click noise */
> > +   if (dmi_check_system(dmi_dell_dino))
> > +   regmap_write(rt286->regmap,
> > +   RT286_MIC1_DET_CTRL,
> 0x0020);
> > +
> >
> > What does this for? How did you get the value 0x0020?
> > I just checked with Kailang, but he have no idea about that.
> 
> It's PIN_VREFHIZ. It's from commit 3e1b0c4a9d56.

snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
0x19 here means nid 0x19. But if you write 0x19 in rt286.c means
write a hidden register with index 0x19. It is totally different.
The corresponding code on rt286.c will be
rt286->regmap(rt286->regmap,
VERB_CMD(AC_VERB_SET_PIN_WIDGET_CONTROL, 0x19, 0x20));
> 
> >
> >>
> >> >
> >> >
> >>
> >> --Please consider the environment before printing this e-mail.


Ftrace: Static function graph not work

2017-03-22 Thread Zong Li
Hi all,

I test the static function graph for ARM, x86 and x86_64 architecture
on linux-3.10 and linux-4.9, and I find it works correctly only for
x86_64 on linux-4.9.

After the following commit, the function tracer also be registered
when registering the function graph tracer.

commit 2940c25bec92f40a3f7f32504b8ea115d1701892
Author: Steven Rostedt (Red Hat) 
CommitDate: Wed Dec 4 10:57:05 2013 -0800

ftrace: Fix function graph with loading of modules


The arch-depend code implement the mcount function pseudo code like:

void mcount(void)
{
...
if (ftrace_trace_function != ftrace_stub)
goto do_trace;

#ifdef CONFIG_FUNCTION_GRAPH_TRACER
   if (ftrace_graph_return != ftrace_stub ||
   ftrace_graph_entry != ftrace_graph_entry_stub)
   ftrace_graph_caller();
#endif
return;

do_trace:
...
}

The function pointer 'ftrace_trace_function' will not be 'ftrace_stub'
because function tracer is registered too, so the function graph part
will not be executed.


On the other hand, I find the another patch to resolve this situation,
and it is reason that x86_64 architecture can work correctly.

commit 62a207d748dd9224140a634786b274fdb6ece0b9
Author: Steven Rostedt (Red Hat) 
CommitDate: Mon Nov 24 15:02:25 2014 -0500

ftrace/x86: Have static function tracing always test for function graph


so, is this problem tending to handle by each architecture? or maybe
it is need to solve by generic code?


This is my first mail to mailing list, please excuse having mistake
and let me know.
Thank a lot !


Ftrace: Static function graph not work

2017-03-22 Thread Zong Li
Hi all,

I test the static function graph for ARM, x86 and x86_64 architecture
on linux-3.10 and linux-4.9, and I find it works correctly only for
x86_64 on linux-4.9.

After the following commit, the function tracer also be registered
when registering the function graph tracer.

commit 2940c25bec92f40a3f7f32504b8ea115d1701892
Author: Steven Rostedt (Red Hat) 
CommitDate: Wed Dec 4 10:57:05 2013 -0800

ftrace: Fix function graph with loading of modules


The arch-depend code implement the mcount function pseudo code like:

void mcount(void)
{
...
if (ftrace_trace_function != ftrace_stub)
goto do_trace;

#ifdef CONFIG_FUNCTION_GRAPH_TRACER
   if (ftrace_graph_return != ftrace_stub ||
   ftrace_graph_entry != ftrace_graph_entry_stub)
   ftrace_graph_caller();
#endif
return;

do_trace:
...
}

The function pointer 'ftrace_trace_function' will not be 'ftrace_stub'
because function tracer is registered too, so the function graph part
will not be executed.


On the other hand, I find the another patch to resolve this situation,
and it is reason that x86_64 architecture can work correctly.

commit 62a207d748dd9224140a634786b274fdb6ece0b9
Author: Steven Rostedt (Red Hat) 
CommitDate: Mon Nov 24 15:02:25 2014 -0500

ftrace/x86: Have static function tracing always test for function graph


so, is this problem tending to handle by each architecture? or maybe
it is need to solve by generic code?


This is my first mail to mailing list, please excuse having mistake
and let me know.
Thank a lot !


[PATCH v1 RESEND 2/2] x86/efi: Clean up a minor mistake in code comment

2017-03-22 Thread Baoquan He
EFI allocate runtime services regions from EFI_VA_START, -4G, down
to -64G, EFI_VA_END. The mechanism was introduced in
commit d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping").

Clean it up to avoid confusion.

Signed-off-by: Baoquan He 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
 arch/x86/platform/efi/efi_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index a4695da..6cbf9e0 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -47,7 +47,7 @@
 #include 
 
 /*
- * We allocate runtime services regions bottom-up, starting from -4G, i.e.
+ * We allocate runtime services regions top-down, starting from -4G, i.e.
  * 0x___ and limit EFI VA mapping space to 64G.
  */
 static u64 efi_va = EFI_VA_START;
-- 
2.5.5



linux-next: manual merge of the livepatching tree with the s390 tree

2017-03-22 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the livepatching tree got conflicts in:

  arch/s390/include/asm/thread_info.h
  arch/s390/kernel/entry.S

between commit:

  916cda1aa1b4 ("s390: add a system call for guarded storage")

from the s390 tree and commits:

  30d64f1904d4 ("livepatch/s390: reorganize TIF thread flag bits")
  2f09ca60a56d ("livepatch/s390: add TIF_PATCH_PENDING thread flag")

from the livepatching tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/s390/include/asm/thread_info.h
index f36e6e2b73f0,646845edf148..
--- a/arch/s390/include/asm/thread_info.h
+++ b/arch/s390/include/asm/thread_info.h
@@@ -55,11 -56,8 +56,9 @@@ int arch_dup_task_struct(struct task_st
  #define TIF_SIGPENDING1   /* signal pending */
  #define TIF_NEED_RESCHED  2   /* rescheduling necessary */
  #define TIF_UPROBE3   /* breakpointed or single-stepping */
 -#define TIF_PATCH_PENDING 4   /* pending live patching update */
 +#define TIF_GUARDED_STORAGE   4   /* load guarded storage control block */
- #define TIF_SYSCALL_TRACE 8   /* syscall trace active */
- #define TIF_SYSCALL_AUDIT 9   /* syscall auditing active */
- #define TIF_SECCOMP   10  /* secure computing */
- #define TIF_SYSCALL_TRACEPOINT11  /* syscall tracepoint 
instrumentation */
++#define TIF_PATCH_PENDING 5   /* pending live patching update */
+ 
  #define TIF_31BIT 16  /* 32bit process */
  #define TIF_MEMDIE17  /* is terminating due to OOM killer */
  #define TIF_RESTORE_SIGMASK   18  /* restore signal mask in do_signal() */
@@@ -70,6 -74,12 +75,13 @@@
  #define _TIF_NOTIFY_RESUME_BITUL(TIF_NOTIFY_RESUME)
  #define _TIF_SIGPENDING   _BITUL(TIF_SIGPENDING)
  #define _TIF_NEED_RESCHED _BITUL(TIF_NEED_RESCHED)
+ #define _TIF_UPROBE   _BITUL(TIF_UPROBE)
++#define _TIF_GUARDED_STORAGE  _BITUL(TIF_GUARDED_STORAGE)
+ #define _TIF_PATCH_PENDING_BITUL(TIF_PATCH_PENDING)
+ 
+ #define _TIF_31BIT_BITUL(TIF_31BIT)
+ #define _TIF_SINGLE_STEP  _BITUL(TIF_SINGLE_STEP)
+ 
  #define _TIF_SYSCALL_TRACE_BITUL(TIF_SYSCALL_TRACE)
  #define _TIF_SYSCALL_AUDIT_BITUL(TIF_SYSCALL_AUDIT)
  #define _TIF_SECCOMP  _BITUL(TIF_SECCOMP)
diff --cc arch/s390/kernel/entry.S
index fa8b8f28e08b,a08b5eea5567..
--- a/arch/s390/kernel/entry.S
+++ b/arch/s390/kernel/entry.S
@@@ -47,7 -47,7 +47,7 @@@ STACK_SIZE  = 1 << STACK_SHIF
  STACK_INIT = STACK_SIZE - STACK_FRAME_OVERHEAD - __PT_SIZE
  
  _TIF_WORK = (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME | _TIF_NEED_RESCHED | \
-  _TIF_UPROBE | _TIF_GUARDED_STORAGE)
 - _TIF_UPROBE | _TIF_PATCH_PENDING)
++ _TIF_UPROBE | _TIF_GUARDED_STORAGE | _TIF_PATCH_PENDING)
  _TIF_TRACE= (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | _TIF_SECCOMP | \
   _TIF_SYSCALL_TRACEPOINT)
  _CIF_WORK = (_CIF_MCCK_PENDING | _CIF_ASCE_PRIMARY | \
@@@ -332,10 -332,13 +332,15 @@@ ENTRY(system_call
TSTMSK  __TI_flags(%r12),_TIF_UPROBE
jo  .Lsysc_uprobe_notify
  #endif
 +  TSTMSK  __TI_flags(%r12),_TIF_GUARDED_STORAGE
 +  jo  .Lsysc_guarded_storage
TSTMSK  __PT_FLAGS(%r11),_PIF_PER_TRAP
jo  .Lsysc_singlestep
+ #ifdef CONFIG_LIVEPATCH
+   TSTMSK  __TI_flags(%r12),_TIF_PATCH_PENDING
+   jo  .Lsysc_patch_pending# handle live patching just before
+   # signals and possible syscall restart
+ #endif
TSTMSK  __TI_flags(%r12),_TIF_SIGPENDING
jo  .Lsysc_sigpending
TSTMSK  __TI_flags(%r12),_TIF_NOTIFY_RESUME
@@@ -411,13 -414,15 +416,22 @@@
  #endif
  
  #
 +# _TIF_GUARDED_STORAGE is set, call guarded_storage_load
 +#
 +.Lsysc_guarded_storage:
 +  lgr %r2,%r11# pass pointer to pt_regs
 +  larl%r14,.Lsysc_return
 +  jg  gs_load_bc_cb
 +
+ # _TIF_PATCH_PENDING is set, call klp_update_patch_state
+ #
+ #ifdef CONFIG_LIVEPATCH
+ .Lsysc_patch_pending:
+   lg  %r2,__LC_CURRENT# pass pointer to task struct
+   larl%r14,.Lsysc_return
+   jg  klp_update_patch_state
+ #endif
+ 
  #
  # _PIF_PER_TRAP is set, call do_per_trap
  #


[PATCH v1 RESEND 2/2] x86/efi: Clean up a minor mistake in code comment

2017-03-22 Thread Baoquan He
EFI allocate runtime services regions from EFI_VA_START, -4G, down
to -64G, EFI_VA_END. The mechanism was introduced in
commit d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping").

Clean it up to avoid confusion.

Signed-off-by: Baoquan He 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
 arch/x86/platform/efi/efi_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index a4695da..6cbf9e0 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -47,7 +47,7 @@
 #include 
 
 /*
- * We allocate runtime services regions bottom-up, starting from -4G, i.e.
+ * We allocate runtime services regions top-down, starting from -4G, i.e.
  * 0x___ and limit EFI VA mapping space to 64G.
  */
 static u64 efi_va = EFI_VA_START;
-- 
2.5.5



linux-next: manual merge of the livepatching tree with the s390 tree

2017-03-22 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the livepatching tree got conflicts in:

  arch/s390/include/asm/thread_info.h
  arch/s390/kernel/entry.S

between commit:

  916cda1aa1b4 ("s390: add a system call for guarded storage")

from the s390 tree and commits:

  30d64f1904d4 ("livepatch/s390: reorganize TIF thread flag bits")
  2f09ca60a56d ("livepatch/s390: add TIF_PATCH_PENDING thread flag")

from the livepatching tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/s390/include/asm/thread_info.h
index f36e6e2b73f0,646845edf148..
--- a/arch/s390/include/asm/thread_info.h
+++ b/arch/s390/include/asm/thread_info.h
@@@ -55,11 -56,8 +56,9 @@@ int arch_dup_task_struct(struct task_st
  #define TIF_SIGPENDING1   /* signal pending */
  #define TIF_NEED_RESCHED  2   /* rescheduling necessary */
  #define TIF_UPROBE3   /* breakpointed or single-stepping */
 -#define TIF_PATCH_PENDING 4   /* pending live patching update */
 +#define TIF_GUARDED_STORAGE   4   /* load guarded storage control block */
- #define TIF_SYSCALL_TRACE 8   /* syscall trace active */
- #define TIF_SYSCALL_AUDIT 9   /* syscall auditing active */
- #define TIF_SECCOMP   10  /* secure computing */
- #define TIF_SYSCALL_TRACEPOINT11  /* syscall tracepoint 
instrumentation */
++#define TIF_PATCH_PENDING 5   /* pending live patching update */
+ 
  #define TIF_31BIT 16  /* 32bit process */
  #define TIF_MEMDIE17  /* is terminating due to OOM killer */
  #define TIF_RESTORE_SIGMASK   18  /* restore signal mask in do_signal() */
@@@ -70,6 -74,12 +75,13 @@@
  #define _TIF_NOTIFY_RESUME_BITUL(TIF_NOTIFY_RESUME)
  #define _TIF_SIGPENDING   _BITUL(TIF_SIGPENDING)
  #define _TIF_NEED_RESCHED _BITUL(TIF_NEED_RESCHED)
+ #define _TIF_UPROBE   _BITUL(TIF_UPROBE)
++#define _TIF_GUARDED_STORAGE  _BITUL(TIF_GUARDED_STORAGE)
+ #define _TIF_PATCH_PENDING_BITUL(TIF_PATCH_PENDING)
+ 
+ #define _TIF_31BIT_BITUL(TIF_31BIT)
+ #define _TIF_SINGLE_STEP  _BITUL(TIF_SINGLE_STEP)
+ 
  #define _TIF_SYSCALL_TRACE_BITUL(TIF_SYSCALL_TRACE)
  #define _TIF_SYSCALL_AUDIT_BITUL(TIF_SYSCALL_AUDIT)
  #define _TIF_SECCOMP  _BITUL(TIF_SECCOMP)
diff --cc arch/s390/kernel/entry.S
index fa8b8f28e08b,a08b5eea5567..
--- a/arch/s390/kernel/entry.S
+++ b/arch/s390/kernel/entry.S
@@@ -47,7 -47,7 +47,7 @@@ STACK_SIZE  = 1 << STACK_SHIF
  STACK_INIT = STACK_SIZE - STACK_FRAME_OVERHEAD - __PT_SIZE
  
  _TIF_WORK = (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME | _TIF_NEED_RESCHED | \
-  _TIF_UPROBE | _TIF_GUARDED_STORAGE)
 - _TIF_UPROBE | _TIF_PATCH_PENDING)
++ _TIF_UPROBE | _TIF_GUARDED_STORAGE | _TIF_PATCH_PENDING)
  _TIF_TRACE= (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | _TIF_SECCOMP | \
   _TIF_SYSCALL_TRACEPOINT)
  _CIF_WORK = (_CIF_MCCK_PENDING | _CIF_ASCE_PRIMARY | \
@@@ -332,10 -332,13 +332,15 @@@ ENTRY(system_call
TSTMSK  __TI_flags(%r12),_TIF_UPROBE
jo  .Lsysc_uprobe_notify
  #endif
 +  TSTMSK  __TI_flags(%r12),_TIF_GUARDED_STORAGE
 +  jo  .Lsysc_guarded_storage
TSTMSK  __PT_FLAGS(%r11),_PIF_PER_TRAP
jo  .Lsysc_singlestep
+ #ifdef CONFIG_LIVEPATCH
+   TSTMSK  __TI_flags(%r12),_TIF_PATCH_PENDING
+   jo  .Lsysc_patch_pending# handle live patching just before
+   # signals and possible syscall restart
+ #endif
TSTMSK  __TI_flags(%r12),_TIF_SIGPENDING
jo  .Lsysc_sigpending
TSTMSK  __TI_flags(%r12),_TIF_NOTIFY_RESUME
@@@ -411,13 -414,15 +416,22 @@@
  #endif
  
  #
 +# _TIF_GUARDED_STORAGE is set, call guarded_storage_load
 +#
 +.Lsysc_guarded_storage:
 +  lgr %r2,%r11# pass pointer to pt_regs
 +  larl%r14,.Lsysc_return
 +  jg  gs_load_bc_cb
 +
+ # _TIF_PATCH_PENDING is set, call klp_update_patch_state
+ #
+ #ifdef CONFIG_LIVEPATCH
+ .Lsysc_patch_pending:
+   lg  %r2,__LC_CURRENT# pass pointer to task struct
+   larl%r14,.Lsysc_return
+   jg  klp_update_patch_state
+ #endif
+ 
  #
  # _PIF_PER_TRAP is set, call do_per_trap
  #


[PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

2017-03-22 Thread Baoquan He
Currently KASLR is enabled on three regions: the direct mapping of physical
memory, vamlloc and vmemmap. However EFI region is also mistakenly included
for VA space randomization because of misusing EFI_VA_START macro and
assuming EFI_VA_START < EFI_VA_END.

The EFI region is reserved for EFI runtime services virtual mapping which
should not be included in kaslr ranges. It will be re-used by kexec/kdump
kernel, the mistake may cause failure when jump to kexec/kdump kernel if
vmemmap allocation stomps on the allocated efi mapping region.

In Documentation/x86/x86_64/mm.txt, we can see:
  ffef - fffe (=64 GB) EFI region mapping space
EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END
Here EFI_VA_START = -4G, and EFI_VA_END = -64G

Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.

Cc:  #4.8+
Signed-off-by: Baoquan He 
Acked-by: Dave Young 
Reviewed-by: Bhupesh Sharma 
Acked-by: Thomas Garnier 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin"  
Cc: x...@kernel.org
Cc: Thomas Garnier 
Cc: Kees Cook 
Cc: Borislav Petkov 
Cc: Andrew Morton 
Cc: Masahiro Yamada 
---
 arch/x86/mm/kaslr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 887e571..aed2064 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -48,7 +48,7 @@ static const unsigned long vaddr_start = __PAGE_OFFSET_BASE;
 #if defined(CONFIG_X86_ESPFIX64)
 static const unsigned long vaddr_end = ESPFIX_BASE_ADDR;
 #elif defined(CONFIG_EFI)
-static const unsigned long vaddr_end = EFI_VA_START;
+static const unsigned long vaddr_end = EFI_VA_END;
 #else
 static const unsigned long vaddr_end = __START_KERNEL_map;
 #endif
@@ -105,7 +105,7 @@ void __init kernel_randomize_memory(void)
 */
BUILD_BUG_ON(vaddr_start >= vaddr_end);
BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) &&
-vaddr_end >= EFI_VA_START);
+vaddr_end >= EFI_VA_END);
BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) ||
  IS_ENABLED(CONFIG_EFI)) &&
 vaddr_end >= __START_KERNEL_map);
-- 
2.5.5



[PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

2017-03-22 Thread Baoquan He
Currently KASLR is enabled on three regions: the direct mapping of physical
memory, vamlloc and vmemmap. However EFI region is also mistakenly included
for VA space randomization because of misusing EFI_VA_START macro and
assuming EFI_VA_START < EFI_VA_END.

The EFI region is reserved for EFI runtime services virtual mapping which
should not be included in kaslr ranges. It will be re-used by kexec/kdump
kernel, the mistake may cause failure when jump to kexec/kdump kernel if
vmemmap allocation stomps on the allocated efi mapping region.

In Documentation/x86/x86_64/mm.txt, we can see:
  ffef - fffe (=64 GB) EFI region mapping space
EFI use the space from -4G to -64G thus EFI_VA_START > EFI_VA_END
Here EFI_VA_START = -4G, and EFI_VA_END = -64G

Changing EFI_VA_START to EFI_VA_END in mm/kaslr.c fixes this problem.

Cc:  #4.8+
Signed-off-by: Baoquan He 
Acked-by: Dave Young 
Reviewed-by: Bhupesh Sharma 
Acked-by: Thomas Garnier 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin"  
Cc: x...@kernel.org
Cc: Thomas Garnier 
Cc: Kees Cook 
Cc: Borislav Petkov 
Cc: Andrew Morton 
Cc: Masahiro Yamada 
---
 arch/x86/mm/kaslr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 887e571..aed2064 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -48,7 +48,7 @@ static const unsigned long vaddr_start = __PAGE_OFFSET_BASE;
 #if defined(CONFIG_X86_ESPFIX64)
 static const unsigned long vaddr_end = ESPFIX_BASE_ADDR;
 #elif defined(CONFIG_EFI)
-static const unsigned long vaddr_end = EFI_VA_START;
+static const unsigned long vaddr_end = EFI_VA_END;
 #else
 static const unsigned long vaddr_end = __START_KERNEL_map;
 #endif
@@ -105,7 +105,7 @@ void __init kernel_randomize_memory(void)
 */
BUILD_BUG_ON(vaddr_start >= vaddr_end);
BUILD_BUG_ON(IS_ENABLED(CONFIG_X86_ESPFIX64) &&
-vaddr_end >= EFI_VA_START);
+vaddr_end >= EFI_VA_END);
BUILD_BUG_ON((IS_ENABLED(CONFIG_X86_ESPFIX64) ||
  IS_ENABLED(CONFIG_EFI)) &&
 vaddr_end >= __START_KERNEL_map);
-- 
2.5.5



[PATCH v3 6/6] powerpc/perf: Add Power8 mem_access event to sysfs

2017-03-22 Thread Madhavan Srinivasan
Patch add "mem_access" event to sysfs. This as-is not a raw event
supported by Power8 pmu. Instead, it is formed based on
raw event encoding specificed in isa207-common.h.

Primary PMU event used here is PM_MRK_INST_CMPL.
This event tracks only the completed marked instructions.

Random sampling mode (MMCRA[SM]) with Random Instruction
Sampling (RIS) is enabled to mark type of instructions.

With Random sampling in RLS mode with PM_MRK_INST_CMPL event,
the LDST /DATA_SRC fields in SIER identifies the memory
hierarchy level (eg: L1, L2 etc) statisfied a data-cache
miss for a marked instruction.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Sukadev Bhattiprolu 
Cc: Daniel Axtens 
Cc: Andrew Donnellan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power8-events-list.h | 6 ++
 arch/powerpc/perf/power8-pmu.c | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/arch/powerpc/perf/power8-events-list.h 
b/arch/powerpc/perf/power8-events-list.h
index 3a2e6e8ebb92..0f1d184627cc 100644
--- a/arch/powerpc/perf/power8-events-list.h
+++ b/arch/powerpc/perf/power8-events-list.h
@@ -89,3 +89,9 @@ EVENT(PM_MRK_FILT_MATCH,  0x2013c)
 EVENT(PM_MRK_FILT_MATCH_ALT,   0x3012e)
 /* Alternate event code for PM_LD_MISS_L1 */
 EVENT(PM_LD_MISS_L1_ALT,   0x400f0)
+/*
+ * Memory Access Event -- mem_access
+ * Primary PMU event used here is PM_MRK_INST_CMPL, along with
+ * Random Load/Store Facility Sampling (RIS) in Random sampling mode 
(MMCRA[SM]).
+ */
+EVENT(MEM_ACCESS,  0x10401e0)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 932d7536f0eb..5463516e369b 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -90,6 +90,7 @@ GENERIC_EVENT_ATTR(branch-instructions,   
PM_BRU_FIN);
 GENERIC_EVENT_ATTR(branch-misses,  PM_BR_MPRED_CMPL);
 GENERIC_EVENT_ATTR(cache-references,   PM_LD_REF_L1);
 GENERIC_EVENT_ATTR(cache-misses,   PM_LD_MISS_L1);
+GENERIC_EVENT_ATTR(mem_access, MEM_ACCESS);
 
 CACHE_EVENT_ATTR(L1-dcache-load-misses,PM_LD_MISS_L1);
 CACHE_EVENT_ATTR(L1-dcache-loads,  PM_LD_REF_L1);
@@ -120,6 +121,7 @@ static struct attribute *power8_events_attr[] = {
GENERIC_EVENT_PTR(PM_BR_MPRED_CMPL),
GENERIC_EVENT_PTR(PM_LD_REF_L1),
GENERIC_EVENT_PTR(PM_LD_MISS_L1),
+   GENERIC_EVENT_PTR(MEM_ACCESS),
 
CACHE_EVENT_PTR(PM_LD_MISS_L1),
CACHE_EVENT_PTR(PM_LD_REF_L1),
-- 
2.7.4



[PATCH v3 6/6] powerpc/perf: Add Power8 mem_access event to sysfs

2017-03-22 Thread Madhavan Srinivasan
Patch add "mem_access" event to sysfs. This as-is not a raw event
supported by Power8 pmu. Instead, it is formed based on
raw event encoding specificed in isa207-common.h.

Primary PMU event used here is PM_MRK_INST_CMPL.
This event tracks only the completed marked instructions.

Random sampling mode (MMCRA[SM]) with Random Instruction
Sampling (RIS) is enabled to mark type of instructions.

With Random sampling in RLS mode with PM_MRK_INST_CMPL event,
the LDST /DATA_SRC fields in SIER identifies the memory
hierarchy level (eg: L1, L2 etc) statisfied a data-cache
miss for a marked instruction.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Sukadev Bhattiprolu 
Cc: Daniel Axtens 
Cc: Andrew Donnellan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power8-events-list.h | 6 ++
 arch/powerpc/perf/power8-pmu.c | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/arch/powerpc/perf/power8-events-list.h 
b/arch/powerpc/perf/power8-events-list.h
index 3a2e6e8ebb92..0f1d184627cc 100644
--- a/arch/powerpc/perf/power8-events-list.h
+++ b/arch/powerpc/perf/power8-events-list.h
@@ -89,3 +89,9 @@ EVENT(PM_MRK_FILT_MATCH,  0x2013c)
 EVENT(PM_MRK_FILT_MATCH_ALT,   0x3012e)
 /* Alternate event code for PM_LD_MISS_L1 */
 EVENT(PM_LD_MISS_L1_ALT,   0x400f0)
+/*
+ * Memory Access Event -- mem_access
+ * Primary PMU event used here is PM_MRK_INST_CMPL, along with
+ * Random Load/Store Facility Sampling (RIS) in Random sampling mode 
(MMCRA[SM]).
+ */
+EVENT(MEM_ACCESS,  0x10401e0)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 932d7536f0eb..5463516e369b 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -90,6 +90,7 @@ GENERIC_EVENT_ATTR(branch-instructions,   
PM_BRU_FIN);
 GENERIC_EVENT_ATTR(branch-misses,  PM_BR_MPRED_CMPL);
 GENERIC_EVENT_ATTR(cache-references,   PM_LD_REF_L1);
 GENERIC_EVENT_ATTR(cache-misses,   PM_LD_MISS_L1);
+GENERIC_EVENT_ATTR(mem_access, MEM_ACCESS);
 
 CACHE_EVENT_ATTR(L1-dcache-load-misses,PM_LD_MISS_L1);
 CACHE_EVENT_ATTR(L1-dcache-loads,  PM_LD_REF_L1);
@@ -120,6 +121,7 @@ static struct attribute *power8_events_attr[] = {
GENERIC_EVENT_PTR(PM_BR_MPRED_CMPL),
GENERIC_EVENT_PTR(PM_LD_REF_L1),
GENERIC_EVENT_PTR(PM_LD_MISS_L1),
+   GENERIC_EVENT_PTR(MEM_ACCESS),
 
CACHE_EVENT_PTR(PM_LD_MISS_L1),
CACHE_EVENT_PTR(PM_LD_REF_L1),
-- 
2.7.4



[PATCH v1 RESEND 0/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

2017-03-22 Thread Baoquan He
Now EFI region is mistakenly counted into KASLR VA space for randomization
because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END.
In fact EFI region reserved for runtime services virtual mapping will be
allocated using a top-down schema. It will be reused by kexec/kdump kernel.

So the mistake will cause failure because vmemmap may be randomized to own
EFI region and stomped on the EFI virtual mapping. It's need be fixed.

The original post can be found in below link. And this repost just updated
patch log, no new code change. The patch 1/2 need be added to stabe kernel
after 4.8+.

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1347835.html

Baoquan He (2):
  x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space
for randomization
  x86/efi: Clean up a minor mistake in code comment

 arch/x86/mm/kaslr.c| 4 ++--
 arch/x86/platform/efi/efi_64.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.5.5



[PATCH v1 RESEND 0/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

2017-03-22 Thread Baoquan He
Now EFI region is mistakenly counted into KASLR VA space for randomization
because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END.
In fact EFI region reserved for runtime services virtual mapping will be
allocated using a top-down schema. It will be reused by kexec/kdump kernel.

So the mistake will cause failure because vmemmap may be randomized to own
EFI region and stomped on the EFI virtual mapping. It's need be fixed.

The original post can be found in below link. And this repost just updated
patch log, no new code change. The patch 1/2 need be added to stabe kernel
after 4.8+.

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1347835.html

Baoquan He (2):
  x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space
for randomization
  x86/efi: Clean up a minor mistake in code comment

 arch/x86/mm/kaslr.c| 4 ++--
 arch/x86/platform/efi/efi_64.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.5.5



[PATCH v3 3/6] powerpc/perf: Support to export MMCRA[TEC*] field to userspace

2017-03-22 Thread Madhavan Srinivasan
Threshold feature when used with MMCRA [Threshold Event Counter Event],
MMCRA[Threshold Start event] and MMCRA[Threshold End event] will update
MMCRA[Threashold Event Counter Exponent] and MMCRA[Threshold Event
Counter Multiplier] with the corresponding threshold event count values.
Patch to export MMCRA[TECX/TECM] to userspace in 'weight' field of
struct perf_sample_data.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Thomas Gleixner 
Cc: Sebastian Andrzej Siewior 
Cc: Anna-Maria Gleixner 
Cc: Daniel Axtens 
Cc: Sukadev Bhattiprolu 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/include/asm/perf_event_server.h |  1 +
 arch/powerpc/perf/core-book3s.c  |  4 
 arch/powerpc/perf/isa207-common.c|  8 
 arch/powerpc/perf/isa207-common.h| 10 ++
 4 files changed, 23 insertions(+)

diff --git a/arch/powerpc/include/asm/perf_event_server.h 
b/arch/powerpc/include/asm/perf_event_server.h
index 446cdcd9b7f5..723bf48e7494 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -40,6 +40,7 @@ struct power_pmu {
u64 alt[]);
void(*get_mem_data_src)(union perf_mem_data_src *dsrc,
u32 flags, struct pt_regs *regs);
+   void(*get_mem_weight)(u64 *weight);
u64 (*bhrb_filter_map)(u64 branch_sample_type);
void(*config_bhrb)(u64 pmu_bhrb_filter);
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index e241ebebab6f..6c2d4168daec 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2053,6 +2053,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
ppmu->get_mem_data_src)
ppmu->get_mem_data_src(_src, ppmu->flags, 
regs);
 
+   if (event->attr.sample_type & PERF_SAMPLE_WEIGHT &&
+   ppmu->get_mem_weight)
+   ppmu->get_mem_weight();
+
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
}
diff --git a/arch/powerpc/perf/isa207-common.c 
b/arch/powerpc/perf/isa207-common.c
index 41cc053ee692..292f6a242bb4 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -227,6 +227,14 @@ void isa207_get_mem_data_src(union perf_mem_data_src 
*dsrc, u32 flags,
}
 }
 
+void isa207_get_mem_weight(u64 *weight)
+{
+   u64 mmcra = mfspr(SPRN_MMCRA);
+   u64 exp = MMCRA_THR_CTR_EXP(mmcra);
+   u64 mantissa = MMCRA_THR_CTR_MANT(mmcra);
+
+   *weight = mantissa << (2 * exp);
+}
 
 int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)
 {
diff --git a/arch/powerpc/perf/isa207-common.h 
b/arch/powerpc/perf/isa207-common.h
index 592aa0917cf3..23e0516df4a4 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -248,6 +248,15 @@
 #define MMCRA_SDAR_MODE_TLB(1ull << MMCRA_SDAR_MODE_SHIFT)
 #define MMCRA_SDAR_MODE_NO_UPDATES ~(0x3ull << MMCRA_SDAR_MODE_SHIFT)
 #define MMCRA_IFM_SHIFT30
+#define MMCRA_THR_CTR_MANT_SHIFT   19
+#define MMCRA_THR_CTR_MANT_MASK0x7Ful
+#define MMCRA_THR_CTR_MANT(v)  (((v) >> MMCRA_THR_CTR_MANT_SHIFT) &\
+   MMCRA_THR_CTR_MANT_MASK)
+
+#define MMCRA_THR_CTR_EXP_SHIFT27
+#define MMCRA_THR_CTR_EXP_MASK 0x7ul
+#define MMCRA_THR_CTR_EXP(v)   (((v) >> MMCRA_THR_CTR_EXP_SHIFT) &\
+   MMCRA_THR_CTR_EXP_MASK)
 
 /* MMCR1 Threshold Compare bit constant for power9 */
 #define p9_MMCRA_THR_CMP_SHIFT 45
@@ -282,5 +291,6 @@ int isa207_get_alternatives(u64 event, u64 alt[],
const unsigned int ev_alt[][MAX_ALT], int size);
 void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
struct pt_regs *regs);
+void isa207_get_mem_weight(u64 *weight);
 
 #endif
-- 
2.7.4



[PATCH v3 5/6] powerpc/perf: Support to export SIERs bit in Power9

2017-03-22 Thread Madhavan Srinivasan
Patch to export SIER bits to userspace via
perf_mem_data_src and perf_sample_data struct.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Sukadev Bhattiprolu 
Cc: Daniel Axtens 
Cc: Andrew Donnellan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power9-pmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 7f6582708e06..018f8e90ac35 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -427,6 +427,8 @@ static struct power_pmu power9_pmu = {
.bhrb_filter_map= power9_bhrb_filter_map,
.get_constraint = isa207_get_constraint,
.get_alternatives   = power9_get_alternatives,
+   .get_mem_data_src   = isa207_get_mem_data_src,
+   .get_mem_weight = isa207_get_mem_weight,
.disable_pmc= isa207_disable_pmc,
.flags  = PPMU_HAS_SIER | PPMU_ARCH_207S,
.n_generic  = ARRAY_SIZE(power9_generic_events),
-- 
2.7.4



[PATCH v3 3/6] powerpc/perf: Support to export MMCRA[TEC*] field to userspace

2017-03-22 Thread Madhavan Srinivasan
Threshold feature when used with MMCRA [Threshold Event Counter Event],
MMCRA[Threshold Start event] and MMCRA[Threshold End event] will update
MMCRA[Threashold Event Counter Exponent] and MMCRA[Threshold Event
Counter Multiplier] with the corresponding threshold event count values.
Patch to export MMCRA[TECX/TECM] to userspace in 'weight' field of
struct perf_sample_data.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Thomas Gleixner 
Cc: Sebastian Andrzej Siewior 
Cc: Anna-Maria Gleixner 
Cc: Daniel Axtens 
Cc: Sukadev Bhattiprolu 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/include/asm/perf_event_server.h |  1 +
 arch/powerpc/perf/core-book3s.c  |  4 
 arch/powerpc/perf/isa207-common.c|  8 
 arch/powerpc/perf/isa207-common.h| 10 ++
 4 files changed, 23 insertions(+)

diff --git a/arch/powerpc/include/asm/perf_event_server.h 
b/arch/powerpc/include/asm/perf_event_server.h
index 446cdcd9b7f5..723bf48e7494 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -40,6 +40,7 @@ struct power_pmu {
u64 alt[]);
void(*get_mem_data_src)(union perf_mem_data_src *dsrc,
u32 flags, struct pt_regs *regs);
+   void(*get_mem_weight)(u64 *weight);
u64 (*bhrb_filter_map)(u64 branch_sample_type);
void(*config_bhrb)(u64 pmu_bhrb_filter);
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index e241ebebab6f..6c2d4168daec 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2053,6 +2053,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
ppmu->get_mem_data_src)
ppmu->get_mem_data_src(_src, ppmu->flags, 
regs);
 
+   if (event->attr.sample_type & PERF_SAMPLE_WEIGHT &&
+   ppmu->get_mem_weight)
+   ppmu->get_mem_weight();
+
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
}
diff --git a/arch/powerpc/perf/isa207-common.c 
b/arch/powerpc/perf/isa207-common.c
index 41cc053ee692..292f6a242bb4 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -227,6 +227,14 @@ void isa207_get_mem_data_src(union perf_mem_data_src 
*dsrc, u32 flags,
}
 }
 
+void isa207_get_mem_weight(u64 *weight)
+{
+   u64 mmcra = mfspr(SPRN_MMCRA);
+   u64 exp = MMCRA_THR_CTR_EXP(mmcra);
+   u64 mantissa = MMCRA_THR_CTR_MANT(mmcra);
+
+   *weight = mantissa << (2 * exp);
+}
 
 int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)
 {
diff --git a/arch/powerpc/perf/isa207-common.h 
b/arch/powerpc/perf/isa207-common.h
index 592aa0917cf3..23e0516df4a4 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -248,6 +248,15 @@
 #define MMCRA_SDAR_MODE_TLB(1ull << MMCRA_SDAR_MODE_SHIFT)
 #define MMCRA_SDAR_MODE_NO_UPDATES ~(0x3ull << MMCRA_SDAR_MODE_SHIFT)
 #define MMCRA_IFM_SHIFT30
+#define MMCRA_THR_CTR_MANT_SHIFT   19
+#define MMCRA_THR_CTR_MANT_MASK0x7Ful
+#define MMCRA_THR_CTR_MANT(v)  (((v) >> MMCRA_THR_CTR_MANT_SHIFT) &\
+   MMCRA_THR_CTR_MANT_MASK)
+
+#define MMCRA_THR_CTR_EXP_SHIFT27
+#define MMCRA_THR_CTR_EXP_MASK 0x7ul
+#define MMCRA_THR_CTR_EXP(v)   (((v) >> MMCRA_THR_CTR_EXP_SHIFT) &\
+   MMCRA_THR_CTR_EXP_MASK)
 
 /* MMCR1 Threshold Compare bit constant for power9 */
 #define p9_MMCRA_THR_CMP_SHIFT 45
@@ -282,5 +291,6 @@ int isa207_get_alternatives(u64 event, u64 alt[],
const unsigned int ev_alt[][MAX_ALT], int size);
 void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
struct pt_regs *regs);
+void isa207_get_mem_weight(u64 *weight);
 
 #endif
-- 
2.7.4



[PATCH v3 5/6] powerpc/perf: Support to export SIERs bit in Power9

2017-03-22 Thread Madhavan Srinivasan
Patch to export SIER bits to userspace via
perf_mem_data_src and perf_sample_data struct.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Sukadev Bhattiprolu 
Cc: Daniel Axtens 
Cc: Andrew Donnellan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power9-pmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 7f6582708e06..018f8e90ac35 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -427,6 +427,8 @@ static struct power_pmu power9_pmu = {
.bhrb_filter_map= power9_bhrb_filter_map,
.get_constraint = isa207_get_constraint,
.get_alternatives   = power9_get_alternatives,
+   .get_mem_data_src   = isa207_get_mem_data_src,
+   .get_mem_weight = isa207_get_mem_weight,
.disable_pmc= isa207_disable_pmc,
.flags  = PPMU_HAS_SIER | PPMU_ARCH_207S,
.n_generic  = ARRAY_SIZE(power9_generic_events),
-- 
2.7.4



[PATCH v3 2/6] powerpc/perf: Export memory hierarchy info to user space

2017-03-22 Thread Madhavan Srinivasan
The LDST field and DATA_SRC in SIER identifies the memory hierarchy level
(eg: L1, L2 etc), from which a data-cache miss for a marked instruction
was satisfied. Use the 'perf_mem_data_src' object to export this
hierarchy level to user space.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Thomas Gleixner 
Cc: Sebastian Andrzej Siewior 
Cc: Anna-Maria Gleixner 
Cc: Daniel Axtens 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Madhavan Srinivasan 
---
Changelog v2:
- Fixed isa207_find_source() to consider all the possible sier[ldst] values.


 arch/powerpc/include/asm/perf_event_server.h |  2 +
 arch/powerpc/perf/core-book3s.c  |  4 ++
 arch/powerpc/perf/isa207-common.c| 80 
 arch/powerpc/perf/isa207-common.h| 16 +-
 4 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/perf_event_server.h 
b/arch/powerpc/include/asm/perf_event_server.h
index ae0a23091a9b..446cdcd9b7f5 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -38,6 +38,8 @@ struct power_pmu {
unsigned long *valp);
int (*get_alternatives)(u64 event_id, unsigned int flags,
u64 alt[]);
+   void(*get_mem_data_src)(union perf_mem_data_src *dsrc,
+   u32 flags, struct pt_regs *regs);
u64 (*bhrb_filter_map)(u64 branch_sample_type);
void(*config_bhrb)(u64 pmu_bhrb_filter);
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 2ff13249f87a..e241ebebab6f 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2049,6 +2049,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
data.br_stack = >bhrb_stack;
}
 
+   if (event->attr.sample_type & PERF_SAMPLE_DATA_SRC &&
+   ppmu->get_mem_data_src)
+   ppmu->get_mem_data_src(_src, ppmu->flags, 
regs);
+
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
}
diff --git a/arch/powerpc/perf/isa207-common.c 
b/arch/powerpc/perf/isa207-common.c
index cd951fd231c4..41cc053ee692 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -148,6 +148,86 @@ static bool is_thresh_cmp_valid(u64 event)
return true;
 }
 
+static inline u64 isa207_find_source(u64 idx, u32 sub_idx)
+{
+   u64 ret = PERF_MEM_NA;
+
+   switch(idx) {
+   case 0:
+   /* Nothing to do */
+   break;
+   case 1:
+   ret = PLH(LVL, L1);
+   break;
+   case 2:
+   ret = PLH(LVL, L2);
+   break;
+   case 3:
+   ret = PLH(LVL, L3);
+   break;
+   case 4:
+   if (sub_idx <= 1)
+   ret = PLH(LVL, LOC_RAM);
+   else if (sub_idx > 1 && sub_idx <= 2)
+   ret = PLH(LVL, REM_RAM1);
+   else
+   ret = PLH(LVL, REM_RAM2);
+   ret |= P(SNOOP, HIT);
+   break;
+   case 5:
+   ret = PLH(LVL, REM_CCE1);
+   if ((sub_idx == 0) || (sub_idx == 2) || (sub_idx == 4))
+   ret |= P(SNOOP, HIT);
+   else if ((sub_idx == 1) || (sub_idx == 3) || (sub_idx == 5))
+   ret |= P(SNOOP, HITM);
+   break;
+   case 6:
+   ret = PLH(LVL, REM_CCE2);
+   if ((sub_idx == 0) || (sub_idx == 2))
+   ret |= P(SNOOP, HIT);
+   else if ((sub_idx == 1) || (sub_idx == 3))
+   ret |= P(SNOOP, HITM);
+   break;
+   case 7:
+   ret = PSM(LVL, L1);
+   break;
+   }
+
+   return ret;
+}
+
+static inline bool is_load_store_inst(u64 sier)
+{
+   u64 val;
+   val = (sier & ISA207_SIER_TYPE_MASK) >> ISA207_SIER_TYPE_SHIFT;
+
+   /* 1 = load, 2 = store */
+   return val == 1 || val == 2;
+}
+
+void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
+   struct pt_regs *regs)
+{
+ 

[PATCH v3 4/6] powerpc/perf: Support to export SIERs bit in Power8

2017-03-22 Thread Madhavan Srinivasan
Patch to export SIER bits to userspace via
perf_mem_data_src and perf_sample_data struct.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Daniel Axtens 
Cc: Andrew Donnellan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power8-pmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index ce15b19a7962..932d7536f0eb 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -325,6 +325,8 @@ static struct power_pmu power8_pmu = {
.bhrb_filter_map= power8_bhrb_filter_map,
.get_constraint = isa207_get_constraint,
.get_alternatives   = power8_get_alternatives,
+   .get_mem_data_src   = isa207_get_mem_data_src,
+   .get_mem_weight = isa207_get_mem_weight,
.disable_pmc= isa207_disable_pmc,
.flags  = PPMU_HAS_SIER | PPMU_ARCH_207S,
.n_generic  = ARRAY_SIZE(power8_generic_events),
-- 
2.7.4



[PATCH v3 2/6] powerpc/perf: Export memory hierarchy info to user space

2017-03-22 Thread Madhavan Srinivasan
The LDST field and DATA_SRC in SIER identifies the memory hierarchy level
(eg: L1, L2 etc), from which a data-cache miss for a marked instruction
was satisfied. Use the 'perf_mem_data_src' object to export this
hierarchy level to user space.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Thomas Gleixner 
Cc: Sebastian Andrzej Siewior 
Cc: Anna-Maria Gleixner 
Cc: Daniel Axtens 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Madhavan Srinivasan 
---
Changelog v2:
- Fixed isa207_find_source() to consider all the possible sier[ldst] values.


 arch/powerpc/include/asm/perf_event_server.h |  2 +
 arch/powerpc/perf/core-book3s.c  |  4 ++
 arch/powerpc/perf/isa207-common.c| 80 
 arch/powerpc/perf/isa207-common.h| 16 +-
 4 files changed, 101 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/perf_event_server.h 
b/arch/powerpc/include/asm/perf_event_server.h
index ae0a23091a9b..446cdcd9b7f5 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -38,6 +38,8 @@ struct power_pmu {
unsigned long *valp);
int (*get_alternatives)(u64 event_id, unsigned int flags,
u64 alt[]);
+   void(*get_mem_data_src)(union perf_mem_data_src *dsrc,
+   u32 flags, struct pt_regs *regs);
u64 (*bhrb_filter_map)(u64 branch_sample_type);
void(*config_bhrb)(u64 pmu_bhrb_filter);
void(*disable_pmc)(unsigned int pmc, unsigned long mmcr[]);
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 2ff13249f87a..e241ebebab6f 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2049,6 +2049,10 @@ static void record_and_restart(struct perf_event *event, 
unsigned long val,
data.br_stack = >bhrb_stack;
}
 
+   if (event->attr.sample_type & PERF_SAMPLE_DATA_SRC &&
+   ppmu->get_mem_data_src)
+   ppmu->get_mem_data_src(_src, ppmu->flags, 
regs);
+
if (perf_event_overflow(event, , regs))
power_pmu_stop(event, 0);
}
diff --git a/arch/powerpc/perf/isa207-common.c 
b/arch/powerpc/perf/isa207-common.c
index cd951fd231c4..41cc053ee692 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -148,6 +148,86 @@ static bool is_thresh_cmp_valid(u64 event)
return true;
 }
 
+static inline u64 isa207_find_source(u64 idx, u32 sub_idx)
+{
+   u64 ret = PERF_MEM_NA;
+
+   switch(idx) {
+   case 0:
+   /* Nothing to do */
+   break;
+   case 1:
+   ret = PLH(LVL, L1);
+   break;
+   case 2:
+   ret = PLH(LVL, L2);
+   break;
+   case 3:
+   ret = PLH(LVL, L3);
+   break;
+   case 4:
+   if (sub_idx <= 1)
+   ret = PLH(LVL, LOC_RAM);
+   else if (sub_idx > 1 && sub_idx <= 2)
+   ret = PLH(LVL, REM_RAM1);
+   else
+   ret = PLH(LVL, REM_RAM2);
+   ret |= P(SNOOP, HIT);
+   break;
+   case 5:
+   ret = PLH(LVL, REM_CCE1);
+   if ((sub_idx == 0) || (sub_idx == 2) || (sub_idx == 4))
+   ret |= P(SNOOP, HIT);
+   else if ((sub_idx == 1) || (sub_idx == 3) || (sub_idx == 5))
+   ret |= P(SNOOP, HITM);
+   break;
+   case 6:
+   ret = PLH(LVL, REM_CCE2);
+   if ((sub_idx == 0) || (sub_idx == 2))
+   ret |= P(SNOOP, HIT);
+   else if ((sub_idx == 1) || (sub_idx == 3))
+   ret |= P(SNOOP, HITM);
+   break;
+   case 7:
+   ret = PSM(LVL, L1);
+   break;
+   }
+
+   return ret;
+}
+
+static inline bool is_load_store_inst(u64 sier)
+{
+   u64 val;
+   val = (sier & ISA207_SIER_TYPE_MASK) >> ISA207_SIER_TYPE_SHIFT;
+
+   /* 1 = load, 2 = store */
+   return val == 1 || val == 2;
+}
+
+void isa207_get_mem_data_src(union perf_mem_data_src *dsrc, u32 flags,
+   struct pt_regs *regs)
+{
+   u64 idx;
+   u32 sub_idx;
+   u64 sier;
+
+   /* Skip if no SIER support */
+   if (!(flags & PPMU_HAS_SIER)) {
+   dsrc->val = 0;
+   return;
+   }
+
+   sier = mfspr(SPRN_SIER);
+   if (is_load_store_inst(sier)) {
+   idx = (sier & ISA207_SIER_LDST_MASK) >> 

[PATCH v3 4/6] powerpc/perf: Support to export SIERs bit in Power8

2017-03-22 Thread Madhavan Srinivasan
Patch to export SIER bits to userspace via
perf_mem_data_src and perf_sample_data struct.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Daniel Axtens 
Cc: Andrew Donnellan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/perf/power8-pmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index ce15b19a7962..932d7536f0eb 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -325,6 +325,8 @@ static struct power_pmu power8_pmu = {
.bhrb_filter_map= power8_bhrb_filter_map,
.get_constraint = isa207_get_constraint,
.get_alternatives   = power8_get_alternatives,
+   .get_mem_data_src   = isa207_get_mem_data_src,
+   .get_mem_weight = isa207_get_mem_weight,
.disable_pmc= isa207_disable_pmc,
.flags  = PPMU_HAS_SIER | PPMU_ARCH_207S,
.n_generic  = ARRAY_SIZE(power8_generic_events),
-- 
2.7.4



[PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

2017-03-22 Thread Madhavan Srinivasan
From: Sukadev Bhattiprolu 

perf_mem_data_src is an union that is initialized via the ->val field
and accessed via the bitmap fields. For this to work on big endian
platforms (Which is broken now), we also need a big-endian represenation
of perf_mem_data_src. i.e, in a big endian system, if user request
PERF_SAMPLE_DATA_SRC (perf report -d), will get the default value from
perf_sample_data_init(), which is PERF_MEM_NA. Value for PERF_MEM_NA
is constructed using shifts:

  /* TLB access */
  #define PERF_MEM_TLB_NA   0x01 /* not available */
  ...
  #define PERF_MEM_TLB_SHIFT26

  #define PERF_MEM_S(a, s) \
(((__u64)PERF_MEM_##a##_##s) << PERF_MEM_##a##_SHIFT)

  #define PERF_MEM_NA (PERF_MEM_S(OP, NA)   |\
PERF_MEM_S(LVL, NA)   |\
PERF_MEM_S(SNOOP, NA) |\
PERF_MEM_S(LOCK, NA)  |\
PERF_MEM_S(TLB, NA))

Which works out as:

  ((0x01 << 0) | (0x01 << 5) | (0x01 << 19) | (0x01 << 24) | (0x01 << 26))

Which means the PERF_MEM_NA value comes out of the kernel as 0x5080021
in CPU endian.

But then in the perf tool, the code uses the bitfields to inspect the
value, and currently the bitfields are defined using little endian
ordering.

So eg. in perf_mem__tlb_scnprintf() we see:
  data_src->val = 0x5080021
 op = 0x0
lvl = 0x0
  snoop = 0x0
   lock = 0x0
   dtlb = 0x0
   rsvd = 0x5080021

Patch does a minimal fix of adding big endian definition of the bitfields
to match the values that are already exported by the kernel on big endian.
And it makes no change on little endian.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Madhavan Srinivasan 
---
Changelog v2:
-Added Michael Ellerman's explanation to comiit message.
Changelog v1:
-Fixed author-ship and added suka's "Signed-off-by:".

 include/uapi/linux/perf_event.h   | 16 
 tools/include/uapi/linux/perf_event.h | 16 
 2 files changed, 32 insertions(+)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index c66a485a24ac..c4af1159a200 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -891,6 +891,7 @@ enum perf_callchain_context {
 #define PERF_FLAG_PID_CGROUP   (1UL << 2) /* pid=cgroup id, per-cpu 
mode only */
 #define PERF_FLAG_FD_CLOEXEC   (1UL << 3) /* O_CLOEXEC */
 
+#if defined(__LITTLE_ENDIAN_BITFIELD)
 union perf_mem_data_src {
__u64 val;
struct {
@@ -902,6 +903,21 @@ union perf_mem_data_src {
mem_rsvd:31;
};
 };
+#elif defined(__BIG_ENDIAN_BITFIELD)
+union perf_mem_data_src {
+   __u64 val;
+   struct {
+   __u64   mem_rsvd:31,
+   mem_dtlb:7, /* tlb access */
+   mem_lock:2, /* lock instr */
+   mem_snoop:5,/* snoop mode */
+   mem_lvl:14, /* memory hierarchy level */
+   mem_op:5;   /* type of opcode */
+   };
+};
+#else
+#error "Unknown endianness"
+#endif
 
 /* type of opcode (load/store/prefetch,code) */
 #define PERF_MEM_OP_NA 0x01 /* not available */
diff --git a/tools/include/uapi/linux/perf_event.h 
b/tools/include/uapi/linux/perf_event.h
index c66a485a24ac..c4af1159a200 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -891,6 +891,7 @@ enum perf_callchain_context {
 #define PERF_FLAG_PID_CGROUP   (1UL << 2) /* pid=cgroup id, per-cpu 
mode only */
 #define PERF_FLAG_FD_CLOEXEC   (1UL << 3) /* O_CLOEXEC */
 
+#if defined(__LITTLE_ENDIAN_BITFIELD)
 union perf_mem_data_src {
__u64 val;
struct {
@@ -902,6 +903,21 @@ union perf_mem_data_src {
mem_rsvd:31;
};
 };
+#elif defined(__BIG_ENDIAN_BITFIELD)
+union perf_mem_data_src {
+   __u64 val;
+   struct {
+   __u64   mem_rsvd:31,
+   mem_dtlb:7, /* tlb access */
+   mem_lock:2, /* lock instr */
+   mem_snoop:5,/* snoop mode */
+   mem_lvl:14, /* memory hierarchy level */
+   mem_op:5;   /* type of opcode */
+   };
+};
+#else
+#error "Unknown endianness"
+#endif
 
 /* type of opcode (load/store/prefetch,code) */
 #define PERF_MEM_OP_NA 0x01 /* not available */
-- 
2.7.4



[PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

2017-03-22 Thread Madhavan Srinivasan
From: Sukadev Bhattiprolu 

perf_mem_data_src is an union that is initialized via the ->val field
and accessed via the bitmap fields. For this to work on big endian
platforms (Which is broken now), we also need a big-endian represenation
of perf_mem_data_src. i.e, in a big endian system, if user request
PERF_SAMPLE_DATA_SRC (perf report -d), will get the default value from
perf_sample_data_init(), which is PERF_MEM_NA. Value for PERF_MEM_NA
is constructed using shifts:

  /* TLB access */
  #define PERF_MEM_TLB_NA   0x01 /* not available */
  ...
  #define PERF_MEM_TLB_SHIFT26

  #define PERF_MEM_S(a, s) \
(((__u64)PERF_MEM_##a##_##s) << PERF_MEM_##a##_SHIFT)

  #define PERF_MEM_NA (PERF_MEM_S(OP, NA)   |\
PERF_MEM_S(LVL, NA)   |\
PERF_MEM_S(SNOOP, NA) |\
PERF_MEM_S(LOCK, NA)  |\
PERF_MEM_S(TLB, NA))

Which works out as:

  ((0x01 << 0) | (0x01 << 5) | (0x01 << 19) | (0x01 << 24) | (0x01 << 26))

Which means the PERF_MEM_NA value comes out of the kernel as 0x5080021
in CPU endian.

But then in the perf tool, the code uses the bitfields to inspect the
value, and currently the bitfields are defined using little endian
ordering.

So eg. in perf_mem__tlb_scnprintf() we see:
  data_src->val = 0x5080021
 op = 0x0
lvl = 0x0
  snoop = 0x0
   lock = 0x0
   dtlb = 0x0
   rsvd = 0x5080021

Patch does a minimal fix of adding big endian definition of the bitfields
to match the values that are already exported by the kernel on big endian.
And it makes no change on little endian.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Wang Nan 
Cc: Alexei Starovoitov 
Cc: Stephane Eranian 
Signed-off-by: Sukadev Bhattiprolu 
Signed-off-by: Madhavan Srinivasan 
---
Changelog v2:
-Added Michael Ellerman's explanation to comiit message.
Changelog v1:
-Fixed author-ship and added suka's "Signed-off-by:".

 include/uapi/linux/perf_event.h   | 16 
 tools/include/uapi/linux/perf_event.h | 16 
 2 files changed, 32 insertions(+)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index c66a485a24ac..c4af1159a200 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -891,6 +891,7 @@ enum perf_callchain_context {
 #define PERF_FLAG_PID_CGROUP   (1UL << 2) /* pid=cgroup id, per-cpu 
mode only */
 #define PERF_FLAG_FD_CLOEXEC   (1UL << 3) /* O_CLOEXEC */
 
+#if defined(__LITTLE_ENDIAN_BITFIELD)
 union perf_mem_data_src {
__u64 val;
struct {
@@ -902,6 +903,21 @@ union perf_mem_data_src {
mem_rsvd:31;
};
 };
+#elif defined(__BIG_ENDIAN_BITFIELD)
+union perf_mem_data_src {
+   __u64 val;
+   struct {
+   __u64   mem_rsvd:31,
+   mem_dtlb:7, /* tlb access */
+   mem_lock:2, /* lock instr */
+   mem_snoop:5,/* snoop mode */
+   mem_lvl:14, /* memory hierarchy level */
+   mem_op:5;   /* type of opcode */
+   };
+};
+#else
+#error "Unknown endianness"
+#endif
 
 /* type of opcode (load/store/prefetch,code) */
 #define PERF_MEM_OP_NA 0x01 /* not available */
diff --git a/tools/include/uapi/linux/perf_event.h 
b/tools/include/uapi/linux/perf_event.h
index c66a485a24ac..c4af1159a200 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -891,6 +891,7 @@ enum perf_callchain_context {
 #define PERF_FLAG_PID_CGROUP   (1UL << 2) /* pid=cgroup id, per-cpu 
mode only */
 #define PERF_FLAG_FD_CLOEXEC   (1UL << 3) /* O_CLOEXEC */
 
+#if defined(__LITTLE_ENDIAN_BITFIELD)
 union perf_mem_data_src {
__u64 val;
struct {
@@ -902,6 +903,21 @@ union perf_mem_data_src {
mem_rsvd:31;
};
 };
+#elif defined(__BIG_ENDIAN_BITFIELD)
+union perf_mem_data_src {
+   __u64 val;
+   struct {
+   __u64   mem_rsvd:31,
+   mem_dtlb:7, /* tlb access */
+   mem_lock:2, /* lock instr */
+   mem_snoop:5,/* snoop mode */
+   mem_lvl:14, /* memory hierarchy level */
+   mem_op:5;   /* type of opcode */
+   };
+};
+#else
+#error "Unknown endianness"
+#endif
 
 /* type of opcode (load/store/prefetch,code) */
 #define PERF_MEM_OP_NA 0x01 /* not available */
-- 
2.7.4



[PATCH v3 0/6] powerpc/perf: Export memory hierarchy level

2017-03-22 Thread Madhavan Srinivasan
Power8/Power9 Perforence Monitoring Unit (PMU) supports
different sampling modes (SM) such as Random Instruction
Sampling (RIS), Random Load/Store Facility Sampling (RLS)
and Random Branch Sampling (RBS). Sample mode RLS updates
Sampled Instruction Event Register [SIER] bits with memory
hierarchy information for a cache reload. Patchset exports
the hierarchy information to the user via the perf_mem_data_src
object from SIER.

Patchset is a rebase of the work posted previously with minor
updates to it.

https://lkml.org/lkml/2015/6/11/92

Changelog v2:
-Updated the commit messages
-Fixed isa207_find_source() to consider all the possible sier[ldst] values.

Changelog v1:
- Fixed author-ship for the first patch and added suka's "Signed-off-by:".

Madhavan Srinivasan (5):
  powerpc/perf: Export memory hierarchy info to user space
  powerpc/perf: Support to export MMCRA[TEC*] field to userspace
  powerpc/perf: Support to export SIERs bit in Power8
  powerpc/perf: Support to export SIERs bit in Power9
  powerpc/perf: Add Power8 mem_access event to sysfs

Sukadev Bhattiprolu (1):
  powerpc/perf: Define big-endian version of perf_mem_data_src

 arch/powerpc/include/asm/perf_event_server.h |  3 +
 arch/powerpc/perf/core-book3s.c  |  8 +++
 arch/powerpc/perf/isa207-common.c| 88 
 arch/powerpc/perf/isa207-common.h| 26 +++-
 arch/powerpc/perf/power8-events-list.h   |  6 ++
 arch/powerpc/perf/power8-pmu.c   |  4 ++
 arch/powerpc/perf/power9-pmu.c   |  2 +
 include/uapi/linux/perf_event.h  | 16 +
 tools/include/uapi/linux/perf_event.h| 16 +
 9 files changed, 168 insertions(+), 1 deletion(-)

-- 
2.7.4



[PATCH v3 0/6] powerpc/perf: Export memory hierarchy level

2017-03-22 Thread Madhavan Srinivasan
Power8/Power9 Perforence Monitoring Unit (PMU) supports
different sampling modes (SM) such as Random Instruction
Sampling (RIS), Random Load/Store Facility Sampling (RLS)
and Random Branch Sampling (RBS). Sample mode RLS updates
Sampled Instruction Event Register [SIER] bits with memory
hierarchy information for a cache reload. Patchset exports
the hierarchy information to the user via the perf_mem_data_src
object from SIER.

Patchset is a rebase of the work posted previously with minor
updates to it.

https://lkml.org/lkml/2015/6/11/92

Changelog v2:
-Updated the commit messages
-Fixed isa207_find_source() to consider all the possible sier[ldst] values.

Changelog v1:
- Fixed author-ship for the first patch and added suka's "Signed-off-by:".

Madhavan Srinivasan (5):
  powerpc/perf: Export memory hierarchy info to user space
  powerpc/perf: Support to export MMCRA[TEC*] field to userspace
  powerpc/perf: Support to export SIERs bit in Power8
  powerpc/perf: Support to export SIERs bit in Power9
  powerpc/perf: Add Power8 mem_access event to sysfs

Sukadev Bhattiprolu (1):
  powerpc/perf: Define big-endian version of perf_mem_data_src

 arch/powerpc/include/asm/perf_event_server.h |  3 +
 arch/powerpc/perf/core-book3s.c  |  8 +++
 arch/powerpc/perf/isa207-common.c| 88 
 arch/powerpc/perf/isa207-common.h| 26 +++-
 arch/powerpc/perf/power8-events-list.h   |  6 ++
 arch/powerpc/perf/power8-pmu.c   |  4 ++
 arch/powerpc/perf/power9-pmu.c   |  2 +
 include/uapi/linux/perf_event.h  | 16 +
 tools/include/uapi/linux/perf_event.h| 16 +
 9 files changed, 168 insertions(+), 1 deletion(-)

-- 
2.7.4



Re: [PATCH] Documentation: Input: Add uinput documentation

2017-03-22 Thread Peter Hutterer
On Wed, Mar 22, 2017 at 11:54:48PM -0300, Marcos Paulo de Souza wrote:
> Hi Peter,
> 
> first of all, thanks a lot for reading this patch so quickly and to
> point a lot of things to make this doc way better.
> 
> See some notes below.

thanks for all the fixes, much appreciated.
just two comments below:

> On Wed, Mar 22, 2017 at 02:03:31PM +1000, Peter Hutterer wrote:
[...]
> > > +memset(, 0, sizeof(ie));
> > > +ie.type = type;
> > > +ie.code = code;
> > > +ie.value = val;
> > > +
> > 
> > memset followed by three out of five filled in seems strange. Just add
> >   ie.time.tv_sec = 0;
> >   ie.time.tv_usec = 0;
> > 
> > ideally, with a comment that states that the timestamp is ignored :)
> 
> All the code in this doc is the result of my tests using uinput, so
> somethings were set in my code some time ago and were never touched
> again. Yes, this makes things a way better :)

note that if we ship this as documentation, these become the official
examples so they *have* to be correct. How many times have you copied
something from the examples of a library? Not ideal if there's a bug or just
messy code to begin with :)

> I fixed a lot of things today, the things that are still missing are the
> libevdev example, and the version check. I do think that I can send a
> new version tomorrow.

As for libevdev: just add a link to the documentation, don't add a libevdev
example. libevdev should (and does) provide the examples and you don't want
to ship example code that relies on some other library' API.

Cheers,
   Peter


Re: [PATCH] Documentation: Input: Add uinput documentation

2017-03-22 Thread Peter Hutterer
On Wed, Mar 22, 2017 at 11:54:48PM -0300, Marcos Paulo de Souza wrote:
> Hi Peter,
> 
> first of all, thanks a lot for reading this patch so quickly and to
> point a lot of things to make this doc way better.
> 
> See some notes below.

thanks for all the fixes, much appreciated.
just two comments below:

> On Wed, Mar 22, 2017 at 02:03:31PM +1000, Peter Hutterer wrote:
[...]
> > > +memset(, 0, sizeof(ie));
> > > +ie.type = type;
> > > +ie.code = code;
> > > +ie.value = val;
> > > +
> > 
> > memset followed by three out of five filled in seems strange. Just add
> >   ie.time.tv_sec = 0;
> >   ie.time.tv_usec = 0;
> > 
> > ideally, with a comment that states that the timestamp is ignored :)
> 
> All the code in this doc is the result of my tests using uinput, so
> somethings were set in my code some time ago and were never touched
> again. Yes, this makes things a way better :)

note that if we ship this as documentation, these become the official
examples so they *have* to be correct. How many times have you copied
something from the examples of a library? Not ideal if there's a bug or just
messy code to begin with :)

> I fixed a lot of things today, the things that are still missing are the
> libevdev example, and the version check. I do think that I can send a
> new version tomorrow.

As for libevdev: just add a link to the documentation, don't add a libevdev
example. libevdev should (and does) provide the examples and you don't want
to ship example code that relies on some other library' API.

Cheers,
   Peter


Re: [PATCH 3/6] ftrace/x86_32: Add stack frame pointer to ftrace_caller

2017-03-22 Thread Masami Hiramatsu
On Tue, 21 Mar 2017 21:35:05 -0400
Steven Rostedt  wrote:

> From: "Steven Rostedt (VMware)" 
> 
> The function hook ftrace_caller does not create its own stack frame, and
> this causes the ftrace stack trace to miss the first function when doing
> stack traces.
> 
>  # echo schedule:stacktrace > /sys/kernel/tracing/set_ftrace_filter
> 
> Before:
>  -0 [002] .N..29.865807: 
>  => cpu_startup_entry
>  => start_secondary
>  => startup_32_smp
><...>-7 [001] 29.866509: 
>  => kthread
>  => ret_from_fork
><...>-1 [000] 29.865377: 
>  => poll_schedule_timeout
>  => do_select
>  => core_sys_select
>  => SyS_select
>  => do_fast_syscall_32
>  => entry_SYSENTER_32
> 
> After:
>   -0 [002] .N..31.234853: 
>  => do_idle
>  => cpu_startup_entry
>  => start_secondary
>  => startup_32_smp
><...>-7 [003] 31.235140: 
>  => rcu_gp_kthread
>  => kthread
>  => ret_from_fork
><...>-1819  [000] 31.264172: 
>  => schedule_hrtimeout_range
>  => poll_schedule_timeout
>  => do_sys_poll
>  => SyS_ppoll
>  => do_fast_syscall_32
>  => entry_SYSENTER_32
> 

Looks good to me.

Reviewed-by: Masami Hiramatsu 

Thank you,

> Reviewed-by: Josh Poimboeuf 
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  arch/x86/kernel/ftrace_32.S | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
> index 1889a74823ce..f991e723c3e4 100644
> --- a/arch/x86/kernel/ftrace_32.S
> +++ b/arch/x86/kernel/ftrace_32.S
> @@ -18,12 +18,19 @@ ENTRY(mcount)
>  END(mcount)
>  
>  ENTRY(ftrace_caller)
> +
> + pushl   %ebp
> + movl%esp, %ebp
> +
>   pushl   %eax
>   pushl   %ecx
>   pushl   %edx
>   pushl   $0  /* Pass NULL as regs pointer */
> - movl4*4(%esp), %eax
> - movl0x4(%ebp), %edx
> + movl5*4(%esp), %eax
> + /* Copy original ebp into %edx */
> + movl4*4(%esp), %edx
> + /* Get the parent ip */
> + movl0x4(%edx), %edx
>   movlfunction_trace_op, %ecx
>   subl$MCOUNT_INSN_SIZE, %eax
>  
> @@ -35,6 +42,7 @@ ftrace_call:
>   popl%edx
>   popl%ecx
>   popl%eax
> + popl%ebp
>  .Lftrace_ret:
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>  .globl ftrace_graph_call
> -- 
> 2.10.2
> 
> 


-- 
Masami Hiramatsu 


Re: [PATCH 3/6] ftrace/x86_32: Add stack frame pointer to ftrace_caller

2017-03-22 Thread Masami Hiramatsu
On Tue, 21 Mar 2017 21:35:05 -0400
Steven Rostedt  wrote:

> From: "Steven Rostedt (VMware)" 
> 
> The function hook ftrace_caller does not create its own stack frame, and
> this causes the ftrace stack trace to miss the first function when doing
> stack traces.
> 
>  # echo schedule:stacktrace > /sys/kernel/tracing/set_ftrace_filter
> 
> Before:
>  -0 [002] .N..29.865807: 
>  => cpu_startup_entry
>  => start_secondary
>  => startup_32_smp
><...>-7 [001] 29.866509: 
>  => kthread
>  => ret_from_fork
><...>-1 [000] 29.865377: 
>  => poll_schedule_timeout
>  => do_select
>  => core_sys_select
>  => SyS_select
>  => do_fast_syscall_32
>  => entry_SYSENTER_32
> 
> After:
>   -0 [002] .N..31.234853: 
>  => do_idle
>  => cpu_startup_entry
>  => start_secondary
>  => startup_32_smp
><...>-7 [003] 31.235140: 
>  => rcu_gp_kthread
>  => kthread
>  => ret_from_fork
><...>-1819  [000] 31.264172: 
>  => schedule_hrtimeout_range
>  => poll_schedule_timeout
>  => do_sys_poll
>  => SyS_ppoll
>  => do_fast_syscall_32
>  => entry_SYSENTER_32
> 

Looks good to me.

Reviewed-by: Masami Hiramatsu 

Thank you,

> Reviewed-by: Josh Poimboeuf 
> Signed-off-by: Steven Rostedt (VMware) 
> ---
>  arch/x86/kernel/ftrace_32.S | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
> index 1889a74823ce..f991e723c3e4 100644
> --- a/arch/x86/kernel/ftrace_32.S
> +++ b/arch/x86/kernel/ftrace_32.S
> @@ -18,12 +18,19 @@ ENTRY(mcount)
>  END(mcount)
>  
>  ENTRY(ftrace_caller)
> +
> + pushl   %ebp
> + movl%esp, %ebp
> +
>   pushl   %eax
>   pushl   %ecx
>   pushl   %edx
>   pushl   $0  /* Pass NULL as regs pointer */
> - movl4*4(%esp), %eax
> - movl0x4(%ebp), %edx
> + movl5*4(%esp), %eax
> + /* Copy original ebp into %edx */
> + movl4*4(%esp), %edx
> + /* Get the parent ip */
> + movl0x4(%edx), %edx
>   movlfunction_trace_op, %ecx
>   subl$MCOUNT_INSN_SIZE, %eax
>  
> @@ -35,6 +42,7 @@ ftrace_call:
>   popl%edx
>   popl%ecx
>   popl%eax
> + popl%ebp
>  .Lftrace_ret:
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>  .globl ftrace_graph_call
> -- 
> 2.10.2
> 
> 


-- 
Masami Hiramatsu 


Re: [PATCH 4/4] zram: make deduplication feature optional

2017-03-22 Thread Joonsoo Kim
On Wed, Mar 22, 2017 at 09:00:59AM +0900, Minchan Kim wrote:
> On Thu, Mar 16, 2017 at 11:46:38AM +0900, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> > 
> > Benefit of deduplication is dependent on the workload so it's not
> > preferable to always enable. Therefore, make it optional.
> 
> Please make it to Kconfig, too. And write down the description to impress
> "help a lot for users who uses zram to build output directory"
> And the feature should be disabled as default.

Okay.

> 
> > 
> > Signed-off-by: Joonsoo Kim 
> > ---
> >  drivers/block/zram/zram_drv.c | 80 
> > ++-
> >  drivers/block/zram/zram_drv.h |  1 +
> >  2 files changed, 73 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index 012425f..e45aa9f 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -328,6 +328,39 @@ static ssize_t comp_algorithm_store(struct device *dev,
> > return len;
> >  }
> >  
> > +static ssize_t use_dedup_show(struct device *dev,
> > +   struct device_attribute *attr, char *buf)
> > +{
> > +   int val;
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   down_read(>init_lock);
> > +   val = zram->use_dedup;
> > +   up_read(>init_lock);
> > +
> > +   return scnprintf(buf, PAGE_SIZE, "%d\n", val);
> > +}
> > +
> > +static ssize_t use_dedup_store(struct device *dev,
> > +   struct device_attribute *attr, const char *buf, size_t len)
> > +{
> > +   int val;
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   if (kstrtoint(buf, 10, ) || (val != 0 && val != 1))
> > +   return -EINVAL;
> > +
> > +   down_write(>init_lock);
> > +   if (init_done(zram)) {
> > +   up_write(>init_lock);
> > +   pr_info("Can't change dedup usage for initialized device\n");
> > +   return -EBUSY;
> > +   }
> > +   zram->use_dedup = val;
> > +   up_write(>init_lock);
> > +   return len;
> > +}
> > +
> >  static ssize_t compact_store(struct device *dev,
> > struct device_attribute *attr, const char *buf, size_t len)
> >  {
> > @@ -422,11 +455,23 @@ static ssize_t debug_stat_show(struct device *dev,
> >  static DEVICE_ATTR_RO(mm_stat);
> >  static DEVICE_ATTR_RO(debug_stat);
> >  
> > -static u32 zram_calc_checksum(unsigned char *mem)
> > +static u32 zram_calc_checksum(struct zram *zram, unsigned char *mem)
> >  {
> > +   if (!zram->use_dedup)
> > +   return 0;
> > +
> 
> Hmm, I don't like this style which every dedup functions have the check
> "use_dedup".
> 
> Can't we abstract like this?

I will try but I'm not sure it can be.

> 
> I want to find more simple way to no need to add the check when new dedup
> functions pop up.
> 
> bool zram_dedup_check
> if (!zram->dedup)
> return false;
> 
> zram_dedup_checksum
> entry = zram_dedup_get
> if (!entry) {
> zram_dedup_add
> return false;
> }
> ..
> return true;
> 
> 
> zram_bvec_write:
> ...
> ...
> 
> if (zram_dedup_match())
> goto found_dup;
> 
> 
> 
> > return jhash(mem, PAGE_SIZE, 0);
> >  }
> >  
> > +static unsigned long zram_entry_handle(struct zram *zram,
> > +   struct zram_entry *entry)
> > +{
> > +   if (!zram->use_dedup)
> > +   return (unsigned long)entry;
> > +
> > +   return entry->handle;
> > +}
> > +
> >  static struct zram_entry *zram_entry_alloc(struct zram *zram,
> > unsigned int len, gfp_t flags)
> >  {
> > @@ -438,6 +483,9 @@ static struct zram_entry *zram_entry_alloc(struct zram 
> > *zram,
> > if (!handle)
> > return NULL;
> >  
> > +   if (!zram->use_dedup)
> > +   return (struct zram_entry *)handle;
> > +
> > entry = kzalloc(sizeof(*entry), flags);
> > if (!entry) {
> > zs_free(meta->mem_pool, handle);
> > @@ -462,6 +510,9 @@ static void zram_entry_insert(struct zram *zram, struct 
> > zram_entry *new,
> > struct rb_node **rb_node, *parent = NULL;
> > struct zram_entry *entry;
> >  
> > +   if (!zram->use_dedup)
> > +   return;
> > +
> > new->checksum = checksum;
> > hash = >hash[checksum % meta->hash_size];
> > rb_root = >rb_root;
> > @@ -492,7 +543,8 @@ static bool zram_entry_match(struct zram *zram, struct 
> > zram_entry *entry,
> > struct zram_meta *meta = zram->meta;
> > struct zcomp_strm *zstrm;
> >  
> > -   cmem = zs_map_object(meta->mem_pool, entry->handle, ZS_MM_RO);
> > +   cmem = zs_map_object(meta->mem_pool,
> > +   zram_entry_handle(zram, entry), ZS_MM_RO);
> > if (entry->len == PAGE_SIZE) {
> > match = !memcmp(mem, cmem, PAGE_SIZE);
> > } else {
> > @@ -501,7 +553,7 @@ static bool zram_entry_match(struct zram *zram, struct 
> > zram_entry *entry,
> 

Re: [PATCH 4/4] zram: make deduplication feature optional

2017-03-22 Thread Joonsoo Kim
On Wed, Mar 22, 2017 at 09:00:59AM +0900, Minchan Kim wrote:
> On Thu, Mar 16, 2017 at 11:46:38AM +0900, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> > 
> > Benefit of deduplication is dependent on the workload so it's not
> > preferable to always enable. Therefore, make it optional.
> 
> Please make it to Kconfig, too. And write down the description to impress
> "help a lot for users who uses zram to build output directory"
> And the feature should be disabled as default.

Okay.

> 
> > 
> > Signed-off-by: Joonsoo Kim 
> > ---
> >  drivers/block/zram/zram_drv.c | 80 
> > ++-
> >  drivers/block/zram/zram_drv.h |  1 +
> >  2 files changed, 73 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index 012425f..e45aa9f 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -328,6 +328,39 @@ static ssize_t comp_algorithm_store(struct device *dev,
> > return len;
> >  }
> >  
> > +static ssize_t use_dedup_show(struct device *dev,
> > +   struct device_attribute *attr, char *buf)
> > +{
> > +   int val;
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   down_read(>init_lock);
> > +   val = zram->use_dedup;
> > +   up_read(>init_lock);
> > +
> > +   return scnprintf(buf, PAGE_SIZE, "%d\n", val);
> > +}
> > +
> > +static ssize_t use_dedup_store(struct device *dev,
> > +   struct device_attribute *attr, const char *buf, size_t len)
> > +{
> > +   int val;
> > +   struct zram *zram = dev_to_zram(dev);
> > +
> > +   if (kstrtoint(buf, 10, ) || (val != 0 && val != 1))
> > +   return -EINVAL;
> > +
> > +   down_write(>init_lock);
> > +   if (init_done(zram)) {
> > +   up_write(>init_lock);
> > +   pr_info("Can't change dedup usage for initialized device\n");
> > +   return -EBUSY;
> > +   }
> > +   zram->use_dedup = val;
> > +   up_write(>init_lock);
> > +   return len;
> > +}
> > +
> >  static ssize_t compact_store(struct device *dev,
> > struct device_attribute *attr, const char *buf, size_t len)
> >  {
> > @@ -422,11 +455,23 @@ static ssize_t debug_stat_show(struct device *dev,
> >  static DEVICE_ATTR_RO(mm_stat);
> >  static DEVICE_ATTR_RO(debug_stat);
> >  
> > -static u32 zram_calc_checksum(unsigned char *mem)
> > +static u32 zram_calc_checksum(struct zram *zram, unsigned char *mem)
> >  {
> > +   if (!zram->use_dedup)
> > +   return 0;
> > +
> 
> Hmm, I don't like this style which every dedup functions have the check
> "use_dedup".
> 
> Can't we abstract like this?

I will try but I'm not sure it can be.

> 
> I want to find more simple way to no need to add the check when new dedup
> functions pop up.
> 
> bool zram_dedup_check
> if (!zram->dedup)
> return false;
> 
> zram_dedup_checksum
> entry = zram_dedup_get
> if (!entry) {
> zram_dedup_add
> return false;
> }
> ..
> return true;
> 
> 
> zram_bvec_write:
> ...
> ...
> 
> if (zram_dedup_match())
> goto found_dup;
> 
> 
> 
> > return jhash(mem, PAGE_SIZE, 0);
> >  }
> >  
> > +static unsigned long zram_entry_handle(struct zram *zram,
> > +   struct zram_entry *entry)
> > +{
> > +   if (!zram->use_dedup)
> > +   return (unsigned long)entry;
> > +
> > +   return entry->handle;
> > +}
> > +
> >  static struct zram_entry *zram_entry_alloc(struct zram *zram,
> > unsigned int len, gfp_t flags)
> >  {
> > @@ -438,6 +483,9 @@ static struct zram_entry *zram_entry_alloc(struct zram 
> > *zram,
> > if (!handle)
> > return NULL;
> >  
> > +   if (!zram->use_dedup)
> > +   return (struct zram_entry *)handle;
> > +
> > entry = kzalloc(sizeof(*entry), flags);
> > if (!entry) {
> > zs_free(meta->mem_pool, handle);
> > @@ -462,6 +510,9 @@ static void zram_entry_insert(struct zram *zram, struct 
> > zram_entry *new,
> > struct rb_node **rb_node, *parent = NULL;
> > struct zram_entry *entry;
> >  
> > +   if (!zram->use_dedup)
> > +   return;
> > +
> > new->checksum = checksum;
> > hash = >hash[checksum % meta->hash_size];
> > rb_root = >rb_root;
> > @@ -492,7 +543,8 @@ static bool zram_entry_match(struct zram *zram, struct 
> > zram_entry *entry,
> > struct zram_meta *meta = zram->meta;
> > struct zcomp_strm *zstrm;
> >  
> > -   cmem = zs_map_object(meta->mem_pool, entry->handle, ZS_MM_RO);
> > +   cmem = zs_map_object(meta->mem_pool,
> > +   zram_entry_handle(zram, entry), ZS_MM_RO);
> > if (entry->len == PAGE_SIZE) {
> > match = !memcmp(mem, cmem, PAGE_SIZE);
> > } else {
> > @@ -501,7 +553,7 @@ static bool zram_entry_match(struct zram *zram, struct 
> > zram_entry *entry,
> > match = !memcmp(mem, 

Re: [PATCH 3/4] zram: implement deduplication in zram

2017-03-22 Thread Joonsoo Kim
On Wed, Mar 22, 2017 at 08:41:21AM +0900, Minchan Kim wrote:
> Hi Joonsoo,
> 
> On Thu, Mar 16, 2017 at 11:46:37AM +0900, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> > 
> > This patch implements deduplication feature in zram. The purpose
> > of this work is naturally to save amount of memory usage by zram.
> > 
> > Android is one of the biggest users to use zram as swap and it's
> > really important to save amount of memory usage. There is a paper
> > that reports that duplication ratio of Android's memory content is
> > rather high [1]. And, there is a similar work on zswap that also
> > reports that experiments has shown that around 10-15% of pages
> > stored in zswp are duplicates and deduplicate them provides some
> > benefits [2].
> > 
> > Also, there is a different kind of workload that uses zram as blockdev
> > and store build outputs into it to reduce wear-out problem of real
> > blockdev. In this workload, deduplication hit is very high
> > although I don't know exact reason about it.
> 
> Hmm, Isn't it due to binary composed by obj files so that many of
> part between binary and object are sharable?
> 
> I'd like to clear it out because dedup was not useful for swap workload
> for the testing in android unlike papers you mentioned.
> Of course, it depends on the workload so someone might find it's
> huge useful for his swap workload. However, I want to focus clear
> winning case scenario rather than "might be better".
> 
> That's why I want to know clear reason the saving. If my assumption
> is right(i.e., object file vs. binary file), it would be enough
> justfication to merge this feature because user can turn on the feature
> with reasonable expectation.

Okay. I checked the reason of benefit on the kernel build now. There are
some cases that deduplication happens.

1) *.cmd
Build command is usually similar in one directory. So, content of
these file are very similar. Please check fs/ext4/.namei.o.cmd and
fs/ext4/.inode.o.cmd. In my system, more than 789 lines are the same
in 944 and 939 line of the file, respectively.

2) object file
built-in.o and temporal object file have the similar content. More
than 50% of fs/ext4/ext4.o is the same with fs/ext4/built-in.o. I
think that we can optimize in this case. ext4.o is temporal object
file and it isn't necessarily needed. We can change following
fs/ext4/Makefile to optimized one.

orig>
obj-$(CONFIG_EXT4_FS) += ext4.o
ext4-y := XXX YYY ZZZ

optimized>
obj-$(CONFIG_EXT4_FS) += XXX YYY ZZZ

3) vmlinux
.tmp_vmlinux1 and .tmp_vmlinux2 and arch/x86/boot/compressed/vmlinux.bin
have the similar content.

I did similar checking for Android and it also has similar case.
Some of object files (.class and .so) are similar with another object
files. (./host/linux-x86/lib/libartd.so and
./host/linux-x86/lib/libartd-compiler.so)

> 
> > 
> > Anyway, if we can detect duplicated content and avoid to store duplicated
> > content at different memory space, we can save memory. This patch
> > tries to do that.
> > 
> > Implementation is almost simple and intuitive but I should note
> > one thing about implementation detail.
> > 
> > To check duplication, this patch uses checksum of the page and
> > collision of this checksum could be possible. There would be
> > many choices to handle this situation but this patch chooses
> > to allow entry with duplicated checksum to be added to the hash,
> > but, not to compare all entries with duplicated checksum
> > when checking duplication. I guess that checksum collision is quite
> 
> Hmm, if there are many duplicated checksum, what a specific checksum
> is compared among them?

I implemented it to check just first one.

> > rare event and we don't need to pay any attention to such a case.
> 
> If it's rare event, why can't we iterate all of entries?

It's possible. If you prefer it, I can do it.

> > Therefore, I decided the most simplest way to implement the feature.
> > If there is a different opinion, I can accept and go that way.
> > 
> > Following is the result of this patch.
> > 
> > Test result #1 (Swap):
> > Android Marshmallow, emulator, x86_64, Backporting to kernel v3.18
> > 
> > orig_data_size: 145297408
> > compr_data_size: 32408125
> > mem_used_total: 32276480
> > dup_data_size: 3188134
> > meta_data_size: 1444272
> > 
> > Last two metrics added to mm_stat are related to this work.
> > First one, dup_data_size, is amount of saved memory by avoiding
> > to store duplicated page. Later one, meta_data_size, is the amount of
> > data structure to support deduplication. If dup > meta, we can judge
> > that the patch improves memory usage.
> > 
> > In Adnroid, we can save 5% of memory usage by this work.
> > 
> > Test result #2 (Blockdev):
> > build the kernel and store output to ext4 FS on zram
> > 
> > 
> > Elapsed time: 249 s
> > mm_stat: 430845952 191014886 196898816 0 196898816 28320 0 0 0
> > 
> > 
> > Elapsed time: 250 s
> > mm_stat: 430505984 190971334 148365312 0 148365312 28404 0 

Re: [PATCH 3/4] zram: implement deduplication in zram

2017-03-22 Thread Joonsoo Kim
On Wed, Mar 22, 2017 at 08:41:21AM +0900, Minchan Kim wrote:
> Hi Joonsoo,
> 
> On Thu, Mar 16, 2017 at 11:46:37AM +0900, js1...@gmail.com wrote:
> > From: Joonsoo Kim 
> > 
> > This patch implements deduplication feature in zram. The purpose
> > of this work is naturally to save amount of memory usage by zram.
> > 
> > Android is one of the biggest users to use zram as swap and it's
> > really important to save amount of memory usage. There is a paper
> > that reports that duplication ratio of Android's memory content is
> > rather high [1]. And, there is a similar work on zswap that also
> > reports that experiments has shown that around 10-15% of pages
> > stored in zswp are duplicates and deduplicate them provides some
> > benefits [2].
> > 
> > Also, there is a different kind of workload that uses zram as blockdev
> > and store build outputs into it to reduce wear-out problem of real
> > blockdev. In this workload, deduplication hit is very high
> > although I don't know exact reason about it.
> 
> Hmm, Isn't it due to binary composed by obj files so that many of
> part between binary and object are sharable?
> 
> I'd like to clear it out because dedup was not useful for swap workload
> for the testing in android unlike papers you mentioned.
> Of course, it depends on the workload so someone might find it's
> huge useful for his swap workload. However, I want to focus clear
> winning case scenario rather than "might be better".
> 
> That's why I want to know clear reason the saving. If my assumption
> is right(i.e., object file vs. binary file), it would be enough
> justfication to merge this feature because user can turn on the feature
> with reasonable expectation.

Okay. I checked the reason of benefit on the kernel build now. There are
some cases that deduplication happens.

1) *.cmd
Build command is usually similar in one directory. So, content of
these file are very similar. Please check fs/ext4/.namei.o.cmd and
fs/ext4/.inode.o.cmd. In my system, more than 789 lines are the same
in 944 and 939 line of the file, respectively.

2) object file
built-in.o and temporal object file have the similar content. More
than 50% of fs/ext4/ext4.o is the same with fs/ext4/built-in.o. I
think that we can optimize in this case. ext4.o is temporal object
file and it isn't necessarily needed. We can change following
fs/ext4/Makefile to optimized one.

orig>
obj-$(CONFIG_EXT4_FS) += ext4.o
ext4-y := XXX YYY ZZZ

optimized>
obj-$(CONFIG_EXT4_FS) += XXX YYY ZZZ

3) vmlinux
.tmp_vmlinux1 and .tmp_vmlinux2 and arch/x86/boot/compressed/vmlinux.bin
have the similar content.

I did similar checking for Android and it also has similar case.
Some of object files (.class and .so) are similar with another object
files. (./host/linux-x86/lib/libartd.so and
./host/linux-x86/lib/libartd-compiler.so)

> 
> > 
> > Anyway, if we can detect duplicated content and avoid to store duplicated
> > content at different memory space, we can save memory. This patch
> > tries to do that.
> > 
> > Implementation is almost simple and intuitive but I should note
> > one thing about implementation detail.
> > 
> > To check duplication, this patch uses checksum of the page and
> > collision of this checksum could be possible. There would be
> > many choices to handle this situation but this patch chooses
> > to allow entry with duplicated checksum to be added to the hash,
> > but, not to compare all entries with duplicated checksum
> > when checking duplication. I guess that checksum collision is quite
> 
> Hmm, if there are many duplicated checksum, what a specific checksum
> is compared among them?

I implemented it to check just first one.

> > rare event and we don't need to pay any attention to such a case.
> 
> If it's rare event, why can't we iterate all of entries?

It's possible. If you prefer it, I can do it.

> > Therefore, I decided the most simplest way to implement the feature.
> > If there is a different opinion, I can accept and go that way.
> > 
> > Following is the result of this patch.
> > 
> > Test result #1 (Swap):
> > Android Marshmallow, emulator, x86_64, Backporting to kernel v3.18
> > 
> > orig_data_size: 145297408
> > compr_data_size: 32408125
> > mem_used_total: 32276480
> > dup_data_size: 3188134
> > meta_data_size: 1444272
> > 
> > Last two metrics added to mm_stat are related to this work.
> > First one, dup_data_size, is amount of saved memory by avoiding
> > to store duplicated page. Later one, meta_data_size, is the amount of
> > data structure to support deduplication. If dup > meta, we can judge
> > that the patch improves memory usage.
> > 
> > In Adnroid, we can save 5% of memory usage by this work.
> > 
> > Test result #2 (Blockdev):
> > build the kernel and store output to ext4 FS on zram
> > 
> > 
> > Elapsed time: 249 s
> > mm_stat: 430845952 191014886 196898816 0 196898816 28320 0 0 0
> > 
> > 
> > Elapsed time: 250 s
> > mm_stat: 430505984 190971334 148365312 0 148365312 28404 0 47287038  3945792
> > 

Re: Purpose of PCI address in ranges property

2017-03-22 Thread valmiki

On 3/20/2017 3:15 AM, Arnd Bergmann wrote:

On Sun, Mar 19, 2017 at 3:14 PM, valmiki  wrote:

Hi,

When ranges property is being parsed using of_pci_get_host_bridge_resources,
the pci address is being used for
calculating the offset for pci_add_resource_offset.

What is this offset for ?

So the cpu address is being used for programming memory base and limit
registers ?


Linux IORESOURCE_MEM resources are defined in terms of CPU addresses,
while PCI config space BAR registers are programmed with bus addresses.
These are often the same, but on some machines they are not, which results
in an offset that has to be used when accessing the BARs.

Thanks Arnd. So mem base and limit registers of RP are programmed with 
CPU addresses,

and EP BARs are programmed with PCI bus addresses ?
So when will this offset be used, only when RP assigns BAR's to RP ?

Regards,
Valmiki





Re: Purpose of PCI address in ranges property

2017-03-22 Thread valmiki

On 3/20/2017 3:15 AM, Arnd Bergmann wrote:

On Sun, Mar 19, 2017 at 3:14 PM, valmiki  wrote:

Hi,

When ranges property is being parsed using of_pci_get_host_bridge_resources,
the pci address is being used for
calculating the offset for pci_add_resource_offset.

What is this offset for ?

So the cpu address is being used for programming memory base and limit
registers ?


Linux IORESOURCE_MEM resources are defined in terms of CPU addresses,
while PCI config space BAR registers are programmed with bus addresses.
These are often the same, but on some machines they are not, which results
in an offset that has to be used when accessing the BARs.

Thanks Arnd. So mem base and limit registers of RP are programmed with 
CPU addresses,

and EP BARs are programmed with PCI bus addresses ?
So when will this offset be used, only when RP assigns BAR's to RP ?

Regards,
Valmiki





perf_callchain_user oops

2017-03-22 Thread Dave Jones
Not seen this one before..

Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 1 PID: 24420 Comm: trinity-main Not tainted 4.11.0-rc3-think+ #3 
task: 8804f4c85440 task.stack: c90001d38000
RIP: 0010:perf_callchain_user+0x11e/0x220
RSP: :c90001d3ba98 EFLAGS: 00010246
RAX: 88044c59c2a8 RBX: c90001d3bae8 RCX: 562bce3f6e40
RDX: 562bce3f6e40 RSI: 7fffeff0 RDI: 
RBP: c90001d3bab8 R08: bff0 R09: dff0
R10: 2faa R11: 2fab R12: 8804f4c85440
R13: c90001d3bf58 R14: c90001d3bf58 R15: 
FS:  7f34b3969b40() GS:880507a0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 88044c5b4000 CR3: 00044c584000 CR4: 001406e0
DR0: 7f34b382e000 DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Call Trace:
 get_perf_callchain+0x258/0x2b0
 perf_callchain+0x79/0x80
 perf_prepare_sample+0x27e/0x360
 perf_event_output_forward+0x75/0x160
 ? perf_prepare_sample+0x360/0x360
 ? sched_clock_cpu+0x13/0xe0
 __perf_event_overflow+0x54/0xf0
 perf_swevent_overflow+0x9a/0xc0
 perf_swevent_event+0x60/0x80
 ___perf_sw_event+0x152/0x290
 ? ___perf_sw_event+0x32/0x290
 ? debug_smp_processor_id+0x17/0x20
 ? get_lock_stats+0x19/0x50
 ? filemap_map_pages+0x2b7/0x550
 ? filemap_map_pages+0x5/0x550
 ? _raw_spin_unlock+0x31/0x50
 ? debug_smp_processor_id+0x17/0x20
 ? get_lock_stats+0x19/0x50
 __perf_sw_event+0x43/0x90
 __do_page_fault+0x322/0x4f0
 do_page_fault+0x20/0x70
 page_fault+0x1f/0x30
RIP: 0033:0x7f34b3232ca0
RSP: 002b:7ffe946e1ae8 EFLAGS: 00010206
RAX: 562bce3431b0 RBX: 562bcdb73210 RCX: 001d
RDX: 001d RSI: 562bcdb73250 RDI: 562bce3431b0
RBP: 562bce3f6e40 R08: 00b1 R09: 00ff
R10: bcbf40b2 R11: 834e0b5f R12: 562bcdb732b0
R13: 0003 R14: 2804 R15: 7ffe946e1e80
Code: f8 48 8b 0a 85 c0 0f 85 e7 00 00 00 48 8b 52 08 85 c0 0f 85 db 00 00 00 
80 7b 12 00 75 aa 48 8b 03 4c 8b 10 4d 8d 5a 01 4c 89 18 <4a> 89 54 d0 08 8b 43 
0c 83 c0 01 89 43 0c eb 90 41 8b bd 88 00 
CR2: 88044c5b4000




perf_callchain_user oops

2017-03-22 Thread Dave Jones
Not seen this one before..

Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 1 PID: 24420 Comm: trinity-main Not tainted 4.11.0-rc3-think+ #3 
task: 8804f4c85440 task.stack: c90001d38000
RIP: 0010:perf_callchain_user+0x11e/0x220
RSP: :c90001d3ba98 EFLAGS: 00010246
RAX: 88044c59c2a8 RBX: c90001d3bae8 RCX: 562bce3f6e40
RDX: 562bce3f6e40 RSI: 7fffeff0 RDI: 
RBP: c90001d3bab8 R08: bff0 R09: dff0
R10: 2faa R11: 2fab R12: 8804f4c85440
R13: c90001d3bf58 R14: c90001d3bf58 R15: 
FS:  7f34b3969b40() GS:880507a0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 88044c5b4000 CR3: 00044c584000 CR4: 001406e0
DR0: 7f34b382e000 DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Call Trace:
 get_perf_callchain+0x258/0x2b0
 perf_callchain+0x79/0x80
 perf_prepare_sample+0x27e/0x360
 perf_event_output_forward+0x75/0x160
 ? perf_prepare_sample+0x360/0x360
 ? sched_clock_cpu+0x13/0xe0
 __perf_event_overflow+0x54/0xf0
 perf_swevent_overflow+0x9a/0xc0
 perf_swevent_event+0x60/0x80
 ___perf_sw_event+0x152/0x290
 ? ___perf_sw_event+0x32/0x290
 ? debug_smp_processor_id+0x17/0x20
 ? get_lock_stats+0x19/0x50
 ? filemap_map_pages+0x2b7/0x550
 ? filemap_map_pages+0x5/0x550
 ? _raw_spin_unlock+0x31/0x50
 ? debug_smp_processor_id+0x17/0x20
 ? get_lock_stats+0x19/0x50
 __perf_sw_event+0x43/0x90
 __do_page_fault+0x322/0x4f0
 do_page_fault+0x20/0x70
 page_fault+0x1f/0x30
RIP: 0033:0x7f34b3232ca0
RSP: 002b:7ffe946e1ae8 EFLAGS: 00010206
RAX: 562bce3431b0 RBX: 562bcdb73210 RCX: 001d
RDX: 001d RSI: 562bcdb73250 RDI: 562bce3431b0
RBP: 562bce3f6e40 R08: 00b1 R09: 00ff
R10: bcbf40b2 R11: 834e0b5f R12: 562bcdb732b0
R13: 0003 R14: 2804 R15: 7ffe946e1e80
Code: f8 48 8b 0a 85 c0 0f 85 e7 00 00 00 48 8b 52 08 85 c0 0f 85 db 00 00 00 
80 7b 12 00 75 aa 48 8b 03 4c 8b 10 4d 8d 5a 01 4c 89 18 <4a> 89 54 d0 08 8b 43 
0c 83 c0 01 89 43 0c eb 90 41 8b bd 88 00 
CR2: 88044c5b4000




[PATCH v3 1/2] module: verify address is read-only

2017-03-22 Thread Eddie Kovsky
Implement a mechanism to check if a module's address is in
the rodata or ro_after_init sections. It mimics the exsiting functions
that test if an address is inside a module's text section.

Functions that take a module as an argument will be able to
verify that the module is in a read-only section.

Signed-off-by: Eddie Kovsky 
---
Changes in v3:
 - Change function name is_module_ro_address() to
is_module_rodata_address().
 - Improve comments on is_module_rodata_address().
 - Add a !CONFIG_MODULES stub for is_module_rodata_address.
 - Correct and simplify the check for the read-only memory regions in
the module address.

 include/linux/module.h | 12 
 kernel/module.c| 53 ++
 2 files changed, 65 insertions(+)

diff --git a/include/linux/module.h b/include/linux/module.h
index 9ad68561d8c2..66b7fd321334 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -492,7 +492,9 @@ static inline int module_is_live(struct module *mod)

 struct module *__module_text_address(unsigned long addr);
 struct module *__module_address(unsigned long addr);
+struct module *__module_ro_address(unsigned long addr);
 bool is_module_address(unsigned long addr);
+bool is_module_rodata_address(unsigned long addr);
 bool __is_module_percpu_address(unsigned long addr, unsigned long *can_addr);
 bool is_module_percpu_address(unsigned long addr);
 bool is_module_text_address(unsigned long addr);
@@ -646,6 +648,16 @@ static inline struct module *__module_address(unsigned 
long addr)
return NULL;
 }

+static inline struct module *__module_ro_address(unsigned long addr)
+{
+   return NULL;
+}
+
+static inline bool is_module_rodata_address(unsigned long addr)
+{
+   return false;
+}
+
 static inline struct module *__module_text_address(unsigned long addr)
 {
return NULL;
diff --git a/kernel/module.c b/kernel/module.c
index 8ffcd29a4245..99ada1257aaa 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4292,6 +4292,59 @@ struct module *__module_text_address(unsigned long addr)
 }
 EXPORT_SYMBOL_GPL(__module_text_address);

+/**
+ * is_module_rodata_address - is this address inside read-only module code?
+ * @addr: the address to check.
+ *
+ */
+bool is_module_rodata_address(unsigned long addr)
+{
+   bool ret;
+
+   preempt_disable();
+   ret = __module_ro_address(addr) != NULL;
+   preempt_enable();
+
+   return ret;
+}
+
+/*
+ * __module_ro_address - get the module whose rodata/ro_after_init sections
+ * contain the given address.
+ * @addr: the address.
+ *
+ * Must be called with preempt disabled or module mutex held so that
+ * module doesn't get freed during this.
+ */
+struct module *__module_ro_address(unsigned long addr)
+{
+   struct module *mod = __module_address(addr);
+
+   void *init_base = mod->init_layout.base;
+   unsigned int init_text_size = mod->init_layout.text_size;
+   unsigned int init_ro_after_init_size = 
mod->init_layout.ro_after_init_size;
+
+   void *core_base = mod->core_layout.base;
+   unsigned int core_text_size = mod->core_layout.text_size;
+   unsigned int core_ro_after_init_size = 
mod->core_layout.ro_after_init_size;
+
+   /*
+* Make sure module is within the read-only section.
+* range(base + text_size, base + ro_after_init_size)
+* encompasses both the rodata and ro_after_init regions.
+* See comment above frob_text() for the layout diagram.
+*/
+   if (mod) {
+   if (!within(addr, init_base + init_text_size,
+   init_ro_after_init_size - init_text_size)
+   && !within(addr, core_base + core_text_size,
+  core_ro_after_init_size - core_text_size))
+   mod = NULL;
+   }
+   return mod;
+}
+EXPORT_SYMBOL_GPL(__module_ro_address);
+
 /* Don't grab lock, we're oopsing. */
 void print_modules(void)
 {
--
2.12.0


[PATCH v3 2/2] extable: verify address is read-only

2017-03-22 Thread Eddie Kovsky
Provide a mechanism to check if the address of a variable is
const or ro_after_init. It mimics the existing functions that test if an
address is inside the kernel's text section.

Other functions inside the kernel could then use this capability to
verify that their arguments are read-only.

Signed-off-by: Eddie Kovsky 
---
Changes in v3:
 - Fix missing declaration of is_module_rodata_address()

 include/linux/kernel.h |  2 ++
 kernel/extable.c   | 29 +
 2 files changed, 31 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c26dc3a8295..51beea39e6c4 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -444,6 +444,8 @@ extern int core_kernel_data(unsigned long addr);
 extern int __kernel_text_address(unsigned long addr);
 extern int kernel_text_address(unsigned long addr);
 extern int func_ptr_is_kernel_text(void *ptr);
+extern int core_kernel_ro_data(unsigned long addr);
+extern int kernel_ro_address(unsigned long addr);

 unsigned long int_sqrt(unsigned long);

diff --git a/kernel/extable.c b/kernel/extable.c
index 2676d7f8baf6..3c3a9f4e6250 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -154,3 +154,32 @@ int func_ptr_is_kernel_text(void *ptr)
return 1;
return is_module_text_address(addr);
 }
+
+/**
+ * core_kernel_ro_data - Verify address points to read-only section
+ * @addr: address to test
+ *
+ */
+int core_kernel_ro_data(unsigned long addr)
+{
+   if (addr >= (unsigned long)__start_rodata &&
+   addr < (unsigned long)__end_rodata)
+   return 1;
+
+   if (addr >= (unsigned long)__start_data_ro_after_init &&
+   addr < (unsigned long)__end_data_ro_after_init)
+   return 1;
+
+   return 0;
+}
+
+/* Verify that address is const or ro_after_init. */
+int kernel_ro_address(unsigned long addr)
+{
+   if (core_kernel_ro_data(addr))
+   return 1;
+   if (is_module_rodata_address(addr))
+   return 1;
+
+   return 0;
+}
--
2.12.0


[PATCH v3 1/2] module: verify address is read-only

2017-03-22 Thread Eddie Kovsky
Implement a mechanism to check if a module's address is in
the rodata or ro_after_init sections. It mimics the exsiting functions
that test if an address is inside a module's text section.

Functions that take a module as an argument will be able to
verify that the module is in a read-only section.

Signed-off-by: Eddie Kovsky 
---
Changes in v3:
 - Change function name is_module_ro_address() to
is_module_rodata_address().
 - Improve comments on is_module_rodata_address().
 - Add a !CONFIG_MODULES stub for is_module_rodata_address.
 - Correct and simplify the check for the read-only memory regions in
the module address.

 include/linux/module.h | 12 
 kernel/module.c| 53 ++
 2 files changed, 65 insertions(+)

diff --git a/include/linux/module.h b/include/linux/module.h
index 9ad68561d8c2..66b7fd321334 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -492,7 +492,9 @@ static inline int module_is_live(struct module *mod)

 struct module *__module_text_address(unsigned long addr);
 struct module *__module_address(unsigned long addr);
+struct module *__module_ro_address(unsigned long addr);
 bool is_module_address(unsigned long addr);
+bool is_module_rodata_address(unsigned long addr);
 bool __is_module_percpu_address(unsigned long addr, unsigned long *can_addr);
 bool is_module_percpu_address(unsigned long addr);
 bool is_module_text_address(unsigned long addr);
@@ -646,6 +648,16 @@ static inline struct module *__module_address(unsigned 
long addr)
return NULL;
 }

+static inline struct module *__module_ro_address(unsigned long addr)
+{
+   return NULL;
+}
+
+static inline bool is_module_rodata_address(unsigned long addr)
+{
+   return false;
+}
+
 static inline struct module *__module_text_address(unsigned long addr)
 {
return NULL;
diff --git a/kernel/module.c b/kernel/module.c
index 8ffcd29a4245..99ada1257aaa 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4292,6 +4292,59 @@ struct module *__module_text_address(unsigned long addr)
 }
 EXPORT_SYMBOL_GPL(__module_text_address);

+/**
+ * is_module_rodata_address - is this address inside read-only module code?
+ * @addr: the address to check.
+ *
+ */
+bool is_module_rodata_address(unsigned long addr)
+{
+   bool ret;
+
+   preempt_disable();
+   ret = __module_ro_address(addr) != NULL;
+   preempt_enable();
+
+   return ret;
+}
+
+/*
+ * __module_ro_address - get the module whose rodata/ro_after_init sections
+ * contain the given address.
+ * @addr: the address.
+ *
+ * Must be called with preempt disabled or module mutex held so that
+ * module doesn't get freed during this.
+ */
+struct module *__module_ro_address(unsigned long addr)
+{
+   struct module *mod = __module_address(addr);
+
+   void *init_base = mod->init_layout.base;
+   unsigned int init_text_size = mod->init_layout.text_size;
+   unsigned int init_ro_after_init_size = 
mod->init_layout.ro_after_init_size;
+
+   void *core_base = mod->core_layout.base;
+   unsigned int core_text_size = mod->core_layout.text_size;
+   unsigned int core_ro_after_init_size = 
mod->core_layout.ro_after_init_size;
+
+   /*
+* Make sure module is within the read-only section.
+* range(base + text_size, base + ro_after_init_size)
+* encompasses both the rodata and ro_after_init regions.
+* See comment above frob_text() for the layout diagram.
+*/
+   if (mod) {
+   if (!within(addr, init_base + init_text_size,
+   init_ro_after_init_size - init_text_size)
+   && !within(addr, core_base + core_text_size,
+  core_ro_after_init_size - core_text_size))
+   mod = NULL;
+   }
+   return mod;
+}
+EXPORT_SYMBOL_GPL(__module_ro_address);
+
 /* Don't grab lock, we're oopsing. */
 void print_modules(void)
 {
--
2.12.0


[PATCH v3 2/2] extable: verify address is read-only

2017-03-22 Thread Eddie Kovsky
Provide a mechanism to check if the address of a variable is
const or ro_after_init. It mimics the existing functions that test if an
address is inside the kernel's text section.

Other functions inside the kernel could then use this capability to
verify that their arguments are read-only.

Signed-off-by: Eddie Kovsky 
---
Changes in v3:
 - Fix missing declaration of is_module_rodata_address()

 include/linux/kernel.h |  2 ++
 kernel/extable.c   | 29 +
 2 files changed, 31 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c26dc3a8295..51beea39e6c4 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -444,6 +444,8 @@ extern int core_kernel_data(unsigned long addr);
 extern int __kernel_text_address(unsigned long addr);
 extern int kernel_text_address(unsigned long addr);
 extern int func_ptr_is_kernel_text(void *ptr);
+extern int core_kernel_ro_data(unsigned long addr);
+extern int kernel_ro_address(unsigned long addr);

 unsigned long int_sqrt(unsigned long);

diff --git a/kernel/extable.c b/kernel/extable.c
index 2676d7f8baf6..3c3a9f4e6250 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -154,3 +154,32 @@ int func_ptr_is_kernel_text(void *ptr)
return 1;
return is_module_text_address(addr);
 }
+
+/**
+ * core_kernel_ro_data - Verify address points to read-only section
+ * @addr: address to test
+ *
+ */
+int core_kernel_ro_data(unsigned long addr)
+{
+   if (addr >= (unsigned long)__start_rodata &&
+   addr < (unsigned long)__end_rodata)
+   return 1;
+
+   if (addr >= (unsigned long)__start_data_ro_after_init &&
+   addr < (unsigned long)__end_data_ro_after_init)
+   return 1;
+
+   return 0;
+}
+
+/* Verify that address is const or ro_after_init. */
+int kernel_ro_address(unsigned long addr)
+{
+   if (core_kernel_ro_data(addr))
+   return 1;
+   if (is_module_rodata_address(addr))
+   return 1;
+
+   return 0;
+}
--
2.12.0


[PATCH v3 0/2] provide check for ro_after_init memory sections

2017-03-22 Thread Eddie Kovsky
Provide a mechanism for other functions to verify that their arguments
are read-only.

This implements the first half of a suggestion made by Kees Cook for
the Kernel Self Protection Project:

- provide mechanism to check for ro_after_init memory areas, and
  reject structures not marked ro_after_init in vmbus_register()

  http://www.openwall.com/lists/kernel-hardening/2017/02/04/1

The idea is to prevent structures (including modules) that are not
read-only from being passed to functions. It builds upon the functions
in kernel/extable.c that test if an address is in the text section.

I have dropped the third patch that uses these features to check the
arguments to vmbus_register() because the maintainers have not been
receptive to using it. My goal right now is to get the API right.

I have test compiled this series on next-20170321 for x86.


Eddie Kovsky (2):
  module: verify address is read-only
  extable: verify address is read-only

 include/linux/kernel.h |  2 ++
 include/linux/module.h | 12 
 kernel/extable.c   | 29 +++
 kernel/module.c| 53 ++
 4 files changed, 96 insertions(+)

--
2.12.0


[PATCH v3 0/2] provide check for ro_after_init memory sections

2017-03-22 Thread Eddie Kovsky
Provide a mechanism for other functions to verify that their arguments
are read-only.

This implements the first half of a suggestion made by Kees Cook for
the Kernel Self Protection Project:

- provide mechanism to check for ro_after_init memory areas, and
  reject structures not marked ro_after_init in vmbus_register()

  http://www.openwall.com/lists/kernel-hardening/2017/02/04/1

The idea is to prevent structures (including modules) that are not
read-only from being passed to functions. It builds upon the functions
in kernel/extable.c that test if an address is in the text section.

I have dropped the third patch that uses these features to check the
arguments to vmbus_register() because the maintainers have not been
receptive to using it. My goal right now is to get the API right.

I have test compiled this series on next-20170321 for x86.


Eddie Kovsky (2):
  module: verify address is read-only
  extable: verify address is read-only

 include/linux/kernel.h |  2 ++
 include/linux/module.h | 12 
 kernel/extable.c   | 29 +++
 kernel/module.c| 53 ++
 4 files changed, 96 insertions(+)

--
2.12.0


Re: [PATCH] Documentation: Input: Add uinput documentation

2017-03-22 Thread Marcos Paulo de Souza
Hi Peter,

first of all, thanks a lot for reading this patch so quickly and to
point a lot of things to make this doc way better.

See some notes below.

On Wed, Mar 22, 2017 at 02:03:31PM +1000, Peter Hutterer wrote:
> Thanks for this, I'm getting enough questions about this, so it's nice to
> have a link :)
> 
> First comment: I don't think rst requires unwrapped lines, so please break
> those up.
> 
> Second comment: I'd really like to have a link to libevdev here. It has a
> uinput interface that's a bit more obvious and takes some of the guesswork
> out. While it's good to have documentation for the kernel module,
> application authors should really use libevdev's uinput interface.
> 
> On Tue, Mar 21, 2017 at 11:58:17PM -0300, Marcos Paulo de Souza wrote:
> > Signed-off-by: Marcos Paulo de Souza 
> > ---
> >  Documentation/input/uinput.rst | 158 
> > +
> >  1 file changed, 158 insertions(+)
> >  create mode 100644 Documentation/input/uinput.rst
> > 
> > diff --git a/Documentation/input/uinput.rst b/Documentation/input/uinput.rst
> > new file mode 100644
> > index 000..8d59c98
> > --- /dev/null
> > +++ b/Documentation/input/uinput.rst
> > @@ -0,0 +1,158 @@
> > +=
> > +uinput module
> > +=
> > +
> > +Introduction
> > +
> > +
> > +uinput is a kernel module that makes possible create and handle input
> 
> typo: "that makes it possible to ..."

Fixed here.

> 
> > devices from userspace. By using /dev/uinput (or /dev/input/uinput), a
> > process can create virtual devices and emit events like key pressing,
> > mouse movements and joystick buttons.
> 
> I'd say something like this: "By writing to the module's /dev/uinput (or
> /dev/input/uinput) file, a process can create a virtual device with specific
> capabilities. Once created, the process can send events through that virtual
> device."

Much better, fixed.

> 
> > +
> > +Interface
> > +=
> > +
> > +::
> > +
> > +  linux/uinput.h
> > +
> > +The uinput header defines ioctl request keys to create, setup and destroy 
> > virtual devices, along with ioctls specific to uinput devices, like 
> > enabling events and keys to be send to the kernel.
> 
> 'request keys' - is this the official name for ioctl numbers? If not, let's
> just use "define ioctls" or "ioctl numbers" or something, because the term
> "keys" is heavily overloaded. And anything after "along with... " is
> superfluous.

I prefer the "define ioctls", I don't remember where I found that "keys"
definition tough...

> 
> > +
> > +Examples
> > +
> > +
> > +1.0 Keyboard events
> > +---
> > +
> > +This first example shows how to create a new virtual device and how to
> > send a key event as well as a physical keyboard. All default imports and
> 
> "as well as" in english usually means "in addition". Just skip the part
> after "send a key event".

I think you now know that I'm not an English native speaker :)
Fixed here.

> 
> > error handlers were removed for the sake of simplicity.
> > +
> > +.. code-block:: c
> > +
> > +   #include 
> > +
> > +   int fd;
> > +
> > +   void emit(int type, int code, int val)
> > +   {
> > +struct input_event ie;
> 
> empty line here.

Fixed.

> 
> > +memset(, 0, sizeof(ie));
> > +ie.type = type;
> > +ie.code = code;
> > +ie.value = val;
> > +
> 
> memset followed by three out of five filled in seems strange. Just add
>   ie.time.tv_sec = 0;
>   ie.time.tv_usec = 0;
> 
> ideally, with a comment that states that the timestamp is ignored :)

All the code in this doc is the result of my tests using uinput, so
somethings were set in my code some time ago and were never touched
again. Yes, this makes things a way better :)

> 
> > +if (write(fd, , sizeof(ie)) < 0) {
> > +perror("write2");
> > +exit(1);
> > +}
> > +   }
> > +
> > +   int main() {
> > +struct input_id uid;
> > +struct uinput_setup usetup;
> > +
> > +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> 
> Empty line here to separate the open from the actual setup. And a comment
> explaining what this does wouldn't go amiss.

Very good, fixed here.
> 
> 
> > +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> > +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> > +
> > +memset(, 0, sizeof(iod));
> > +memset(, 0, sizeof(usetup));
> > +usetup.id = uid;
> 
> this is a bit strange - you're memsetting the id field anyway with the
> usetup memset - it's superfluous. Given this is supposed to be example code,
> something immediately obvious would help:
>usetup.id.bustype = BUS_USB;
>usetup.id.vendor = 0x1234; /* sample vendor */

Good. Fixed.
>... 
> 
> > +strcpy(usetup.name, "ex_device");
> 
> Surely we have enough bytes to name this "Example device" for obviousness :)
Sure, fixed :)
> 
> > +
> > +ioctl(fd, UI_DEV_SETUP, 

Re: [PATCH] Documentation: Input: Add uinput documentation

2017-03-22 Thread Marcos Paulo de Souza
Hi Peter,

first of all, thanks a lot for reading this patch so quickly and to
point a lot of things to make this doc way better.

See some notes below.

On Wed, Mar 22, 2017 at 02:03:31PM +1000, Peter Hutterer wrote:
> Thanks for this, I'm getting enough questions about this, so it's nice to
> have a link :)
> 
> First comment: I don't think rst requires unwrapped lines, so please break
> those up.
> 
> Second comment: I'd really like to have a link to libevdev here. It has a
> uinput interface that's a bit more obvious and takes some of the guesswork
> out. While it's good to have documentation for the kernel module,
> application authors should really use libevdev's uinput interface.
> 
> On Tue, Mar 21, 2017 at 11:58:17PM -0300, Marcos Paulo de Souza wrote:
> > Signed-off-by: Marcos Paulo de Souza 
> > ---
> >  Documentation/input/uinput.rst | 158 
> > +
> >  1 file changed, 158 insertions(+)
> >  create mode 100644 Documentation/input/uinput.rst
> > 
> > diff --git a/Documentation/input/uinput.rst b/Documentation/input/uinput.rst
> > new file mode 100644
> > index 000..8d59c98
> > --- /dev/null
> > +++ b/Documentation/input/uinput.rst
> > @@ -0,0 +1,158 @@
> > +=
> > +uinput module
> > +=
> > +
> > +Introduction
> > +
> > +
> > +uinput is a kernel module that makes possible create and handle input
> 
> typo: "that makes it possible to ..."

Fixed here.

> 
> > devices from userspace. By using /dev/uinput (or /dev/input/uinput), a
> > process can create virtual devices and emit events like key pressing,
> > mouse movements and joystick buttons.
> 
> I'd say something like this: "By writing to the module's /dev/uinput (or
> /dev/input/uinput) file, a process can create a virtual device with specific
> capabilities. Once created, the process can send events through that virtual
> device."

Much better, fixed.

> 
> > +
> > +Interface
> > +=
> > +
> > +::
> > +
> > +  linux/uinput.h
> > +
> > +The uinput header defines ioctl request keys to create, setup and destroy 
> > virtual devices, along with ioctls specific to uinput devices, like 
> > enabling events and keys to be send to the kernel.
> 
> 'request keys' - is this the official name for ioctl numbers? If not, let's
> just use "define ioctls" or "ioctl numbers" or something, because the term
> "keys" is heavily overloaded. And anything after "along with... " is
> superfluous.

I prefer the "define ioctls", I don't remember where I found that "keys"
definition tough...

> 
> > +
> > +Examples
> > +
> > +
> > +1.0 Keyboard events
> > +---
> > +
> > +This first example shows how to create a new virtual device and how to
> > send a key event as well as a physical keyboard. All default imports and
> 
> "as well as" in english usually means "in addition". Just skip the part
> after "send a key event".

I think you now know that I'm not an English native speaker :)
Fixed here.

> 
> > error handlers were removed for the sake of simplicity.
> > +
> > +.. code-block:: c
> > +
> > +   #include 
> > +
> > +   int fd;
> > +
> > +   void emit(int type, int code, int val)
> > +   {
> > +struct input_event ie;
> 
> empty line here.

Fixed.

> 
> > +memset(, 0, sizeof(ie));
> > +ie.type = type;
> > +ie.code = code;
> > +ie.value = val;
> > +
> 
> memset followed by three out of five filled in seems strange. Just add
>   ie.time.tv_sec = 0;
>   ie.time.tv_usec = 0;
> 
> ideally, with a comment that states that the timestamp is ignored :)

All the code in this doc is the result of my tests using uinput, so
somethings were set in my code some time ago and were never touched
again. Yes, this makes things a way better :)

> 
> > +if (write(fd, , sizeof(ie)) < 0) {
> > +perror("write2");
> > +exit(1);
> > +}
> > +   }
> > +
> > +   int main() {
> > +struct input_id uid;
> > +struct uinput_setup usetup;
> > +
> > +fd = open("/dev/uinput", O_WRONLY | O_NONBLOCK);
> 
> Empty line here to separate the open from the actual setup. And a comment
> explaining what this does wouldn't go amiss.

Very good, fixed here.
> 
> 
> > +ioctl(fd, UI_SET_EVBIT, EV_KEY);
> > +ioctl(fd, UI_SET_KEYBIT, KEY_SPACE);
> > +
> > +memset(, 0, sizeof(iod));
> > +memset(, 0, sizeof(usetup));
> > +usetup.id = uid;
> 
> this is a bit strange - you're memsetting the id field anyway with the
> usetup memset - it's superfluous. Given this is supposed to be example code,
> something immediately obvious would help:
>usetup.id.bustype = BUS_USB;
>usetup.id.vendor = 0x1234; /* sample vendor */

Good. Fixed.
>... 
> 
> > +strcpy(usetup.name, "ex_device");
> 
> Surely we have enough bytes to name this "Example device" for obviousness :)
Sure, fixed :)
> 
> > +
> > +ioctl(fd, UI_DEV_SETUP, );
> > +ioctl(fd, 

[PATCH] w83627ehf: Drop support for nct6775/nct6776

2017-03-22 Thread Peter Huewe
Since there exists a dedicated driver for nct6775/nct6776 it makes sense
to remove support for these chips from this driver, in order to have
only one code base for these types of chips.

This also improves maintainability and readability (and size) of this
driver.

Some not so-obvious changes are:
- removal of fan_debounce module parameter (now unused)
- removal of has_fan_div flag (nct6776 specific)
- w83627ehf_update_fan_div_common -> w83627ehf_update_fan_div
  (no distinction needed anymore)
- w83627ehf_update_pwm_common -> w83627ehf_update_pwm
  (no distinction needed anymore)
- NUM_REG_TEMP changed to ARRAY_SIZE(W83627EHF_REG_TEMP)
  (different number of max temp sensors)
- removal of intrusion1_alarm (nct6776 specific)

Tested with NCT6776F that it does not get probed anymore.

Signed-off-by: Peter Huewe 
---
Please apply after my conversion patch series.

 drivers/hwmon/w83627ehf.c | 542 --
 1 file changed, 43 insertions(+), 499 deletions(-)

diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index bba26623af36..8e7ad86422ed 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -31,8 +31,6 @@
  *  w83627uhg8  2   2   3  0xa230 0xc10x5ca3
  *  w83667hg 9  5   3   3  0xa510 0xc10x5ca3
  *  w83667hg-b   9  5   3   4  0xb350 0xc10x5ca3
- *  nct6775f 9  4   3   9  0xb470 0xc10x5ca3
- *  nct6776f 9  5   3   9  0xC330 0xc10x5ca3
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -53,7 +51,7 @@
 
 enum kinds {
w83627ehf, w83627dhg, w83627dhg_p, w83627uhg,
-   w83667hg, w83667hg_b, nct6775, nct6776,
+   w83667hg, w83667hg_b,
 };
 
 /* used to set data->name = w83627ehf_device_names[data->sio_kind] */
@@ -64,18 +62,12 @@ static const char * const w83627ehf_device_names[] = {
"w83627uhg",
"w83667hg",
"w83667hg",
-   "nct6775",
-   "nct6776",
 };
 
 static unsigned short force_id;
 module_param(force_id, ushort, 0);
 MODULE_PARM_DESC(force_id, "Override the detected device ID");
 
-static unsigned short fan_debounce;
-module_param(fan_debounce, ushort, 0);
-MODULE_PARM_DESC(fan_debounce, "Enable debouncing for fan RPM signal");
-
 #define DRVNAME "w83627ehf"
 
 /*
@@ -100,8 +92,6 @@ MODULE_PARM_DESC(fan_debounce, "Enable debouncing for fan 
RPM signal");
 #define SIO_W83627UHG_ID   0xa230
 #define SIO_W83667HG_ID0xa510
 #define SIO_W83667HG_B_ID  0xb350
-#define SIO_NCT6775_ID 0xb470
-#define SIO_NCT6776_ID 0xc330
 #define SIO_ID_MASK0xFFF0
 
 static inline void
@@ -184,11 +174,6 @@ static const u16 W83627EHF_REG_TEMP_CONFIG[] = { 0, 0x152, 
0x252, 0 };
 #define W83627EHF_REG_DIODE0x59
 #define W83627EHF_REG_SMI_OVT  0x4C
 
-/* NCT6775F has its own fan divider registers */
-#define NCT6775_REG_FANDIV10x506
-#define NCT6775_REG_FANDIV20x507
-#define NCT6775_REG_FAN_DEBOUNCE   0xf0
-
 #define W83627EHF_REG_ALARM1   0x459
 #define W83627EHF_REG_ALARM2   0x45A
 #define W83627EHF_REG_ALARM3   0x45B
@@ -232,28 +217,6 @@ static const u16 W83627EHF_REG_FAN_STEP_OUTPUT_W83667_B[]
 
 static const u16 W83627EHF_REG_TEMP_OFFSET[] = { 0x454, 0x455, 0x456 };
 
-static const u16 NCT6775_REG_TARGET[] = { 0x101, 0x201, 0x301 };
-static const u16 NCT6775_REG_FAN_MODE[] = { 0x102, 0x202, 0x302 };
-static const u16 NCT6775_REG_FAN_STOP_OUTPUT[] = { 0x105, 0x205, 0x305 };
-static const u16 NCT6775_REG_FAN_START_OUTPUT[] = { 0x106, 0x206, 0x306 };
-static const u16 NCT6775_REG_FAN_STOP_TIME[] = { 0x107, 0x207, 0x307 };
-static const u16 NCT6775_REG_PWM[] = { 0x109, 0x209, 0x309 };
-static const u16 NCT6775_REG_FAN_MAX_OUTPUT[] = { 0x10a, 0x20a, 0x30a };
-static const u16 NCT6775_REG_FAN_STEP_OUTPUT[] = { 0x10b, 0x20b, 0x30b };
-static const u16 NCT6775_REG_FAN[] = { 0x630, 0x632, 0x634, 0x636, 0x638 };
-static const u16 NCT6776_REG_FAN_MIN[] = { 0x63a, 0x63c, 0x63e, 0x640, 0x642};
-
-static const u16 NCT6775_REG_TEMP[]
-   = { 0x27, 0x150, 0x250, 0x73, 0x75, 0x77, 0x62b, 0x62c, 0x62d };
-static const u16 NCT6775_REG_TEMP_CONFIG[]
-   = { 0, 0x152, 0x252, 0, 0, 0, 0x628, 0x629, 0x62A };
-static const u16 NCT6775_REG_TEMP_HYST[]
-   = { 0x3a, 0x153, 0x253, 0, 0, 0, 0x673, 0x678, 0x67D };
-static const u16 NCT6775_REG_TEMP_OVER[]
-   = { 0x39, 0x155, 0x255, 0, 0, 0, 0x672, 0x677, 0x67C };
-static const u16 NCT6775_REG_TEMP_SOURCE[]
-   = { 0x621, 0x622, 0x623, 0x100, 0x200, 0x300, 0x624, 0x625, 0x626 };
-
 static const char *const w83667hg_b_temp_label[] = {
"SYSTIN",
"CPUTIN",
@@ -265,57 +228,7 @@ static const char *const w83667hg_b_temp_label[] = {
"PECI Agent 4"
 };
 
-static const char *const nct6775_temp_label[] = {
-   "",
-   "SYSTIN",
-   "CPUTIN",
-   "AUXTIN",
-   "AMD SB-TSI",

[PATCH] w83627ehf: Drop support for nct6775/nct6776

2017-03-22 Thread Peter Huewe
Since there exists a dedicated driver for nct6775/nct6776 it makes sense
to remove support for these chips from this driver, in order to have
only one code base for these types of chips.

This also improves maintainability and readability (and size) of this
driver.

Some not so-obvious changes are:
- removal of fan_debounce module parameter (now unused)
- removal of has_fan_div flag (nct6776 specific)
- w83627ehf_update_fan_div_common -> w83627ehf_update_fan_div
  (no distinction needed anymore)
- w83627ehf_update_pwm_common -> w83627ehf_update_pwm
  (no distinction needed anymore)
- NUM_REG_TEMP changed to ARRAY_SIZE(W83627EHF_REG_TEMP)
  (different number of max temp sensors)
- removal of intrusion1_alarm (nct6776 specific)

Tested with NCT6776F that it does not get probed anymore.

Signed-off-by: Peter Huewe 
---
Please apply after my conversion patch series.

 drivers/hwmon/w83627ehf.c | 542 --
 1 file changed, 43 insertions(+), 499 deletions(-)

diff --git a/drivers/hwmon/w83627ehf.c b/drivers/hwmon/w83627ehf.c
index bba26623af36..8e7ad86422ed 100644
--- a/drivers/hwmon/w83627ehf.c
+++ b/drivers/hwmon/w83627ehf.c
@@ -31,8 +31,6 @@
  *  w83627uhg8  2   2   3  0xa230 0xc10x5ca3
  *  w83667hg 9  5   3   3  0xa510 0xc10x5ca3
  *  w83667hg-b   9  5   3   4  0xb350 0xc10x5ca3
- *  nct6775f 9  4   3   9  0xb470 0xc10x5ca3
- *  nct6776f 9  5   3   9  0xC330 0xc10x5ca3
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -53,7 +51,7 @@
 
 enum kinds {
w83627ehf, w83627dhg, w83627dhg_p, w83627uhg,
-   w83667hg, w83667hg_b, nct6775, nct6776,
+   w83667hg, w83667hg_b,
 };
 
 /* used to set data->name = w83627ehf_device_names[data->sio_kind] */
@@ -64,18 +62,12 @@ static const char * const w83627ehf_device_names[] = {
"w83627uhg",
"w83667hg",
"w83667hg",
-   "nct6775",
-   "nct6776",
 };
 
 static unsigned short force_id;
 module_param(force_id, ushort, 0);
 MODULE_PARM_DESC(force_id, "Override the detected device ID");
 
-static unsigned short fan_debounce;
-module_param(fan_debounce, ushort, 0);
-MODULE_PARM_DESC(fan_debounce, "Enable debouncing for fan RPM signal");
-
 #define DRVNAME "w83627ehf"
 
 /*
@@ -100,8 +92,6 @@ MODULE_PARM_DESC(fan_debounce, "Enable debouncing for fan 
RPM signal");
 #define SIO_W83627UHG_ID   0xa230
 #define SIO_W83667HG_ID0xa510
 #define SIO_W83667HG_B_ID  0xb350
-#define SIO_NCT6775_ID 0xb470
-#define SIO_NCT6776_ID 0xc330
 #define SIO_ID_MASK0xFFF0
 
 static inline void
@@ -184,11 +174,6 @@ static const u16 W83627EHF_REG_TEMP_CONFIG[] = { 0, 0x152, 
0x252, 0 };
 #define W83627EHF_REG_DIODE0x59
 #define W83627EHF_REG_SMI_OVT  0x4C
 
-/* NCT6775F has its own fan divider registers */
-#define NCT6775_REG_FANDIV10x506
-#define NCT6775_REG_FANDIV20x507
-#define NCT6775_REG_FAN_DEBOUNCE   0xf0
-
 #define W83627EHF_REG_ALARM1   0x459
 #define W83627EHF_REG_ALARM2   0x45A
 #define W83627EHF_REG_ALARM3   0x45B
@@ -232,28 +217,6 @@ static const u16 W83627EHF_REG_FAN_STEP_OUTPUT_W83667_B[]
 
 static const u16 W83627EHF_REG_TEMP_OFFSET[] = { 0x454, 0x455, 0x456 };
 
-static const u16 NCT6775_REG_TARGET[] = { 0x101, 0x201, 0x301 };
-static const u16 NCT6775_REG_FAN_MODE[] = { 0x102, 0x202, 0x302 };
-static const u16 NCT6775_REG_FAN_STOP_OUTPUT[] = { 0x105, 0x205, 0x305 };
-static const u16 NCT6775_REG_FAN_START_OUTPUT[] = { 0x106, 0x206, 0x306 };
-static const u16 NCT6775_REG_FAN_STOP_TIME[] = { 0x107, 0x207, 0x307 };
-static const u16 NCT6775_REG_PWM[] = { 0x109, 0x209, 0x309 };
-static const u16 NCT6775_REG_FAN_MAX_OUTPUT[] = { 0x10a, 0x20a, 0x30a };
-static const u16 NCT6775_REG_FAN_STEP_OUTPUT[] = { 0x10b, 0x20b, 0x30b };
-static const u16 NCT6775_REG_FAN[] = { 0x630, 0x632, 0x634, 0x636, 0x638 };
-static const u16 NCT6776_REG_FAN_MIN[] = { 0x63a, 0x63c, 0x63e, 0x640, 0x642};
-
-static const u16 NCT6775_REG_TEMP[]
-   = { 0x27, 0x150, 0x250, 0x73, 0x75, 0x77, 0x62b, 0x62c, 0x62d };
-static const u16 NCT6775_REG_TEMP_CONFIG[]
-   = { 0, 0x152, 0x252, 0, 0, 0, 0x628, 0x629, 0x62A };
-static const u16 NCT6775_REG_TEMP_HYST[]
-   = { 0x3a, 0x153, 0x253, 0, 0, 0, 0x673, 0x678, 0x67D };
-static const u16 NCT6775_REG_TEMP_OVER[]
-   = { 0x39, 0x155, 0x255, 0, 0, 0, 0x672, 0x677, 0x67C };
-static const u16 NCT6775_REG_TEMP_SOURCE[]
-   = { 0x621, 0x622, 0x623, 0x100, 0x200, 0x300, 0x624, 0x625, 0x626 };
-
 static const char *const w83667hg_b_temp_label[] = {
"SYSTIN",
"CPUTIN",
@@ -265,57 +228,7 @@ static const char *const w83667hg_b_temp_label[] = {
"PECI Agent 4"
 };
 
-static const char *const nct6775_temp_label[] = {
-   "",
-   "SYSTIN",
-   "CPUTIN",
-   "AUXTIN",
-   "AMD SB-TSI",
-   "PECI 

[PATCH] hangcheck-timer: Fix typo in comment

2017-03-22 Thread Shile Zhang
Signed-off-by: Shile Zhang 
---
 drivers/char/hangcheck-timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c
index 4f33737..dcd37b1 100644
--- a/drivers/char/hangcheck-timer.c
+++ b/drivers/char/hangcheck-timer.c
@@ -32,7 +32,7 @@
  * timer and 180 seconds for the margin of error.  IOW, a timer is set
  * for 60 seconds.  When the timer fires, the callback checks the
  * actual duration that the timer waited.  If the duration exceeds the
- * alloted time and margin (here 60 + 180, or 240 seconds), the machine
+ * allowed time and margin (here 60 + 180, or 240 seconds), the machine
  * is restarted.  A healthy machine will have the duration match the
  * expected timeout very closely.
  */
-- 
2.6.2



[PATCH] hangcheck-timer: Fix typo in comment

2017-03-22 Thread Shile Zhang
Signed-off-by: Shile Zhang 
---
 drivers/char/hangcheck-timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c
index 4f33737..dcd37b1 100644
--- a/drivers/char/hangcheck-timer.c
+++ b/drivers/char/hangcheck-timer.c
@@ -32,7 +32,7 @@
  * timer and 180 seconds for the margin of error.  IOW, a timer is set
  * for 60 seconds.  When the timer fires, the callback checks the
  * actual duration that the timer waited.  If the duration exceeds the
- * alloted time and margin (here 60 + 180, or 240 seconds), the machine
+ * allowed time and margin (here 60 + 180, or 240 seconds), the machine
  * is restarted.  A healthy machine will have the duration match the
  * expected timeout very closely.
  */
-- 
2.6.2



[PATCH] hangcheck-timer: Fix typo in comment

2017-03-22 Thread Shile Zhang
Signed-off-by: Shile Zhang 
---
 drivers/char/hangcheck-timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c
index 4f33737..dcd37b1 100644
--- a/drivers/char/hangcheck-timer.c
+++ b/drivers/char/hangcheck-timer.c
@@ -32,7 +32,7 @@
  * timer and 180 seconds for the margin of error.  IOW, a timer is set
  * for 60 seconds.  When the timer fires, the callback checks the
  * actual duration that the timer waited.  If the duration exceeds the
- * alloted time and margin (here 60 + 180, or 240 seconds), the machine
+ * allowed time and margin (here 60 + 180, or 240 seconds), the machine
  * is restarted.  A healthy machine will have the duration match the
  * expected timeout very closely.
  */
-- 
2.6.2



[PATCH] hangcheck-timer: Fix typo in comment

2017-03-22 Thread Shile Zhang
Signed-off-by: Shile Zhang 
---
 drivers/char/hangcheck-timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c
index 4f33737..dcd37b1 100644
--- a/drivers/char/hangcheck-timer.c
+++ b/drivers/char/hangcheck-timer.c
@@ -32,7 +32,7 @@
  * timer and 180 seconds for the margin of error.  IOW, a timer is set
  * for 60 seconds.  When the timer fires, the callback checks the
  * actual duration that the timer waited.  If the duration exceeds the
- * alloted time and margin (here 60 + 180, or 240 seconds), the machine
+ * allowed time and margin (here 60 + 180, or 240 seconds), the machine
  * is restarted.  A healthy machine will have the duration match the
  * expected timeout very closely.
  */
-- 
2.6.2



Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

2017-03-22 Thread kbuild test robot
Hi Rick,

[auto build test ERROR on iio/togreg]
[also build test ERROR on v4.11-rc3 next-20170322]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Rick-Altherr/Documentation-dt-bindings-Document-bindings-for-Aspeed-AST2400-AST2500-ADC/20170323-093517
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

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

   drivers/iio/adc/aspeed_adc.c: In function 'aspeed_adc_read_raw':
>> drivers/iio/adc/aspeed_adc.c:100:39: error: dereferencing pointer to 
>> incomplete type 'struct clk_hw'
  *val = clk_get_rate(data->clk_scaler->clk) /
  ^~
   drivers/iio/adc/aspeed_adc.c: In function 'aspeed_adc_probe':
>> drivers/iio/adc/aspeed_adc.c:177:20: error: implicit declaration of function 
>> 'of_clk_get_parent_name' [-Werror=implicit-function-declaration]
 clk_parent_name = of_clk_get_parent_name(pdev->dev.of_node, 0);
   ^~
>> drivers/iio/adc/aspeed_adc.c:177:18: warning: assignment makes pointer from 
>> integer without a cast [-Wint-conversion]
 clk_parent_name = of_clk_get_parent_name(pdev->dev.of_node, 0);
 ^
>> drivers/iio/adc/aspeed_adc.c:179:24: error: implicit declaration of function 
>> 'clk_hw_register_divider' [-Werror=implicit-function-declaration]
 data->clk_prescaler = clk_hw_register_divider(
   ^~~
   drivers/iio/adc/aspeed_adc.c:179:22: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
 data->clk_prescaler = clk_hw_register_divider(
 ^
>> drivers/iio/adc/aspeed_adc.c:195:5: error: 'CLK_SET_RATE_PARENT' undeclared 
>> (first use in this function)
CLK_SET_RATE_PARENT,
^~~
   drivers/iio/adc/aspeed_adc.c:195:5: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/iio/adc/aspeed_adc.c:229:2: error: implicit declaration of function 
>> 'clk_hw_unregister_divider' [-Werror=implicit-function-declaration]
 clk_hw_unregister_divider(data->clk_scaler);
 ^
   cc1: some warnings being treated as errors

vim +100 drivers/iio/adc/aspeed_adc.c

94  case IIO_CHAN_INFO_SCALE:
95  *val = 2500; // mV
96  *val2 = 10;
97  return IIO_VAL_FRACTIONAL_LOG2;
98  
99  case IIO_CHAN_INFO_SAMP_FREQ:
 > 100  *val = clk_get_rate(data->clk_scaler->clk) /
   101  ASPEED_ADC_CLOCKS_PER_SAMPLE;
   102  return IIO_VAL_INT;
   103  
   104  default:
   105  return -EINVAL;
   106  }
   107  }
   108  
   109  static int aspeed_adc_write_raw(struct iio_dev *indio_dev,
   110  struct iio_chan_spec const *chan,
   111  int val, int val2, long mask)
   112  {
   113  struct aspeed_adc_data *data = iio_priv(indio_dev);
   114  
   115  switch (mask) {
   116  case IIO_CHAN_INFO_SAMP_FREQ:
   117  if (val < ASPEED_ADC_MIN_SAMP_RATE ||
   118  val > ASPEED_ADC_MAX_SAMP_RATE)
   119  return -EINVAL;
   120  
   121  clk_set_rate(data->clk_scaler->clk,
   122  val * ASPEED_ADC_CLOCKS_PER_SAMPLE);
   123  return 0;
   124  
   125  default:
   126  return -EINVAL;
   127  }
   128  }
   129  
   130  static int aspeed_adc_reg_access(struct iio_dev *indio_dev,
   131   unsigned int reg, unsigned int 
writeval,
   132   unsigned int *readval)
   133  {
   134  struct aspeed_adc_data *data = iio_priv(indio_dev);
   135  
   136  if (!readval || reg % 4 || reg > ASPEED_ADC_REG_MAX)
   137  return -EINVAL;
   138  
   139  *readval = readl(data->base + reg);
   140  return 0;
   141  }
   142  
   143  static const struct iio_info aspeed_adc_iio_info = {
   144  .driver_module = THIS_MODULE,
   145  .read_raw = _adc_read_raw,
   146  .write_raw = _adc_write_raw,
   147  .debugfs_reg_access = _adc_reg_access,
   148  };
   149  
   150  static int aspeed_adc_p

Re: kexec regression since 4.9 caused by efi

2017-03-22 Thread Dave Young
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:48, Dave Young  wrote:
> > On 03/20/17 at 10:14am, Dave Young wrote:
> >> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >> > >
> >> > > Matt, I think it should be fine although I think the md type checking 
> >> > > in
> >> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >> >
> >> > Could you make that a separate patch if you think of improvements
> >> > there?
> >>
> >> Duplicate the lookup function is indeed a little ugly, will do it when I
> >> have a better idea, we can leave it as is since it works.
> >
> > Matt, rethinking about this, how about doint something below, not
> > tested, just seeking for idea and opinons, in this way no need duplicate
> > a function, but there is an assumption that no overlapped mem ranges in
> > efi memmap.
> >
> > Also the case Omar reported is the esrt memory range type is
> > RUNTIME_DATA, that is a little different with the mem attribute of
> > RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
> > attribute, like bgrt in kexec reboot. Should we distinguish the two
> > cases and give out some warnings or debug info?
> >
> >
> > ---
> >  arch/x86/platform/efi/quirks.c |5 +
> >  drivers/firmware/efi/efi.c |6 --
> >  drivers/firmware/efi/esrt.c|7 +++
> >  3 files changed, 12 insertions(+), 6 deletions(-)
> >
> > --- linux-x86.orig/drivers/firmware/efi/efi.c
> > +++ linux-x86/drivers/firmware/efi/efi.c
> > @@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
> > u64 size;
> > u64 end;
> >
> > -   if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > -   md->type != EFI_BOOT_SERVICES_DATA &&
> > -   md->type != EFI_RUNTIME_SERVICES_DATA) {
> > -   continue;
> > -   }
> > -
> > size = md->num_pages << EFI_PAGE_SHIFT;
> > end = md->phys_addr + size;
> > if (phys_addr >= md->phys_addr && phys_addr < end) {
> > --- linux-x86.orig/drivers/firmware/efi/esrt.c
> > +++ linux-x86/drivers/firmware/efi/esrt.c
> > @@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
> > return;
> > }
> >
> > +   if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > + md->type != EFI_BOOT_SERVICES_DATA &&
> > + md->type != EFI_RUNTIME_SERVICES_DATA) {
> > +   pr_err("ESRT header memory map type is invalid\n");
> > +   return;
> > +   }
> > +
> 
> This looks wrong to me. While the meanings get convoluted in practice,
> the EFI_MEMORY_RUNTIME attribute only means that the firmware requests
> a virtual mapping for the region. It is perfectly legal for a
> EFI_RUNTIME_SERVICES_DATA region not to have the EFI_MEMORY_RUNTIME
> attribute, if the region is never accessed by the runtime services
> themselves, and this is not entirely unlikely for tables that the
> firmware exposes to the OS

Thanks for the comment, if so "!(md->attribute & EFI_MEMORY_RUNTIME) &&"
should be dropped.

BTW, md->type should be md.type, bgrt reserving works fine with this
change but I have no esrt machine to test it. I would like to wait for
Matt's opinions about this first before an update. 

Also cc Peter about the esrt piece.
> 
> > max = efi_mem_desc_end();
> > if (max < efi.esrt) {
> > pr_err("EFI memory descriptor is invalid. (esrt: %p max: 
> > %p)\n",
> > --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> > +++ linux-x86/arch/x86/platform/efi/quirks.c
> > @@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
> > return;
> > }
> >
> > +   if (md->attribute & EFI_MEMORY_RUNTIME ||
> > + md->type != EFI_BOOT_SERVICES_DATA) {
> > +   return;
> > +   }
> > +
> > size += addr % EFI_PAGE_SIZE;
> > size = round_up(size, EFI_PAGE_SIZE);
> > addr = round_down(addr, EFI_PAGE_SIZE);
> >
> >>
> >> >
> >> > > How about move the if chunk early like below because it seems no need
> >> > > to sanity check the addr + size any more if the md is still RUNTIME?
> >> >
> >> > My original version did as you suggest, but I changed it because we
> >> > *really* want to know if someone tries to reserve a range that spans
> >> > regions. That would be totally unexpected and a warning about a
> >> > potential bug/issue.
> >>
> >> Matt, I'm fine if you prefer to capture the range checking errors.
> >> Would you like me to post it or just you send it out?
> >>
> >> Thanks
> >> Dave
> >
> > Thanks
> > Dave
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

2017-03-22 Thread kbuild test robot
Hi Rick,

[auto build test ERROR on iio/togreg]
[also build test ERROR on v4.11-rc3 next-20170322]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Rick-Altherr/Documentation-dt-bindings-Document-bindings-for-Aspeed-AST2400-AST2500-ADC/20170323-093517
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

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

   drivers/iio/adc/aspeed_adc.c: In function 'aspeed_adc_read_raw':
>> drivers/iio/adc/aspeed_adc.c:100:39: error: dereferencing pointer to 
>> incomplete type 'struct clk_hw'
  *val = clk_get_rate(data->clk_scaler->clk) /
  ^~
   drivers/iio/adc/aspeed_adc.c: In function 'aspeed_adc_probe':
>> drivers/iio/adc/aspeed_adc.c:177:20: error: implicit declaration of function 
>> 'of_clk_get_parent_name' [-Werror=implicit-function-declaration]
 clk_parent_name = of_clk_get_parent_name(pdev->dev.of_node, 0);
   ^~
>> drivers/iio/adc/aspeed_adc.c:177:18: warning: assignment makes pointer from 
>> integer without a cast [-Wint-conversion]
 clk_parent_name = of_clk_get_parent_name(pdev->dev.of_node, 0);
 ^
>> drivers/iio/adc/aspeed_adc.c:179:24: error: implicit declaration of function 
>> 'clk_hw_register_divider' [-Werror=implicit-function-declaration]
 data->clk_prescaler = clk_hw_register_divider(
   ^~~
   drivers/iio/adc/aspeed_adc.c:179:22: warning: assignment makes pointer from 
integer without a cast [-Wint-conversion]
 data->clk_prescaler = clk_hw_register_divider(
 ^
>> drivers/iio/adc/aspeed_adc.c:195:5: error: 'CLK_SET_RATE_PARENT' undeclared 
>> (first use in this function)
CLK_SET_RATE_PARENT,
^~~
   drivers/iio/adc/aspeed_adc.c:195:5: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/iio/adc/aspeed_adc.c:229:2: error: implicit declaration of function 
>> 'clk_hw_unregister_divider' [-Werror=implicit-function-declaration]
 clk_hw_unregister_divider(data->clk_scaler);
 ^
   cc1: some warnings being treated as errors

vim +100 drivers/iio/adc/aspeed_adc.c

94  case IIO_CHAN_INFO_SCALE:
95  *val = 2500; // mV
96  *val2 = 10;
97  return IIO_VAL_FRACTIONAL_LOG2;
98  
99  case IIO_CHAN_INFO_SAMP_FREQ:
 > 100  *val = clk_get_rate(data->clk_scaler->clk) /
   101  ASPEED_ADC_CLOCKS_PER_SAMPLE;
   102  return IIO_VAL_INT;
   103  
   104  default:
   105  return -EINVAL;
   106  }
   107  }
   108  
   109  static int aspeed_adc_write_raw(struct iio_dev *indio_dev,
   110  struct iio_chan_spec const *chan,
   111  int val, int val2, long mask)
   112  {
   113  struct aspeed_adc_data *data = iio_priv(indio_dev);
   114  
   115  switch (mask) {
   116  case IIO_CHAN_INFO_SAMP_FREQ:
   117  if (val < ASPEED_ADC_MIN_SAMP_RATE ||
   118  val > ASPEED_ADC_MAX_SAMP_RATE)
   119  return -EINVAL;
   120  
   121  clk_set_rate(data->clk_scaler->clk,
   122  val * ASPEED_ADC_CLOCKS_PER_SAMPLE);
   123  return 0;
   124  
   125  default:
   126  return -EINVAL;
   127  }
   128  }
   129  
   130  static int aspeed_adc_reg_access(struct iio_dev *indio_dev,
   131   unsigned int reg, unsigned int 
writeval,
   132   unsigned int *readval)
   133  {
   134  struct aspeed_adc_data *data = iio_priv(indio_dev);
   135  
   136  if (!readval || reg % 4 || reg > ASPEED_ADC_REG_MAX)
   137  return -EINVAL;
   138  
   139  *readval = readl(data->base + reg);
   140  return 0;
   141  }
   142  
   143  static const struct iio_info aspeed_adc_iio_info = {
   144  .driver_module = THIS_MODULE,
   145  .read_raw = _adc_read_raw,
   146  .write_raw = _adc_write_raw,
   147  .debugfs_reg_access = _adc_reg_access,
   148  };
   149  
   150  static int aspeed_adc_p

Re: kexec regression since 4.9 caused by efi

2017-03-22 Thread Dave Young
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:48, Dave Young  wrote:
> > On 03/20/17 at 10:14am, Dave Young wrote:
> >> On 03/17/17 at 01:32pm, Matt Fleming wrote:
> >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote:
> >> > >
> >> > > Matt, I think it should be fine although I think the md type checking 
> >> > > in
> >> > > efi_mem_desc_lookup() is causing confusion and not easy to understand..
> >> >
> >> > Could you make that a separate patch if you think of improvements
> >> > there?
> >>
> >> Duplicate the lookup function is indeed a little ugly, will do it when I
> >> have a better idea, we can leave it as is since it works.
> >
> > Matt, rethinking about this, how about doint something below, not
> > tested, just seeking for idea and opinons, in this way no need duplicate
> > a function, but there is an assumption that no overlapped mem ranges in
> > efi memmap.
> >
> > Also the case Omar reported is the esrt memory range type is
> > RUNTIME_DATA, that is a little different with the mem attribute of
> > RUNTIME which also includes BOOT_DATA which has been set the RUNTIME
> > attribute, like bgrt in kexec reboot. Should we distinguish the two
> > cases and give out some warnings or debug info?
> >
> >
> > ---
> >  arch/x86/platform/efi/quirks.c |5 +
> >  drivers/firmware/efi/efi.c |6 --
> >  drivers/firmware/efi/esrt.c|7 +++
> >  3 files changed, 12 insertions(+), 6 deletions(-)
> >
> > --- linux-x86.orig/drivers/firmware/efi/efi.c
> > +++ linux-x86/drivers/firmware/efi/efi.c
> > @@ -376,12 +376,6 @@ int __init efi_mem_desc_lookup(u64 phys_
> > u64 size;
> > u64 end;
> >
> > -   if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > -   md->type != EFI_BOOT_SERVICES_DATA &&
> > -   md->type != EFI_RUNTIME_SERVICES_DATA) {
> > -   continue;
> > -   }
> > -
> > size = md->num_pages << EFI_PAGE_SHIFT;
> > end = md->phys_addr + size;
> > if (phys_addr >= md->phys_addr && phys_addr < end) {
> > --- linux-x86.orig/drivers/firmware/efi/esrt.c
> > +++ linux-x86/drivers/firmware/efi/esrt.c
> > @@ -258,6 +258,13 @@ void __init efi_esrt_init(void)
> > return;
> > }
> >
> > +   if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
> > + md->type != EFI_BOOT_SERVICES_DATA &&
> > + md->type != EFI_RUNTIME_SERVICES_DATA) {
> > +   pr_err("ESRT header memory map type is invalid\n");
> > +   return;
> > +   }
> > +
> 
> This looks wrong to me. While the meanings get convoluted in practice,
> the EFI_MEMORY_RUNTIME attribute only means that the firmware requests
> a virtual mapping for the region. It is perfectly legal for a
> EFI_RUNTIME_SERVICES_DATA region not to have the EFI_MEMORY_RUNTIME
> attribute, if the region is never accessed by the runtime services
> themselves, and this is not entirely unlikely for tables that the
> firmware exposes to the OS

Thanks for the comment, if so "!(md->attribute & EFI_MEMORY_RUNTIME) &&"
should be dropped.

BTW, md->type should be md.type, bgrt reserving works fine with this
change but I have no esrt machine to test it. I would like to wait for
Matt's opinions about this first before an update. 

Also cc Peter about the esrt piece.
> 
> > max = efi_mem_desc_end();
> > if (max < efi.esrt) {
> > pr_err("EFI memory descriptor is invalid. (esrt: %p max: 
> > %p)\n",
> > --- linux-x86.orig/arch/x86/platform/efi/quirks.c
> > +++ linux-x86/arch/x86/platform/efi/quirks.c
> > @@ -201,6 +201,11 @@ void __init efi_arch_mem_reserve(phys_ad
> > return;
> > }
> >
> > +   if (md->attribute & EFI_MEMORY_RUNTIME ||
> > + md->type != EFI_BOOT_SERVICES_DATA) {
> > +   return;
> > +   }
> > +
> > size += addr % EFI_PAGE_SIZE;
> > size = round_up(size, EFI_PAGE_SIZE);
> > addr = round_down(addr, EFI_PAGE_SIZE);
> >
> >>
> >> >
> >> > > How about move the if chunk early like below because it seems no need
> >> > > to sanity check the addr + size any more if the md is still RUNTIME?
> >> >
> >> > My original version did as you suggest, but I changed it because we
> >> > *really* want to know if someone tries to reserve a range that spans
> >> > regions. That would be totally unexpected and a warning about a
> >> > potential bug/issue.
> >>
> >> Matt, I'm fine if you prefer to capture the range checking errors.
> >> Would you like me to post it or just you send it out?
> >>
> >> Thanks
> >> Dave
> >
> > Thanks
> > Dave
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

2017-03-22 Thread Wanpeng Li
2017-03-23 2:20 GMT+08:00 Jim Mattson :
> Is cpu_has_vmx_invvpid() sufficient? This indicates support for the
> INVVPID instruction, but not necessarily any of the desired INVVPID
> types. KVM's vpid_sync_context() assumes that at least one of
> {VMX_VPID_EXTENT_SINGLE_CONTEXT, VMX_VPID_EXTENT_ALL_CONTEXT} is
> supported.

Good point, fix it in v4.

Regards,
Wanpeng Li

>
> On Wed, Mar 22, 2017 at 1:50 AM, David Hildenbrand  wrote:
>> On 22.03.2017 02:19, Wanpeng Li wrote:
>>> From: Wanpeng Li 
>>>
>>> This can be reproduced by running L2 on L1, and disable VPID on L0 if w/o
>>> commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 crash as below:
>>>
>>> KVM: entry failed, hardware error 0x7
>>> EAX= EBX= ECX= EDX=000306c3
>>> ESI= EDI= EBP= ESP=
>>> EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
>>> ES =   9300
>>> CS =f000   9b00
>>> SS =   9300
>>> DS =   9300
>>> FS =   9300
>>> GS =   9300
>>> LDT=   8200
>>> TR =   8b00
>>> GDT=  
>>> IDT=  
>>> CR0=6010 CR2= CR3= CR4=
>>> DR0= DR1= DR2= 
>>> DR3=
>>> DR6=0ff0 DR7=0400
>>> EFER=
>>>
>>> Reference SDM 30.3 INVVPID:
>>>
>>> Protected Mode Exceptions
>>> #UD
>>>   - If not in VMX operation.
>>>   - If the logical processor does not support VPIDs 
>>> (IA32_VMX_PROCBASED_CTLS2[37]=0).
>>>   - If the logical processor supports VPIDs 
>>> (IA32_VMX_PROCBASED_CTLS2[37]=1) but does
>>> not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).
>>>
>>> So we should check both VPID enable bit in vmx exec control and INVVPID 
>>> support bit
>>> in vmx capability MSRs to enable VPID. This patch adds the guarantee to not 
>>> enable VPID
>>> if INVVPID is not exposed in vmx capability MSRs.
>>>
>>> Cc: Paolo Bonzini 
>>> Cc: Radim Krčmář 
>>> Signed-off-by: Wanpeng Li 
>>> ---
>>>  arch/x86/kvm/vmx.c | 8 +++-
>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> index 8795a70..f2b912e 100644
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
>>>   return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
>>>  }
>>>
>>> +static inline bool cpu_has_vmx_invvpid(void)
>>> +{
>>> + return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
>>> +}
>>> +
>>>  static inline bool cpu_has_vmx_ept(void)
>>>  {
>>>   return vmcs_config.cpu_based_2nd_exec_ctrl &
>>> @@ -6518,8 +6523,9 @@ static __init int hardware_setup(void)
>>>   if (boot_cpu_has(X86_FEATURE_NX))
>>>   kvm_enable_efer_bits(EFER_NX);
>>>
>>> - if (!cpu_has_vmx_vpid())
>>> + if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid())
>>>   enable_vpid = 0;
>>> +
>>>   if (!cpu_has_vmx_shadow_vmcs())
>>>   enable_shadow_vmcs = 0;
>>>   if (enable_shadow_vmcs)
>>>
>>
>> Reviewed-by: David Hildenbrand 
>>
>> --
>>
>> Thanks,
>>
>> David


Re: [PATCH v3] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

2017-03-22 Thread Wanpeng Li
2017-03-23 2:20 GMT+08:00 Jim Mattson :
> Is cpu_has_vmx_invvpid() sufficient? This indicates support for the
> INVVPID instruction, but not necessarily any of the desired INVVPID
> types. KVM's vpid_sync_context() assumes that at least one of
> {VMX_VPID_EXTENT_SINGLE_CONTEXT, VMX_VPID_EXTENT_ALL_CONTEXT} is
> supported.

Good point, fix it in v4.

Regards,
Wanpeng Li

>
> On Wed, Mar 22, 2017 at 1:50 AM, David Hildenbrand  wrote:
>> On 22.03.2017 02:19, Wanpeng Li wrote:
>>> From: Wanpeng Li 
>>>
>>> This can be reproduced by running L2 on L1, and disable VPID on L0 if w/o
>>> commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 crash as below:
>>>
>>> KVM: entry failed, hardware error 0x7
>>> EAX= EBX= ECX= EDX=000306c3
>>> ESI= EDI= EBP= ESP=
>>> EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
>>> ES =   9300
>>> CS =f000   9b00
>>> SS =   9300
>>> DS =   9300
>>> FS =   9300
>>> GS =   9300
>>> LDT=   8200
>>> TR =   8b00
>>> GDT=  
>>> IDT=  
>>> CR0=6010 CR2= CR3= CR4=
>>> DR0= DR1= DR2= 
>>> DR3=
>>> DR6=0ff0 DR7=0400
>>> EFER=
>>>
>>> Reference SDM 30.3 INVVPID:
>>>
>>> Protected Mode Exceptions
>>> #UD
>>>   - If not in VMX operation.
>>>   - If the logical processor does not support VPIDs 
>>> (IA32_VMX_PROCBASED_CTLS2[37]=0).
>>>   - If the logical processor supports VPIDs 
>>> (IA32_VMX_PROCBASED_CTLS2[37]=1) but does
>>> not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).
>>>
>>> So we should check both VPID enable bit in vmx exec control and INVVPID 
>>> support bit
>>> in vmx capability MSRs to enable VPID. This patch adds the guarantee to not 
>>> enable VPID
>>> if INVVPID is not exposed in vmx capability MSRs.
>>>
>>> Cc: Paolo Bonzini 
>>> Cc: Radim Krčmář 
>>> Signed-off-by: Wanpeng Li 
>>> ---
>>>  arch/x86/kvm/vmx.c | 8 +++-
>>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> index 8795a70..f2b912e 100644
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
>>>   return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
>>>  }
>>>
>>> +static inline bool cpu_has_vmx_invvpid(void)
>>> +{
>>> + return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
>>> +}
>>> +
>>>  static inline bool cpu_has_vmx_ept(void)
>>>  {
>>>   return vmcs_config.cpu_based_2nd_exec_ctrl &
>>> @@ -6518,8 +6523,9 @@ static __init int hardware_setup(void)
>>>   if (boot_cpu_has(X86_FEATURE_NX))
>>>   kvm_enable_efer_bits(EFER_NX);
>>>
>>> - if (!cpu_has_vmx_vpid())
>>> + if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid())
>>>   enable_vpid = 0;
>>> +
>>>   if (!cpu_has_vmx_shadow_vmcs())
>>>   enable_shadow_vmcs = 0;
>>>   if (enable_shadow_vmcs)
>>>
>>
>> Reviewed-by: David Hildenbrand 
>>
>> --
>>
>> Thanks,
>>
>> David


[PATCH v4] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

2017-03-22 Thread Wanpeng Li
From: Wanpeng Li 

This can be reproduced by running L2 on L1, and disable VPID on L0 
if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 
crash as below:

KVM: entry failed, hardware error 0x7
EAX= EBX= ECX= EDX=000306c3
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   9300
CS =f000   9b00
SS =   9300
DS =   9300
FS =   9300
GS =   9300
LDT=   8200
TR =   8b00
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2= 
DR3= 
DR6=0ff0 DR7=0400
EFER=

Reference SDM 30.3 INVVPID:
 
Protected Mode Exceptions
#UD 
  - If not in VMX operation.
  - If the logical processor does not support VPIDs 
(IA32_VMX_PROCBASED_CTLS2[37]=0).
  - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) 
but does 
not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).

So we should check both VPID enable bit in vmx exec control and INVVPID support 
bit 
in vmx capability MSRs to enable VPID. This patch adds the guarantee to not 
enable VPID
if INVVPID is not exposed in vmx capability MSRs.

Reviewed-by: David Hildenbrand 
Cc: Jim Mattson 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8795a70..8925c76 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
 }
 
+static inline bool cpu_has_vmx_invvpid(void)
+{
+   return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
+}
+
 static inline bool cpu_has_vmx_ept(void)
 {
return vmcs_config.cpu_based_2nd_exec_ctrl &
@@ -6518,8 +6523,10 @@ static __init int hardware_setup(void)
if (boot_cpu_has(X86_FEATURE_NX))
kvm_enable_efer_bits(EFER_NX);
 
-   if (!cpu_has_vmx_vpid())
+   if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
+   !cpu_has_vmx_invvpid_single() || !cpu_has_vmx_invvpid_global())
enable_vpid = 0;
+
if (!cpu_has_vmx_shadow_vmcs())
enable_shadow_vmcs = 0;
if (enable_shadow_vmcs)
-- 
2.7.4



[PATCH v4] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

2017-03-22 Thread Wanpeng Li
From: Wanpeng Li 

This can be reproduced by running L2 on L1, and disable VPID on L0 
if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 
crash as below:

KVM: entry failed, hardware error 0x7
EAX= EBX= ECX= EDX=000306c3
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   9300
CS =f000   9b00
SS =   9300
DS =   9300
FS =   9300
GS =   9300
LDT=   8200
TR =   8b00
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2= 
DR3= 
DR6=0ff0 DR7=0400
EFER=

Reference SDM 30.3 INVVPID:
 
Protected Mode Exceptions
#UD 
  - If not in VMX operation.
  - If the logical processor does not support VPIDs 
(IA32_VMX_PROCBASED_CTLS2[37]=0).
  - If the logical processor supports VPIDs (IA32_VMX_PROCBASED_CTLS2[37]=1) 
but does 
not support the INVVPID instruction (IA32_VMX_EPT_VPID_CAP[32]=0).

So we should check both VPID enable bit in vmx exec control and INVVPID support 
bit 
in vmx capability MSRs to enable VPID. This patch adds the guarantee to not 
enable VPID
if INVVPID is not exposed in vmx capability MSRs.

Reviewed-by: David Hildenbrand 
Cc: Jim Mattson 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 8795a70..8925c76 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1239,6 +1239,11 @@ static inline bool cpu_has_vmx_invvpid_global(void)
return vmx_capability.vpid & VMX_VPID_EXTENT_GLOBAL_CONTEXT_BIT;
 }
 
+static inline bool cpu_has_vmx_invvpid(void)
+{
+   return vmx_capability.vpid & VMX_VPID_INVVPID_BIT;
+}
+
 static inline bool cpu_has_vmx_ept(void)
 {
return vmcs_config.cpu_based_2nd_exec_ctrl &
@@ -6518,8 +6523,10 @@ static __init int hardware_setup(void)
if (boot_cpu_has(X86_FEATURE_NX))
kvm_enable_efer_bits(EFER_NX);
 
-   if (!cpu_has_vmx_vpid())
+   if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
+   !cpu_has_vmx_invvpid_single() || !cpu_has_vmx_invvpid_global())
enable_vpid = 0;
+
if (!cpu_has_vmx_shadow_vmcs())
enable_shadow_vmcs = 0;
if (enable_shadow_vmcs)
-- 
2.7.4



Re: [PATCH] genirq: Notify clients whenever there is change in affinity

2017-03-22 Thread kbuild test robot
Hi Prasad,

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

url:
https://github.com/0day-ci/linux/commits/Prasad-Sodagudi/genirq-Notify-clients-whenever-there-is-change-in-affinity/20170323-094431
config: x86_64-randconfig-x015-201712 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   kernel/irq/migration.c: In function 'irq_move_masked_irq':
>> kernel/irq/migration.c:46:3: error: too few arguments to function 
>> 'irq_do_set_affinity'
  irq_do_set_affinity(>irq_data, desc->pending_mask, false);
  ^~~
   In file included from kernel/irq/migration.c:5:0:
   kernel/irq/internals.h:116:12: note: declared here
extern int irq_do_set_affinity(struct irq_data *data,
   ^~~

vim +/irq_do_set_affinity +46 kernel/irq/migration.c

c777ac55 Andrew Morton 2006-03-25  40* Being paranoid i guess!
e7b946e9 Eric W. Biederman 2006-10-04  41*
e7b946e9 Eric W. Biederman 2006-10-04  42* For correct operation this 
depends on the caller
e7b946e9 Eric W. Biederman 2006-10-04  43* masking the irqs.
c777ac55 Andrew Morton 2006-03-25  44*/
818b0f3b Jiang Liu 2012-03-30  45   if 
(cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids)
818b0f3b Jiang Liu 2012-03-30 @46   
irq_do_set_affinity(>irq_data, desc->pending_mask, false);
57b150cc Yinghai Lu2009-04-27  47  
7f7ace0c Mike Travis   2009-01-10  48   
cpumask_clear(desc->pending_mask);
e7b946e9 Eric W. Biederman 2006-10-04  49  }

:: The code at line 46 was first introduced by commit
:: 818b0f3bfb236ae66cac3ff38e86b9e47f24b7aa genirq: Introduce 
irq_do_set_affinity() to reduce duplicated code

:: TO: Jiang Liu <liu...@gmail.com>
:: CC: Thomas Gleixner <t...@linutronix.de>

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


.config.gz
Description: application/gzip


Re: [PATCH] genirq: Notify clients whenever there is change in affinity

2017-03-22 Thread kbuild test robot
Hi Prasad,

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

url:
https://github.com/0day-ci/linux/commits/Prasad-Sodagudi/genirq-Notify-clients-whenever-there-is-change-in-affinity/20170323-094431
config: x86_64-randconfig-x015-201712 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   kernel/irq/migration.c: In function 'irq_move_masked_irq':
>> kernel/irq/migration.c:46:3: error: too few arguments to function 
>> 'irq_do_set_affinity'
  irq_do_set_affinity(>irq_data, desc->pending_mask, false);
  ^~~
   In file included from kernel/irq/migration.c:5:0:
   kernel/irq/internals.h:116:12: note: declared here
extern int irq_do_set_affinity(struct irq_data *data,
   ^~~

vim +/irq_do_set_affinity +46 kernel/irq/migration.c

c777ac55 Andrew Morton 2006-03-25  40* Being paranoid i guess!
e7b946e9 Eric W. Biederman 2006-10-04  41*
e7b946e9 Eric W. Biederman 2006-10-04  42* For correct operation this 
depends on the caller
e7b946e9 Eric W. Biederman 2006-10-04  43* masking the irqs.
c777ac55 Andrew Morton 2006-03-25  44*/
818b0f3b Jiang Liu 2012-03-30  45   if 
(cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids)
818b0f3b Jiang Liu 2012-03-30 @46   
irq_do_set_affinity(>irq_data, desc->pending_mask, false);
57b150cc Yinghai Lu2009-04-27  47  
7f7ace0c Mike Travis   2009-01-10  48   
cpumask_clear(desc->pending_mask);
e7b946e9 Eric W. Biederman 2006-10-04  49  }

:: The code at line 46 was first introduced by commit
:: 818b0f3bfb236ae66cac3ff38e86b9e47f24b7aa genirq: Introduce 
irq_do_set_affinity() to reduce duplicated code

:: TO: Jiang Liu 
:: CC: Thomas Gleixner 

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


.config.gz
Description: application/gzip


Re: [PATCH] net: stmmac: dwmac-rk: Add handling for RGMII_ID/RXID/TXID

2017-03-22 Thread David Miller
From: Wadim Egorov 
Date: Wed, 22 Mar 2017 16:50:22 +0100

> @@ -74,6 +74,10 @@ struct rk_priv_data {
>  #define GRF_BIT(nr)  (BIT(nr) | BIT(nr+16))
>  #define GRF_CLR_BIT(nr)  (BIT(nr+16))
>  
> +#define DELAY_ENABLE(soc, tx, rx) \
> + ((tx) ? soc##_GMAC_TXCLK_DLY_ENABLE : soc##_GMAC_TXCLK_DLY_DISABLE | \
> +  (rx) ? soc##_GMAC_RXCLK_DLY_ENABLE : soc##_GMAC_RXCLK_DLY_DISABLE)

This doesn't evaluate the way you want it to.

You need to put parenthesis around both "x ? a : b" expressions.


Re: [PATCH] net: stmmac: dwmac-rk: Add handling for RGMII_ID/RXID/TXID

2017-03-22 Thread David Miller
From: Wadim Egorov 
Date: Wed, 22 Mar 2017 16:50:22 +0100

> @@ -74,6 +74,10 @@ struct rk_priv_data {
>  #define GRF_BIT(nr)  (BIT(nr) | BIT(nr+16))
>  #define GRF_CLR_BIT(nr)  (BIT(nr+16))
>  
> +#define DELAY_ENABLE(soc, tx, rx) \
> + ((tx) ? soc##_GMAC_TXCLK_DLY_ENABLE : soc##_GMAC_TXCLK_DLY_DISABLE | \
> +  (rx) ? soc##_GMAC_RXCLK_DLY_ENABLE : soc##_GMAC_RXCLK_DLY_DISABLE)

This doesn't evaluate the way you want it to.

You need to put parenthesis around both "x ? a : b" expressions.


[PATCH v3 1/3] sched/deadline: Make find_later_rq() choose a closer cpu in topology

2017-03-22 Thread Byungchul Park
When cpudl_find() returns any among free_cpus, the cpu might not be
closer than others, considering sched domain. For example:

   this_cpu: 15
   free_cpus: 0, 1,..., 14 (== later_mask)
   best_cpu: 0

   topology:

   0 --+
   +--+
   1 --+  |
  +-- ... --+
   2 --+  | |
   +--+ |
   3 --+|

   ... ...

   12 --+   |
+--+|
   13 --+  ||
   +-- ... -+
   14 --+  |
+--+
   15 --+

In this case, it would be best to select 14 since it's a free cpu and
closest to 15(this_cpu). However, currently the code select 0(best_cpu)
even though that's just any among free_cpus. Fix it.

Signed-off-by: Byungchul Park 
---
 kernel/sched/deadline.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index a2ce590..49c93b9 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1324,7 +1324,7 @@ static int find_later_rq(struct task_struct *task)
struct sched_domain *sd;
struct cpumask *later_mask = 
this_cpu_cpumask_var_ptr(local_cpu_mask_dl);
int this_cpu = smp_processor_id();
-   int best_cpu, cpu = task_cpu(task);
+   int cpu = task_cpu(task);
 
/* Make sure the mask is initialized first */
if (unlikely(!later_mask))
@@ -1337,17 +1337,14 @@ static int find_later_rq(struct task_struct *task)
 * We have to consider system topology and task affinity
 * first, then we can look for a suitable cpu.
 */
-   best_cpu = cpudl_find(_rq(task)->rd->cpudl,
-   task, later_mask);
-   if (best_cpu == -1)
+   if (cpudl_find(_rq(task)->rd->cpudl, task, later_mask) == -1)
return -1;
 
/*
-* If we are here, some target has been found,
-* the most suitable of which is cached in best_cpu.
-* This is, among the runqueues where the current tasks
-* have later deadlines than the task's one, the rq
-* with the latest possible one.
+* If we are here, some targets have been found, including
+* the most suitable which is, among the runqueues where the
+* current tasks have later deadlines than the task's one, the
+* rq with the latest possible one.
 *
 * Now we check how well this matches with task's
 * affinity and system topology.
@@ -1367,6 +1364,7 @@ static int find_later_rq(struct task_struct *task)
rcu_read_lock();
for_each_domain(cpu, sd) {
if (sd->flags & SD_WAKE_AFFINE) {
+   int closest_cpu;
 
/*
 * If possible, preempting this_cpu is
@@ -1378,14 +1376,17 @@ static int find_later_rq(struct task_struct *task)
return this_cpu;
}
 
+   closest_cpu = cpumask_first_and(later_mask,
+   sched_domain_span(sd));
/*
-* Last chance: if best_cpu is valid and is
-* in the mask, that becomes our choice.
+* Last chance: if a cpu being in both later_mask
+* and current sd span is valid, that becomes our
+* choice. Of course, the latest possible cpu is
+* already under consideration through later_mask.
 */
-   if (best_cpu < nr_cpu_ids &&
-   cpumask_test_cpu(best_cpu, sched_domain_span(sd))) {
+   if (closest_cpu < nr_cpu_ids) {
rcu_read_unlock();
-   return best_cpu;
+   return closest_cpu;
}
}
}
-- 
1.9.1



[PATCH v3 1/3] sched/deadline: Make find_later_rq() choose a closer cpu in topology

2017-03-22 Thread Byungchul Park
When cpudl_find() returns any among free_cpus, the cpu might not be
closer than others, considering sched domain. For example:

   this_cpu: 15
   free_cpus: 0, 1,..., 14 (== later_mask)
   best_cpu: 0

   topology:

   0 --+
   +--+
   1 --+  |
  +-- ... --+
   2 --+  | |
   +--+ |
   3 --+|

   ... ...

   12 --+   |
+--+|
   13 --+  ||
   +-- ... -+
   14 --+  |
+--+
   15 --+

In this case, it would be best to select 14 since it's a free cpu and
closest to 15(this_cpu). However, currently the code select 0(best_cpu)
even though that's just any among free_cpus. Fix it.

Signed-off-by: Byungchul Park 
---
 kernel/sched/deadline.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index a2ce590..49c93b9 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1324,7 +1324,7 @@ static int find_later_rq(struct task_struct *task)
struct sched_domain *sd;
struct cpumask *later_mask = 
this_cpu_cpumask_var_ptr(local_cpu_mask_dl);
int this_cpu = smp_processor_id();
-   int best_cpu, cpu = task_cpu(task);
+   int cpu = task_cpu(task);
 
/* Make sure the mask is initialized first */
if (unlikely(!later_mask))
@@ -1337,17 +1337,14 @@ static int find_later_rq(struct task_struct *task)
 * We have to consider system topology and task affinity
 * first, then we can look for a suitable cpu.
 */
-   best_cpu = cpudl_find(_rq(task)->rd->cpudl,
-   task, later_mask);
-   if (best_cpu == -1)
+   if (cpudl_find(_rq(task)->rd->cpudl, task, later_mask) == -1)
return -1;
 
/*
-* If we are here, some target has been found,
-* the most suitable of which is cached in best_cpu.
-* This is, among the runqueues where the current tasks
-* have later deadlines than the task's one, the rq
-* with the latest possible one.
+* If we are here, some targets have been found, including
+* the most suitable which is, among the runqueues where the
+* current tasks have later deadlines than the task's one, the
+* rq with the latest possible one.
 *
 * Now we check how well this matches with task's
 * affinity and system topology.
@@ -1367,6 +1364,7 @@ static int find_later_rq(struct task_struct *task)
rcu_read_lock();
for_each_domain(cpu, sd) {
if (sd->flags & SD_WAKE_AFFINE) {
+   int closest_cpu;
 
/*
 * If possible, preempting this_cpu is
@@ -1378,14 +1376,17 @@ static int find_later_rq(struct task_struct *task)
return this_cpu;
}
 
+   closest_cpu = cpumask_first_and(later_mask,
+   sched_domain_span(sd));
/*
-* Last chance: if best_cpu is valid and is
-* in the mask, that becomes our choice.
+* Last chance: if a cpu being in both later_mask
+* and current sd span is valid, that becomes our
+* choice. Of course, the latest possible cpu is
+* already under consideration through later_mask.
 */
-   if (best_cpu < nr_cpu_ids &&
-   cpumask_test_cpu(best_cpu, sched_domain_span(sd))) {
+   if (closest_cpu < nr_cpu_ids) {
rcu_read_unlock();
-   return best_cpu;
+   return closest_cpu;
}
}
}
-- 
1.9.1



Re: [PATCH] net: stmmac: add set_mac to the stmmac_ops

2017-03-22 Thread David Miller
From: Corentin Labbe 
Date: Wed, 22 Mar 2017 14:29:04 +0100

> @@ -2224,7 +,8 @@ static int stmmac_release(struct net_device *dev)
>   free_dma_desc_resources(priv);
>  
>   /* Disable the MAC Rx/Tx */
> - stmmac_set_mac(priv->ioaddr, false);
> + if (priv->hw->mac->set_mac)
> + priv->hw->mac->set_mac(priv->ioaddr, false);
>  
>   netif_carrier_off(dev);
>  
> @@ -3710,7 +3709,8 @@ int stmmac_dvr_remove(struct device *dev)
>  
>   stmmac_stop_all_dma(priv);
>  
> - stmmac_set_mac(priv->ioaddr, false);
> + if (priv->hw->mac->set_mac)
> + priv->hw->mac->set_mac(priv->ioaddr, false);
>   netif_carrier_off(ndev);
>   unregister_netdev(ndev);
>   if (priv->plat->stmmac_rst)
> @@ -3761,7 +3761,8 @@ int stmmac_suspend(struct device *dev)
>   priv->hw->mac->pmt(priv->hw, priv->wolopts);
>   priv->irq_wake = 1;
>   } else {
> - stmmac_set_mac(priv->ioaddr, false);
> + if (priv->hw->mac->set_mac)
> + priv->hw->mac->set_mac(priv->ioaddr, false);
>   pinctrl_pm_select_sleep_state(priv->device);
>   /* Disable clock in case of PWM is off */
>   clk_disable(priv->plat->pclk);

I'd say this is pretty much a required method, so it doesn't make any
sense to guard the calls with a NULL check.  Every implementation of
the MAC ops must at least set set_mac to stmmac_set_mac().

So please remove the checks, thanks.


Re: [PATCH] net: stmmac: add set_mac to the stmmac_ops

2017-03-22 Thread David Miller
From: Corentin Labbe 
Date: Wed, 22 Mar 2017 14:29:04 +0100

> @@ -2224,7 +,8 @@ static int stmmac_release(struct net_device *dev)
>   free_dma_desc_resources(priv);
>  
>   /* Disable the MAC Rx/Tx */
> - stmmac_set_mac(priv->ioaddr, false);
> + if (priv->hw->mac->set_mac)
> + priv->hw->mac->set_mac(priv->ioaddr, false);
>  
>   netif_carrier_off(dev);
>  
> @@ -3710,7 +3709,8 @@ int stmmac_dvr_remove(struct device *dev)
>  
>   stmmac_stop_all_dma(priv);
>  
> - stmmac_set_mac(priv->ioaddr, false);
> + if (priv->hw->mac->set_mac)
> + priv->hw->mac->set_mac(priv->ioaddr, false);
>   netif_carrier_off(ndev);
>   unregister_netdev(ndev);
>   if (priv->plat->stmmac_rst)
> @@ -3761,7 +3761,8 @@ int stmmac_suspend(struct device *dev)
>   priv->hw->mac->pmt(priv->hw, priv->wolopts);
>   priv->irq_wake = 1;
>   } else {
> - stmmac_set_mac(priv->ioaddr, false);
> + if (priv->hw->mac->set_mac)
> + priv->hw->mac->set_mac(priv->ioaddr, false);
>   pinctrl_pm_select_sleep_state(priv->device);
>   /* Disable clock in case of PWM is off */
>   clk_disable(priv->plat->pclk);

I'd say this is pretty much a required method, so it doesn't make any
sense to guard the calls with a NULL check.  Every implementation of
the MAC ops must at least set set_mac to stmmac_set_mac().

So please remove the checks, thanks.


Re: [PATCH 2] net: virtio_net: use new api ethtool_{get|set}_link_ksettings

2017-03-22 Thread David Miller
From: Philippe Reynes 
Date: Tue, 21 Mar 2017 23:24:24 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 
> ---
> Changelog:
> v2:
> - remove comment about the missing hardware,
>   I've tested this change with qemu

Applied.


Re: [PATCH] net: vmxnet3: use new api ethtool_{get|set}_link_ksettings

2017-03-22 Thread David Miller
From: Philippe Reynes 
Date: Wed, 22 Mar 2017 08:27:57 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


Re: [PATCH 2] net: virtio_net: use new api ethtool_{get|set}_link_ksettings

2017-03-22 Thread David Miller
From: Philippe Reynes 
Date: Tue, 21 Mar 2017 23:24:24 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 
> ---
> Changelog:
> v2:
> - remove comment about the missing hardware,
>   I've tested this change with qemu

Applied.


Re: [PATCH] net: vmxnet3: use new api ethtool_{get|set}_link_ksettings

2017-03-22 Thread David Miller
From: Philippe Reynes 
Date: Wed, 22 Mar 2017 08:27:57 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied.


  1   2   3   4   5   6   7   8   9   10   >