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
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
> 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
> 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
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
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
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,
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,
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
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
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
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
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
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
> > >
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
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
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
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
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
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
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.
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.
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
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
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
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
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.
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.
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
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
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
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
[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
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
---
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
[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
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
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
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
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 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
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.
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
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
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
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.
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
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
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()
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()
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
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
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
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
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
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
:
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
:
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
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 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
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
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
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
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
> 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
>
> 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
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;
> +
> +
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;
> +
> +
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
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
>
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 =
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 =
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
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
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
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
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
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
> -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
> -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-
>
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
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:
>>
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
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
> -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
> -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-
>
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
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
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
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
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
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
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
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.
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
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
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
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
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
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 - 100 of 1298 matches
Mail list logo