[PATCH][v5] tools/power turbostat: if --iterations, print for specific count of iterations

From: Chen Yu There's a use case during test to only print specific round of iterations if --iterations is specified, for example, with this patch applied: turbostat -i 5 -r 4 will capture 4 samples with 5 seconds interval. Cc: Len Brown Cc: Rafael J

[PATCH][v5] tools/power turbostat: if --iterations, print for specific count of iterations

From: Chen Yu There's a use case during test to only print specific round of iterations if --iterations is specified, for example, with this patch applied: turbostat -i 5 -r 4 will capture 4 samples with 5 seconds interval. Cc: Len Brown Cc: Rafael J Wysocki Cc: Artem Bityutskiy Cc: Doug

Re: NO_HZ_FULL and tick running within a reasonable amount of time

> On Tue, Apr 03, 2018 at 10:08:58AM -0700, Paul E. McKenney wrote: > > On Tue, Apr 03, 2018 at 01:41:31PM +0200, Frederic Weisbecker wrote: > > > On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote: > > > > Hello! > > > > > > > > I am hitting the following on today's mainline under

Re: NO_HZ_FULL and tick running within a reasonable amount of time

> On Tue, Apr 03, 2018 at 10:08:58AM -0700, Paul E. McKenney wrote: > > On Tue, Apr 03, 2018 at 01:41:31PM +0200, Frederic Weisbecker wrote: > > > On Mon, Apr 02, 2018 at 03:04:38PM -0700, Paul E. McKenney wrote: > > > > Hello! > > > > > > > > I am hitting the following on today's mainline under

Re: [PATCH] x86/xen: Remove use of VLAs

On 04/13/2018 07:55 PM, David Brown wrote: On Fri, Apr 13, 2018 at 03:11:46PM -0700, Laura Abbott wrote: There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. The few VLAs in use have an upper bound based on a size of 64K. This doesn't produce an excessively

Re: [PATCH] x86/xen: Remove use of VLAs

On 04/13/2018 07:55 PM, David Brown wrote: On Fri, Apr 13, 2018 at 03:11:46PM -0700, Laura Abbott wrote: There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. The few VLAs in use have an upper bound based on a size of 64K. This doesn't produce an excessively

Re: [PATCH] staging fbtft: Fixed lines exceeding columns limit

On Fri, Apr 13, 2018 at 03:57:47PM +0300, Dan Carpenter wrote: > > - ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0); > > \ > > I feel like the original is basically OK but if we're going to change it > then align it like this: > > ret = fbtft_write_buf_dc(par,

Re: [PATCH] staging fbtft: Fixed lines exceeding columns limit

On Fri, Apr 13, 2018 at 03:57:47PM +0300, Dan Carpenter wrote: > > - ret = fbtft_write_buf_dc(par, par->buf, sizeof(data_type) + offset, 0); > > \ > > I feel like the original is basically OK but if we're going to change it > then align it like this: > > ret = fbtft_write_buf_dc(par,

[PATCH 1/1] dts: qcom: db820c: Add gpio-line-names property

Add gpio-line-names property for Dragonboard820c based on APQ8096 SoC. There are 4 gpio-controllers present on this board, including the APQ8096 SoC, PM8994 (GPIO and MPP) and PMI8994 (GPIO). Lines names are derived from 96Boards CE Specification 1.0, Appendix "Expansion Connector Signal

[PATCH 0/1] Add gpio-line-names property for Dragonboard820c

Add gpio-line-names property for 96Boards Dragonboard820c development board based on APQ8096 SoC. The lines are named after the 96Boards CE Specification 1.0, Appendix "Expansion Connector Signal Description". There are 4 gpio-controllers present on this board, including the APQ8096 SoC, PM8994

[PATCH 1/1] dts: qcom: db820c: Add gpio-line-names property

Add gpio-line-names property for Dragonboard820c based on APQ8096 SoC. There are 4 gpio-controllers present on this board, including the APQ8096 SoC, PM8994 (GPIO and MPP) and PMI8994 (GPIO). Lines names are derived from 96Boards CE Specification 1.0, Appendix "Expansion Connector Signal

[PATCH 0/1] Add gpio-line-names property for Dragonboard820c

