Re: [PATCH 1/4] w83627ehf: Use hwmon_device_register_with_info and sensor groups
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
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
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
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
[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
[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
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
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
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
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
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 RothwellSigned-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> -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
> -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
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
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
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 HeCc: 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
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
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
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
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
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
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 HerrenschmidtCc: 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
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
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
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
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 HerrenschmidtCc: 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
Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Cc: Benjamin HerrenschmidtCc: 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
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
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
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 HerrenschmidtCc: 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
Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Cc: Benjamin HerrenschmidtCc: 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
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
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
From: Sukadev Bhattiproluperf_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
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
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
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
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
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
On Tue, 21 Mar 2017 21:35:05 -0400 Steven Rostedtwrote: > 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
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
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
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
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
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
On 3/20/2017 3:15 AM, Arnd Bergmann wrote: On Sun, Mar 19, 2017 at 3:14 PM, valmikiwrote: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On 03/22/17 at 04:10pm, Ard Biesheuvel wrote: > On 21 March 2017 at 07:48, Dave Youngwrote: > > 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
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
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-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-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
From: Wanpeng LiThis 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
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
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
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
From: Wadim EgorovDate: 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
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
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
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
From: Corentin LabbeDate: 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
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
From: Philippe ReynesDate: 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
From: Philippe ReynesDate: 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
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
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.