Add gpio-line-names property for 96Boards Dragonboard820c development board based on APQ8096 SoC. The lines are named after the 96Boards CE Specification 1.0, Appendix "Expansion Connector Signal Description". There are 4 gpio-controllers present on this board, including the APQ8096 SoC, PM8994

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On Fri, 2018-04-13 at 18:04 +0200, Paolo Bonzini wrote: > On 13/04/2018 18:02, Jim Mattson wrote: > > > > On Fri, Apr 13, 2018 at 4:23 AM, Paolo Bonzini wrote: > > > > > > From: KarimAllah Ahmed > > > > > > Update 'tsc_offset' on vmenty/vmexit of L2

Re: [PATCH 1/2] X86/KVM: Properly update 'tsc_offset' to represent the running guest

On Fri, 2018-04-13 at 18:04 +0200, Paolo Bonzini wrote: > On 13/04/2018 18:02, Jim Mattson wrote: > > > > On Fri, Apr 13, 2018 at 4:23 AM, Paolo Bonzini wrote: > > > > > > From: KarimAllah Ahmed > > > > > > Update 'tsc_offset' on vmenty/vmexit of L2 guests to ensure that it always > > >

[PATCH v4] X86/KVM: Properly update 'tsc_offset' to represent the running guest

Update 'tsc_offset' on vmentry/vmexit of L2 guests to ensure that it always captures the TSC_OFFSET of the running guest whether it is the L1 or L2 guest. Cc: Jim Mattson Cc: Paolo Bonzini Cc: Radim Krčmář Cc: k...@vger.kernel.org

[PATCH v4] X86/KVM: Properly update 'tsc_offset' to represent the running guest

Update 'tsc_offset' on vmentry/vmexit of L2 guests to ensure that it always captures the TSC_OFFSET of the running guest whether it is the L1 or L2 guest. Cc: Jim Mattson Cc: Paolo Bonzini Cc: Radim Krčmář Cc: k...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Suggested-by: Paolo Bonzini

[PATCH 2/2] printk: wake up klogd in vprintk_emit

We wake up klogd very late - only when current console_sem owner is done pushing pending kernel messages to the serial/net consoles. In some cases this results in lost syslog messages, because kernel log buffer is a circular buffer and if we don't wakeup syslog long enough there are chances that

[PATCH 2/2] printk: wake up klogd in vprintk_emit

We wake up klogd very late - only when current console_sem owner is done pushing pending kernel messages to the serial/net consoles. In some cases this results in lost syslog messages, because kernel log buffer is a circular buffer and if we don't wakeup syslog long enough there are chances that

[PATCH 1/2] vsprintf: Tweak pF/pf comment

Reflect changes that have happened to pf/pF (deprecation) specifiers in pointer() comment section. Signed-off-by: Sergey Senozhatsky --- lib/vsprintf.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c

[PATCH 1/2] vsprintf: Tweak pF/pf comment

Reflect changes that have happened to pf/pF (deprecation) specifiers in pointer() comment section. Signed-off-by: Sergey Senozhatsky --- lib/vsprintf.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index

Re: [PATCH] x86/xen: Remove use of VLAs

On Fri, Apr 13, 2018 at 03:11:46PM -0700, Laura Abbott wrote: There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. The few VLAs in use have an upper bound based on a size of 64K. This doesn't produce an excessively large stack so just switch the upper bound.

Re: [PATCH] x86/xen: Remove use of VLAs

On Fri, Apr 13, 2018 at 03:11:46PM -0700, Laura Abbott wrote: There's an ongoing effort to remove VLAs[1] from the kernel to eventually turn on -Wvla. The few VLAs in use have an upper bound based on a size of 64K. This doesn't produce an excessively large stack so just switch the upper bound.

[PATCH v2 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine

[PATCH v2 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

Introduce bindings for RPMh regulator devices found on some Qualcomm Technlogies, Inc. SoCs. These devices allow a given processor within the SoC to make PMIC regulator requests which are aggregated within the RPMh hardware block along with requests from other processors in the SoC to determine

[PATCH v2 0/2] regulator: add QCOM RPMh regulator driver

Hello, This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage

[PATCH v2 0/2] regulator: add QCOM RPMh regulator driver

Hello, This patch series adds a driver and device tree binding documentation for PMIC regulator control via Resource Power Manager-hardened (RPMh) on some Qualcomm Technologies, Inc. SoCs such as SDM845. RPMh is a hardware block which contains several accelerators which are used to manage

[PATCH v2 2/2] regulator: add QCOM RPMh regulator driver

Add the QCOM RPMh regulator driver to manage PMIC regulators which are controlled via RPMh on some Qualcomm Technologies, Inc. SoCs. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC.

[PATCH v2 2/2] regulator: add QCOM RPMh regulator driver

Add the QCOM RPMh regulator driver to manage PMIC regulators which are controlled via RPMh on some Qualcomm Technologies, Inc. SoCs. RPMh is a hardware block which contains several accelerators which are used to manage various hardware resources that are shared between the processors of the SoC.

[PATCH] gpu/drm/amd/amdkfd: fix build, select MMU_NOTIFIER

From: Randy Dunlap When CONFIG_MMU_NOTIFIER is not enabled, struct mmu_notifier has an incomplete type definition, which causes build errors. ../drivers/gpu/drm/amd/amdkfd/kfd_priv.h:607:22: error: field 'mmu_notifier' has incomplete type

[PATCH] gpu/drm/amd/amdkfd: fix build, select MMU_NOTIFIER

From: Randy Dunlap When CONFIG_MMU_NOTIFIER is not enabled, struct mmu_notifier has an incomplete type definition, which causes build errors. ../drivers/gpu/drm/amd/amdkfd/kfd_priv.h:607:22: error: field 'mmu_notifier' has incomplete type ../include/linux/kernel.h:979:32: error: dereferencing

[PATCH v3 2/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Add the RPMh clock driver to control the RPMh managed clock resources on some of the Qualcomm Technologies, Inc. SoCs. Signed-off-by: David Collins Signed-off-by: Amit Nischal --- drivers/clk/qcom/Kconfig| 9 ++ drivers/clk/qcom/Makefile

[PATCH v3 2/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Add the RPMh clock driver to control the RPMh managed clock resources on some of the Qualcomm Technologies, Inc. SoCs. Signed-off-by: David Collins Signed-off-by: Amit Nischal --- drivers/clk/qcom/Kconfig| 9 ++ drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/clk-rpmh.c | 367

[PATCH v3 0/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

[v3] * Addressed documentation & code review comments from Bjorn * Addressed bindings comments from Rob * Updated the patch series order for bindings [v2] * Addressed comments from Stephen * Addressed comments from Evan This patch series adds a driver and device tree documentation

[PATCH v3 1/2] dt-bindings: clock: Introduce QCOM RPMh clock bindings

Add RPMh clock device bindings for Qualcomm Technology Inc's SoCs. These devices would be used for communicating resource state requests to control the clocks managed by RPMh. Signed-off-by: Amit Nischal Signed-off-by: Taniya Das ---

[PATCH v3 1/2] dt-bindings: clock: Introduce QCOM RPMh clock bindings

Add RPMh clock device bindings for Qualcomm Technology Inc's SoCs. These devices would be used for communicating resource state requests to control the clocks managed by RPMh. Signed-off-by: Amit Nischal Signed-off-by: Taniya Das --- .../devicetree/bindings/clock/qcom,rpmh-clk.txt| 22

[PATCH v3 0/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

[v3] * Addressed documentation & code review comments from Bjorn * Addressed bindings comments from Rob * Updated the patch series order for bindings [v2] * Addressed comments from Stephen * Addressed comments from Evan This patch series adds a driver and device tree documentation

Re: [PATCH] printk: Ratelimit messages printed by console drivers

On (04/13/18 10:12), Steven Rostedt wrote: > > > The interval is set to one hour. It is rather arbitrary selected time. > > It is supposed to be a compromise between never print these messages, > > do not lockup the machine, do not fill the entire buffer too quickly, > > and get information if

Re: [PATCH] printk: Ratelimit messages printed by console drivers

On (04/13/18 10:12), Steven Rostedt wrote: > > > The interval is set to one hour. It is rather arbitrary selected time. > > It is supposed to be a compromise between never print these messages, > > do not lockup the machine, do not fill the entire buffer too quickly, > > and get information if

Hello Dear

Hi,How are you? I must confess that you're a nice looking gentle man on your profile.Are you married?, Can we be friends? Susan

Hello Dear

Hi,How are you? I must confess that you're a nice looking gentle man on your profile.Are you married?, Can we be friends? Susan

Re: [[PATCH v2] 1/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Hello Bjorn, Thank you for the review comments. On 4/10/2018 11:09 PM, Bjorn Andersson wrote: On Sun 08 Apr 03:32 PDT 2018, Taniya Das wrote: From: Amit Nischal Add the RPMh clock driver to control the RPMh managed clock resources on some of the Qualcomm

Re: [[PATCH v2] 1/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Hello Bjorn, Thank you for the review comments. On 4/10/2018 11:09 PM, Bjorn Andersson wrote: On Sun 08 Apr 03:32 PDT 2018, Taniya Das wrote: From: Amit Nischal Add the RPMh clock driver to control the RPMh managed clock resources on some of the Qualcomm Technologies, Inc. SoCs.

Re: [[PATCH v2] 2/2] dt-bindings: clock: Introduce QCOM RPMh clock bindings

Hello Bjorn, Thanks for your review comments. On 4/10/2018 4:28 AM, Bjorn Andersson wrote: On Sun 08 Apr 03:32 PDT 2018, Taniya Das wrote: From: Amit Nischal Add RPMh clock device bindings for Qualcomm Technology Inc's SoCs. These devices would be used for

Re: [[PATCH v2] 1/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Hello Rob, Thank you for the review comments. On 4/13/2018 10:07 PM, Rob Herring wrote: On Sun, Apr 08, 2018 at 04:02:12PM +0530, Taniya Das wrote: From: Amit Nischal Add the RPMh clock driver to control the RPMh managed clock resources on some of the Qualcomm

Re: [[PATCH v2] 2/2] dt-bindings: clock: Introduce QCOM RPMh clock bindings

Hello Bjorn, Thanks for your review comments. On 4/10/2018 4:28 AM, Bjorn Andersson wrote: On Sun 08 Apr 03:32 PDT 2018, Taniya Das wrote: From: Amit Nischal Add RPMh clock device bindings for Qualcomm Technology Inc's SoCs. These devices would be used for communicating resource state

Re: [[PATCH v2] 1/2] clk: qcom: clk-rpmh: Add QCOM RPMh clock driver

Hello Rob, Thank you for the review comments. On 4/13/2018 10:07 PM, Rob Herring wrote: On Sun, Apr 08, 2018 at 04:02:12PM +0530, Taniya Das wrote: From: Amit Nischal Add the RPMh clock driver to control the RPMh managed clock resources on some of the Qualcomm Technologies, Inc. SoCs.

issues with suspend on Dell XPS 13 2-in-1

Hi All, I have a Dell XPS 13 2-in-1 (9365) that when I supend gets warm and has much shorter than expected battery life, it is about the same as if the laptop just runs. I am currently running Fedora 28 with 4.16.2 kernel. My laptop has NVMe for storage and is configured for AHCI mode in the

issues with suspend on Dell XPS 13 2-in-1

Hi All, I have a Dell XPS 13 2-in-1 (9365) that when I supend gets warm and has much shorter than expected battery life, it is about the same as if the laptop just runs. I am currently running Fedora 28 with 4.16.2 kernel. My laptop has NVMe for storage and is configured for AHCI mode in the

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

On Wed, Apr 11, 2018 at 10:53:13AM -0400, Dennis Dalessandro wrote: > On 4/11/2018 3:32 AM, Jia-Ju Bai wrote: > > i40iw_add_mqh_4() is never called in atomic context, because it > > calls rtnl_lock() that can sleep. > > > > Despite never getting called from atomic context, > > i40iw_add_mqh_4()

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

On Wed, Apr 11, 2018 at 10:53:13AM -0400, Dennis Dalessandro wrote: > On 4/11/2018 3:32 AM, Jia-Ju Bai wrote: > > i40iw_add_mqh_4() is never called in atomic context, because it > > calls rtnl_lock() that can sleep. > > > > Despite never getting called from atomic context, > > i40iw_add_mqh_4()

Re: [PATCH 3/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_l2param_change

On Wed, Apr 11, 2018 at 03:33:06PM +0800, Jia-Ju Bai wrote: > i40iw_l2param_change() is never called in atomic context. > > i40iw_make_listen_node() is only set as ".l2_param_change" > in struct i40e_client_ops, and this function pointer is not called > in atomic context. > > Despite never

Re: [PATCH 3/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_l2param_change

On Wed, Apr 11, 2018 at 03:33:06PM +0800, Jia-Ju Bai wrote: > i40iw_l2param_change() is never called in atomic context. > > i40iw_make_listen_node() is only set as ".l2_param_change" > in struct i40e_client_ops, and this function pointer is not called > in atomic context. > > Despite never

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

On Wed, Apr 11, 2018 at 03:32:25PM +0800, Jia-Ju Bai wrote: > i40iw_add_mqh_4() is never called in atomic context, because it > calls rtnl_lock() that can sleep. > > Despite never getting called from atomic context, > i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC, > which does not sleep for

Re: [PATCH 1/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_add_mqh_4

On Wed, Apr 11, 2018 at 03:32:25PM +0800, Jia-Ju Bai wrote: > i40iw_add_mqh_4() is never called in atomic context, because it > calls rtnl_lock() that can sleep. > > Despite never getting called from atomic context, > i40iw_add_mqh_4() calls kzalloc() with GFP_ATOMIC, > which does not sleep for

Re: [PATCH 2/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_make_listen_node

On Wed, Apr 11, 2018 at 03:32:48PM +0800, Jia-Ju Bai wrote: > i40iw_make_listen_node() is never called in atomic context. > > i40iw_make_listen_node() is only called by i40iw_create_listen, which is > set as ".create_listen" in struct iw_cm_verbs. > > Despite never getting called from atomic

Re: [PATCH 2/3] infiniband: i40iw: Replace GFP_ATOMIC with GFP_KERNEL in i40iw_make_listen_node

On Wed, Apr 11, 2018 at 03:32:48PM +0800, Jia-Ju Bai wrote: > i40iw_make_listen_node() is never called in atomic context. > > i40iw_make_listen_node() is only called by i40iw_create_listen, which is > set as ".create_listen" in struct iw_cm_verbs. > > Despite never getting called from atomic

Re: general protection fault in vmx_vcpu_run

: https://syzkaller.appspot.com/x/.config?id=-5947642240294114534 compiler: gcc (GCC) 8.0.1 20180413 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+cc483201a3c6436d3...@syzkaller.appspotmail.com It will help syzbot understand when the bug

Re: general protection fault in vmx_vcpu_run

: https://syzkaller.appspot.com/x/.config?id=-5947642240294114534 compiler: gcc (GCC) 8.0.1 20180413 (experimental) IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+cc483201a3c6436d3...@syzkaller.appspotmail.com It will help syzbot understand when the bug

Re: [PATCH 3/3] x86/MCE/AMD: Get address from already initialized block

On 2018 Feb 01, Yazen Ghannam wrote: > From: Yazen Ghannam > > The block address is saved after the block is initialized when > threshold_init_device() is called. > > Use the saved block address, if available, rather than trying to > rediscover it. > > We can avoid some

Re: [PATCH 3/3] x86/MCE/AMD: Get address from already initialized block

On 2018 Feb 01, Yazen Ghannam wrote: > From: Yazen Ghannam > > The block address is saved after the block is initialized when > threshold_init_device() is called. > > Use the saved block address, if available, rather than trying to > rediscover it. > > We can avoid some *on_cpu() calls in the

Re: [PATCH v2 1/2] gpio: dwapb: Add support for 1 interrupt per port A GPIO

Hi Phil, Thank you for the patch! Yet something to improve: [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.16 next-20180413] [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

Re: [PATCH v2 1/2] gpio: dwapb: Add support for 1 interrupt per port A GPIO

Hi Phil, Thank you for the patch! Yet something to improve: [auto build test ERROR on gpio/for-next] [also build test ERROR on v4.16 next-20180413] [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

mmotm 2018-04-13-17-28 uploaded

The mm-of-the-moment snapshot 2018-04-13-17-28 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2018-04-13-17-28 uploaded

The mm-of-the-moment snapshot 2018-04-13-17-28 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

RE: [Resend Patch 3/3] Storvsc: Select channel based on available percentage of ring buffer to write

> Subject: RE: [Resend Patch 3/3] Storvsc: Select channel based on available > percentage of ring buffer to write > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org > > On Behalf Of Long Li > > Sent: Tuesday, March 27, 2018 5:49 PM >

RE: [Resend Patch 3/3] Storvsc: Select channel based on available percentage of ring buffer to write

> Subject: RE: [Resend Patch 3/3] Storvsc: Select channel based on available > percentage of ring buffer to write > > > -Original Message- > > From: linux-kernel-ow...@vger.kernel.org > > On Behalf Of Long Li > > Sent: Tuesday, March 27, 2018 5:49 PM > > To: KY Srinivasan ; Haiyang Zhang

Re: [PATCH v3 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote: >  > + > +void amd_iommu_debugfs_setup(struct amd_iommu *iommu) > +{ > + char name[MAX_NAME_LEN + 1]; > + struct dentry *d_top; > + > + if (!debugfs_initialized()) Probably not needed. > + return; > + > +

Re: [PATCH v3 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote: >  > + > +void amd_iommu_debugfs_setup(struct amd_iommu *iommu) > +{ > + char name[MAX_NAME_LEN + 1]; > + struct dentry *d_top; > + > + if (!debugfs_initialized()) Probably not needed. > + return; > + > +

Re: [RFC PATCH v2 3/6] sched: Add over-utilization/tipping point indicator

Hi, On Fri, Apr 6, 2018 at 8:36 AM, Dietmar Eggemann wrote: > From: Thara Gopinath > > Energy-aware scheduling should only operate when the system is not > overutilized. There must be cpu time available to place tasks based on > utilization

Re: [RFC PATCH v2 3/6] sched: Add over-utilization/tipping point indicator

Hi, On Fri, Apr 6, 2018 at 8:36 AM, Dietmar Eggemann wrote: > From: Thara Gopinath > > Energy-aware scheduling should only operate when the system is not > overutilized. There must be cpu time available to place tasks based on > utilization in an energy-aware fashion, i.e. to pack tasks on >

Re: [PATCH v3 1/2] iommu - Enable debugfs exposure of the IOMMU

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote: >  >  > +struct dentry *iommu_debugfs_setup(void) > +{ > + if (!debugfs_initialized()) This check is probably not needed. > + return NULL; > + > + if (!iommu_debugfs_dir) > + iommu_debugfs_dir =

Re: [PATCH v3 1/2] iommu - Enable debugfs exposure of the IOMMU

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote: >  >  > +struct dentry *iommu_debugfs_setup(void) > +{ > + if (!debugfs_initialized()) This check is probably not needed. > + return NULL; > + > + if (!iommu_debugfs_dir) > + iommu_debugfs_dir =

Re: [PATCH] cifs: smb2ops: Fix NULL check in smb2_query_symlink

2018-04-13 8:13 GMT-07:00 Gustavo A. R. Silva : > The current code null checks variable err_buf, which is always null > when it is checked, hence utf16_path is free'd and the function > returns -ENOENT everytime it is called, making it impossible for the > execution path to

Re: [PATCH] cifs: smb2ops: Fix NULL check in smb2_query_symlink

2018-04-13 8:13 GMT-07:00 Gustavo A. R. Silva : > The current code null checks variable err_buf, which is always null > when it is checked, hence utf16_path is free'd and the function > returns -ENOENT everytime it is called, making it impossible for the > execution path to reach the following

Re: [PATCH v4 2/2] MIPS: io: add a barrier after register read in readX()

On Thu, Apr 12, 2018 at 10:33:42PM -0400, Sinan Kaya wrote: > On 4/12/2018 10:30 PM, Sinan Kaya wrote: > > + /* prevent prefetching of coherent DMA dma prematurely */ \ > > I tried to write DMA data but my keyboard is not cooperating. I'll hold onto > posting another version until I hear

Re: [PATCH v4 2/2] MIPS: io: add a barrier after register read in readX()

On Thu, Apr 12, 2018 at 10:33:42PM -0400, Sinan Kaya wrote: > On 4/12/2018 10:30 PM, Sinan Kaya wrote: > > + /* prevent prefetching of coherent DMA dma prematurely */ \ > > I tried to write DMA data but my keyboard is not cooperating. I'll hold onto > posting another version until I hear

Re: [PATCH] virtio_balloon: add array of stat names

On 04/13/2018 03:07 PM, Michael S. Tsirkin wrote: On Fri, Apr 13, 2018 at 11:53:31AM -0700, Jonathan Helman wrote: On 04/13/2018 06:44 AM, Michael S. Tsirkin wrote: Jason Wang points out that it's vary hard for users to build an array of s/vary/very stat names. The naive thing is to

Re: [PATCH] virtio_balloon: add array of stat names

On 04/13/2018 03:07 PM, Michael S. Tsirkin wrote: On Fri, Apr 13, 2018 at 11:53:31AM -0700, Jonathan Helman wrote: On 04/13/2018 06:44 AM, Michael S. Tsirkin wrote: Jason Wang points out that it's vary hard for users to build an array of s/vary/very stat names. The naive thing is to

RE: [Resend Patch 2/3] Netvsc: Use the vmbus functiton to calculate ring buffer percentage

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > On Behalf > Of Long Li > Sent: Tuesday, March 27, 2018 5:49 PM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen > Hemminger

RE: [Resend Patch 2/3] Netvsc: Use the vmbus functiton to calculate ring buffer percentage

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > On Behalf > Of Long Li > Sent: Tuesday, March 27, 2018 5:49 PM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen > Hemminger ; James E . J . Bottomley > ; > Martin K . Petersen ; > de...@linuxdriverproject.org; linux- >

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

On Fri, Apr 13, 2018 at 11:49 AM, Jean Delvare wrote: > On Fri, 13 Apr 2018 09:02:03 -0700, Sam Hansen wrote: >> On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare wrote: >> > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: >> >> On Thu, Apr 12, 2018 at

Re: [PATCH] Documentation/i2c: sync docs with current state of i2c-tools.

On Fri, Apr 13, 2018 at 11:49 AM, Jean Delvare wrote: > On Fri, 13 Apr 2018 09:02:03 -0700, Sam Hansen wrote: >> On Fri, Apr 13, 2018 at 5:13 AM, Jean Delvare wrote: >> > On Fri, 13 Apr 2018 00:24:57 +0200, Wolfram Sang wrote: >> >> On Thu, Apr 12, 2018 at 02:33:42PM -0700, Sam Hansen wrote: >>

Re: [GIT PULL] chrome-platform updates for v4.17

On Fri, Apr 13, 2018 at 04:26:41PM -0700, Linus Torvalds wrote: > Please don't do this to me. > > You're sending me a pull request in the second half of the second week > of the merge window, and none of this has been in linux-next as far as > I can tell. > > I don't even check linux-next as of

Re: [GIT PULL] chrome-platform updates for v4.17

On Fri, Apr 13, 2018 at 04:26:41PM -0700, Linus Torvalds wrote: > Please don't do this to me. > > You're sending me a pull request in the second half of the second week > of the merge window, and none of this has been in linux-next as far as > I can tell. > > I don't even check linux-next as of

RE: [Resend Patch 3/3] Storvsc: Select channel based on available percentage of ring buffer to write

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > On Behalf > Of Long Li > Sent: Tuesday, March 27, 2018 5:49 PM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen > Hemminger

RE: [Resend Patch 3/3] Storvsc: Select channel based on available percentage of ring buffer to write

> -Original Message- > From: linux-kernel-ow...@vger.kernel.org > On Behalf > Of Long Li > Sent: Tuesday, March 27, 2018 5:49 PM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen > Hemminger ; James E . J . Bottomley > ; > Martin K . Petersen ; > de...@linuxdriverproject.org; linux- >

Re: [GIT PULL] chrome-platform updates for v4.17

On Thu, Apr 12, 2018 at 3:21 PM, Benson Leung wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git > tags/chrome-platform-for-linus-4.17 Please don't do this to me. You're sending me a pull request in the second half of the second week of the

Re: [GIT PULL] chrome-platform updates for v4.17

On Thu, Apr 12, 2018 at 3:21 PM, Benson Leung wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git > tags/chrome-platform-for-linus-4.17 Please don't do this to me. You're sending me a pull request in the second half of the second week of the merge window, and

Re: [PATCH v4 2/2] drivers: soc: Add LLCC driver

On 2018-04-12 15:02, Evan Green wrote: Hi Rishabh, On Tue, Apr 10, 2018 at 1:09 PM Rishabh Bhatnagar wrote: LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into multiple slices and each slice gets its own

Re: [PATCH v4 2/2] drivers: soc: Add LLCC driver

On 2018-04-12 15:02, Evan Green wrote: Hi Rishabh, On Tue, Apr 10, 2018 at 1:09 PM Rishabh Bhatnagar wrote: LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into multiple slices and each slice gets its own priority, size, ID and other

Re: [GIT PULL] auxdisplay for v4.17-rc1

On Thu, Apr 12, 2018 at 11:37 AM, Miguel Ojeda wrote: > > Please pull these fixes and cleanups for auxdisplay. As far as I can tell, none of this has been in linux-next. By the end of the merge window, I styart getting a whole lot more anal about what I pull. In

Re: [GIT PULL] auxdisplay for v4.17-rc1

On Thu, Apr 12, 2018 at 11:37 AM, Miguel Ojeda wrote: > > Please pull these fixes and cleanups for auxdisplay. As far as I can tell, none of this has been in linux-next. By the end of the merge window, I styart getting a whole lot more anal about what I pull. In particular, if people send me

Re: [PATCH v8 15/18] mm, fs, dax: handle layout changes to pinned dax mappings

On Fri, Apr 13, 2018 at 03:03:51PM -0700, Dan Williams wrote: > On Mon, Apr 9, 2018 at 9:51 AM, Dan Williams wrote: > > On Mon, Apr 9, 2018 at 9:49 AM, Jan Kara wrote: > >> On Sat 07-04-18 12:38:24, Dan Williams wrote: > > [..] > >>> I wonder if this can

Re: [PATCH v8 15/18] mm, fs, dax: handle layout changes to pinned dax mappings

On Fri, Apr 13, 2018 at 03:03:51PM -0700, Dan Williams wrote: > On Mon, Apr 9, 2018 at 9:51 AM, Dan Williams wrote: > > On Mon, Apr 9, 2018 at 9:49 AM, Jan Kara wrote: > >> On Sat 07-04-18 12:38:24, Dan Williams wrote: > > [..] > >>> I wonder if this can be trivially solved by using srcu. I.e.

PRINCE CHARLES CONSULTING/GOOD DAY

We are Consultant to a private investor who is willing to invest over a $100 million in any lucrative Business as long as he is convinced of return of investment. Get back to me on (princecharles...@yahoo.com) for onward process and partnership. Regards, PRINCE & CHARLES CONSULTING LTD c/o

PRINCE CHARLES CONSULTING/GOOD DAY

We are Consultant to a private investor who is willing to invest over a $100 million in any lucrative Business as long as he is convinced of return of investment. Get back to me on (princecharles...@yahoo.com) for onward process and partnership. Regards, PRINCE & CHARLES CONSULTING LTD c/o

Re: [PATCH] [RFC][WIP] namespace.c: Allow some unprivileged proc mounts when not fully visible

On Wed, Apr 4, 2018 at 4:45 PM, Eric W. Biederman wrote: [...] > > The only option I have seen proposed that might qualify as something > general purpose and simple is a new filesystem that is just the process > directories of proc. As there would in essence be no files

Re: [PATCH] [RFC][WIP] namespace.c: Allow some unprivileged proc mounts when not fully visible

On Wed, Apr 4, 2018 at 4:45 PM, Eric W. Biederman wrote: [...] > > The only option I have seen proposed that might qualify as something > general purpose and simple is a new filesystem that is just the process > directories of proc. As there would in essence be no files that would > need

Re: [PATCH v5 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

Quoting Lina Iyer (2018-04-11 14:24:31) > On Wed, Apr 11 2018 at 09:29 -0600, Stephen Boyd wrote: > >Quoting Lina Iyer (2018-04-09 09:08:00) > >> On Fri, Apr 06 2018 at 19:14 -0600, Stephen Boyd wrote: > >> >Quoting Lina Iyer (2018-04-05 09:18:26) > >> >> diff --git

Re: [PATCH v5 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

Quoting Lina Iyer (2018-04-11 14:24:31) > On Wed, Apr 11 2018 at 09:29 -0600, Stephen Boyd wrote: > >Quoting Lina Iyer (2018-04-09 09:08:00) > >> On Fri, Apr 06 2018 at 19:14 -0600, Stephen Boyd wrote: > >> >Quoting Lina Iyer (2018-04-05 09:18:26) > >> >> diff --git

  1   2   3   4   5   6   7   8   9   10   >