Replies inline
On 16 September 2018 14:48:36 BST, Sebastian Reichel
wrote:
>Hi,
>
>First of all thanks for the patch and big sorry for the long delay
>in reviewing this. I did not find enough time to do it properly
>until now :(
>
>On Thu, Jun 14, 2018 at 04:14:15PM +0100, Craig Tatlor wrote:
Replies inline
On 16 September 2018 14:48:36 BST, Sebastian Reichel
wrote:
>Hi,
>
>First of all thanks for the patch and big sorry for the long delay
>in reviewing this. I did not find enough time to do it properly
>until now :(
>
>On Thu, Jun 14, 2018 at 04:14:15PM +0100, Craig Tatlor wrote:
>From context, we mean EPB (Enegry Performance Bias).
Signed-off-by: Matt Lupfer
---
tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.8
>From context, we mean EPB (Enegry Performance Bias).
Signed-off-by: Matt Lupfer
---
tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.8 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.8
On 16 September 2018 13:10:45 BST, Sebastian Reichel
wrote:
>Hi,
>
>Sorry for my long delay in reviewing this. I like the binding,
>but the "qcom," specific properties should become common properties
>in
>
>Documentation/devicetree/bindings/power/supply/battery.txt
Thanks for the review, what
On 16 September 2018 13:10:45 BST, Sebastian Reichel
wrote:
>Hi,
>
>Sorry for my long delay in reviewing this. I like the binding,
>but the "qcom," specific properties should become common properties
>in
>
>Documentation/devicetree/bindings/power/supply/battery.txt
Thanks for the review, what
Register frequency test using rtc_add_group to avoid a possible race
condition and simplify the code.
This also moves the attribute to its proper location under the rtc device
instead of the i2c parent device.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-ds1307.c | 53
Register frequency test using rtc_add_group to avoid a possible race
condition and simplify the code.
This also moves the attribute to its proper location under the rtc device
instead of the i2c parent device.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-ds1307.c | 53
On 2018/9/20 22:24, Dave Kleikamp wrote:
> On 9/20/18 9:18 AM, Chao Yu wrote:
>> Ping,
>>
>> Any comments?
>
> Sorry for putting it off. It looks good to me. I'll push it upstream.
Thanks for your review. ;)
Thanks,
>
> Thanks,
> Dave
>
>>
>> On 2018/9/17 15:12, Chao Yu wrote:
>>> We don't
On 2018/9/20 22:24, Dave Kleikamp wrote:
> On 9/20/18 9:18 AM, Chao Yu wrote:
>> Ping,
>>
>> Any comments?
>
> Sorry for putting it off. It looks good to me. I'll push it upstream.
Thanks for your review. ;)
Thanks,
>
> Thanks,
> Dave
>
>>
>> On 2018/9/17 15:12, Chao Yu wrote:
>>> We don't
On 9/20/2018 4:52 AM, zhong jiang wrote:
> kfree_skb has taken the null pointer into account. hence it is safe
> to remove the redundant null pointer check before kfree_skb.
>
> Signed-off-by: zhong jiang
> ---
> drivers/infiniband/hw/cxgb4/cm.c | 3 +--
> drivers/infiniband/hw/cxgb4/qp.c |
On 9/20/2018 4:52 AM, zhong jiang wrote:
> kfree_skb has taken the null pointer into account. hence it is safe
> to remove the redundant null pointer check before kfree_skb.
>
> Signed-off-by: zhong jiang
> ---
> drivers/infiniband/hw/cxgb4/cm.c | 3 +--
> drivers/infiniband/hw/cxgb4/qp.c |
On 9/20/2018 12:08 AM, Michael Kelley (EOSG) wrote:
> From: Tianyu Lan Sent: Monday, September 17, 2018 8:19 PM
>> +
>> +if (ret && kvm_available_flush_tlb_with_range()) {
>> +kvm_flush_remote_tlbs_with_address(kvm,
>> +
On 9/20/2018 12:08 AM, Michael Kelley (EOSG) wrote:
> From: Tianyu Lan Sent: Monday, September 17, 2018 8:19 PM
>> +
>> +if (ret && kvm_available_flush_tlb_with_range()) {
>> +kvm_flush_remote_tlbs_with_address(kvm,
>> +
On 20 September 2018 14:01:57 BST, Sricharan R wrote:
>
>
>On 9/20/2018 1:54 AM, Craig wrote:
>> Yup, this patch seems to have fixed the higher frequencies from the
>quick test I did.
>>
> Thanks !!. Can i take that as Craig Tatlor ?
Sure, no problem
>
>Regards,
> Sricharan
>
>
On 20 September 2018 14:01:57 BST, Sricharan R wrote:
>
>
>On 9/20/2018 1:54 AM, Craig wrote:
>> Yup, this patch seems to have fixed the higher frequencies from the
>quick test I did.
>>
> Thanks !!. Can i take that as Craig Tatlor ?
Sure, no problem
>
>Regards,
> Sricharan
>
>
On Wed, 19 Sep 2018, Dmitry Safonov wrote:
> On Wed, 2018-09-19 at 16:03 -0400, Mikulas Patocka wrote:
> >
> > On Wed, 19 Sep 2018, Dmitry Safonov wrote:
> > > Thanks much for the testing, Mikulas.
> > > Could you try to bisect which of the patches causes it?
> > > The most important are
On 9/20/18 9:18 AM, Chao Yu wrote:
> Ping,
>
> Any comments?
Sorry for putting it off. It looks good to me. I'll push it upstream.
Thanks,
Dave
>
> On 2018/9/17 15:12, Chao Yu wrote:
>> We don't need to call dquot_initialize() twice in jfs_evict_inode(),
>> remove one of them for cleanup.
>>
On Wed, 19 Sep 2018, Dmitry Safonov wrote:
> On Wed, 2018-09-19 at 16:03 -0400, Mikulas Patocka wrote:
> >
> > On Wed, 19 Sep 2018, Dmitry Safonov wrote:
> > > Thanks much for the testing, Mikulas.
> > > Could you try to bisect which of the patches causes it?
> > > The most important are
On 9/20/18 9:18 AM, Chao Yu wrote:
> Ping,
>
> Any comments?
Sorry for putting it off. It looks good to me. I'll push it upstream.
Thanks,
Dave
>
> On 2018/9/17 15:12, Chao Yu wrote:
>> We don't need to call dquot_initialize() twice in jfs_evict_inode(),
>> remove one of them for cleanup.
>>
Ping,
Any comments?
On 2018/9/17 15:12, Chao Yu wrote:
> We don't need to call dquot_initialize() twice in jfs_evict_inode(),
> remove one of them for cleanup.
>
> Signed-off-by: Chao Yu
> ---
> fs/jfs/inode.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/jfs/inode.c
Ping,
Any comments?
On 2018/9/17 15:12, Chao Yu wrote:
> We don't need to call dquot_initialize() twice in jfs_evict_inode(),
> remove one of them for cleanup.
>
> Signed-off-by: Chao Yu
> ---
> fs/jfs/inode.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/jfs/inode.c
Thank you for fixing that. I was doing that previously, but this time
I was only doing it every few commits. Will make sure to go back to
the way I was doing it before. Sorry about that.
On Thu, Sep 20, 2018 at 3:23 AM, Takashi Iwai wrote:
> On Tue, 18 Sep 2018 20:33:28 +0200,
> Connor McAdams
Thank you for fixing that. I was doing that previously, but this time
I was only doing it every few commits. Will make sure to go back to
the way I was doing it before. Sorry about that.
On Thu, Sep 20, 2018 at 3:23 AM, Takashi Iwai wrote:
> On Tue, 18 Sep 2018 20:33:28 +0200,
> Connor McAdams
Hi
On Thu, Sep 20, 2018 at 2:20 PM Timur Tabi wrote:
>
>
>
> On 09/19/2018 10:27 AM, Ricardo Ribalda Delgado wrote:
> > Let me explain my current setup
> >
> > I have a board with input and output gpios, the direction is defined
> > via pdata. When I run gpioinfo all the gpios are shown as input,
Hi
On Thu, Sep 20, 2018 at 2:20 PM Timur Tabi wrote:
>
>
>
> On 09/19/2018 10:27 AM, Ricardo Ribalda Delgado wrote:
> > Let me explain my current setup
> >
> > I have a board with input and output gpios, the direction is defined
> > via pdata. When I run gpioinfo all the gpios are shown as input,
Regmap tables are both defined in hmc5843_spi.c and hmc5843_i2c.c, while
the only difference between these two set of tables is SPI need a read
mask, which is set only in 'regmap_config' structrue. This patch moves
the other structrues into hmc5843_core.c to reduce redundance.
Signed-off-by: Song
Regmap tables are both defined in hmc5843_spi.c and hmc5843_i2c.c, while
the only difference between these two set of tables is SPI need a read
mask, which is set only in 'regmap_config' structrue. This patch moves
the other structrues into hmc5843_core.c to reduce redundance.
Signed-off-by: Song
Em Thu, Sep 20, 2018 at 04:00:42PM +0300, Adrian Hunter escreveu:
> Hi
>
> Here is V2 of some Intel PT patches to improve the data displayed when using
> address filters.
>
> Previously, the decoder would indicate begin / end by a branch from / to
> zero. That hides useful information, in
Em Thu, Sep 20, 2018 at 04:00:42PM +0300, Adrian Hunter escreveu:
> Hi
>
> Here is V2 of some Intel PT patches to improve the data displayed when using
> address filters.
>
> Previously, the decoder would indicate begin / end by a branch from / to
> zero. That hides useful information, in
On Wed, Sep 19, 2018 at 10:29:05AM -0700, Reinette Chatre wrote:
> Reinette Chatre (6):
> perf/core: Add sanity check to deal with pinned event failure
> perf/x86: Add helper to obtain performance counter index
> x86/intel_rdt: Remove local register variables
> x86/intel_rdt: Create
On Wed, Sep 19, 2018 at 10:29:05AM -0700, Reinette Chatre wrote:
> Reinette Chatre (6):
> perf/core: Add sanity check to deal with pinned event failure
> perf/x86: Add helper to obtain performance counter index
> x86/intel_rdt: Remove local register variables
> x86/intel_rdt: Create
On Wed, Sep 19, 2018 at 10:29:10AM -0700, Reinette Chatre wrote:
> +static int measure_l3_residency(void *_plr)
> +{
> + counts.miss_after -= counts.miss_before;
> + if (boot_cpu_data.x86_model == INTEL_FAM6_BROADWELL_X) {
> + /*
> + * On BDW references and misses
On Wed, Sep 19, 2018 at 10:29:10AM -0700, Reinette Chatre wrote:
> +static int measure_l3_residency(void *_plr)
> +{
> + counts.miss_after -= counts.miss_before;
> + if (boot_cpu_data.x86_model == INTEL_FAM6_BROADWELL_X) {
> + /*
> + * On BDW references and misses
On Thu, Sep 20, 2018 at 4:18 AM Stephen Rothwell wrote:
>
> Hi Michael,
>
> On Thu, 20 Sep 2018 21:10:08 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 20 Sep 2018 20:37:37 +1000 Michael Ellerman
> > wrote:
> > >
> > > Oodles of:
> > >
> > > # < make -s -j 48 ARCH=arm64
> > >
On Thu, Sep 20, 2018 at 4:18 AM Stephen Rothwell wrote:
>
> Hi Michael,
>
> On Thu, 20 Sep 2018 21:10:08 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 20 Sep 2018 20:37:37 +1000 Michael Ellerman
> > wrote:
> > >
> > > Oodles of:
> > >
> > > # < make -s -j 48 ARCH=arm64
> > >
On Mon, Aug 27, 2018 at 12:45:25AM -0700, Kees Cook wrote:
> On Tue, May 29, 2018 at 6:27 AM, Andy Whitcroft
> wrote:
> > On Wed, Mar 07, 2018 at 04:02:45PM -0800, Brian Belleville wrote:
> >> The final field of a floppy_struct is the field "name", which is a
> >> pointer to a string in kernel
On Mon, Aug 27, 2018 at 12:45:25AM -0700, Kees Cook wrote:
> On Tue, May 29, 2018 at 6:27 AM, Andy Whitcroft
> wrote:
> > On Wed, Mar 07, 2018 at 04:02:45PM -0800, Brian Belleville wrote:
> >> The final field of a floppy_struct is the field "name", which is a
> >> pointer to a string in kernel
On Thu, Sep 20, 2018 at 03:57:48PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 18, 2018 at 06:55:40PM +0200, Miguel Ojeda wrote:
> > These two patches are the 5th and 6th of the Compiler Attributes series,
> > which Stefan and Nick requested to go into v4.19 so that the clang ARM32
> > build is
On Thu, Sep 20, 2018 at 03:57:48PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 18, 2018 at 06:55:40PM +0200, Miguel Ojeda wrote:
> > These two patches are the 5th and 6th of the Compiler Attributes series,
> > which Stefan and Nick requested to go into v4.19 so that the clang ARM32
> > build is
Since WEAK() supposed to be used instead of ENTRY() to define weak
symbols, but unlike ENTRY() it doesn't have ALIGN directive.
It seems there is no actual reason to not have, so let's add
ALIGN to WEAK() too.
Signed-off-by: Andrey Ryabinin
---
include/linux/linkage.h | 1 +
1 file changed, 1
ARM64 has asm implementation of memchr(), memcmp(), str[r]chr(),
str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm
code, thus it can potentially miss many bugs.
Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is
enabled, so the generic implementations from
Arch code may have asm implementation of string/memory API functions
instead of using generic one from lib/string.c. KASAN don't see
memory accesses in asm code, thus can miss many bugs.
E.g. on ARM64 KASAN don't see bugs in memchr(), memcmp(), str[r]chr(),
str[n]cmp(), str[n]len(). Add tests for
Since WEAK() supposed to be used instead of ENTRY() to define weak
symbols, but unlike ENTRY() it doesn't have ALIGN directive.
It seems there is no actual reason to not have, so let's add
ALIGN to WEAK() too.
Signed-off-by: Andrey Ryabinin
---
include/linux/linkage.h | 1 +
1 file changed, 1
ARM64 has asm implementation of memchr(), memcmp(), str[r]chr(),
str[n]cmp(), str[n]len(). KASAN don't see memory accesses in asm
code, thus it can potentially miss many bugs.
Ifdef out __HAVE_ARCH_* defines of these functions when KASAN is
enabled, so the generic implementations from
Arch code may have asm implementation of string/memory API functions
instead of using generic one from lib/string.c. KASAN don't see
memory accesses in asm code, thus can miss many bugs.
E.g. on ARM64 KASAN don't see bugs in memchr(), memcmp(), str[r]chr(),
str[n]cmp(), str[n]len(). Add tests for
On Tue, Sep 18, 2018 at 06:55:40PM +0200, Miguel Ojeda wrote:
> These two patches are the 5th and 6th of the Compiler Attributes series,
> which Stefan and Nick requested to go into v4.19 so that the clang ARM32
> build is fixed. The v5 of Compiler Attributes will have these two removed
> if this
On Tue, Sep 18, 2018 at 06:55:40PM +0200, Miguel Ojeda wrote:
> These two patches are the 5th and 6th of the Compiler Attributes series,
> which Stefan and Nick requested to go into v4.19 so that the clang ARM32
> build is fixed. The v5 of Compiler Attributes will have these two removed
> if this
Hi Dmitry,
On Mon, Sep 17, 2018 at 11:16:00AM -0700, Dmitry Torokhov wrote:
> +/**
> + * device_add_child_properties - Add a collection of properties to a device
> object.
> + * @dev: Device to add properties to.
In case you didn't notice my comment for this, you are missing @parent
here.
But
Hi Dmitry,
On Mon, Sep 17, 2018 at 11:16:00AM -0700, Dmitry Torokhov wrote:
> +/**
> + * device_add_child_properties - Add a collection of properties to a device
> object.
> + * @dev: Device to add properties to.
In case you didn't notice my comment for this, you are missing @parent
here.
But
On Thu, 20 Sep 2018, Song Qiang wrote:
> PNI RM3100 magnetometer is a high resolution, large signal immunity
> magnetometer, composed of 3 single sensors and a processing chip.
> PNI is currently not in the vendors list, so this is also adding it.
comments below
>
> Following functions are
On Thu, 20 Sep 2018, Song Qiang wrote:
> PNI RM3100 magnetometer is a high resolution, large signal immunity
> magnetometer, composed of 3 single sensors and a processing chip.
> PNI is currently not in the vendors list, so this is also adding it.
comments below
>
> Following functions are
On Wed, Sep 19, 2018 at 6:47 PM Stephen Rothwell wrote:
>
> Hi Rob,
>
> After merging the devicetree tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
Yes, that's expected. I posted fixes for all of these last week. Some
sub-arch maintainers haven't picked up the
On Wed, Sep 19, 2018 at 6:47 PM Stephen Rothwell wrote:
>
> Hi Rob,
>
> After merging the devicetree tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
Yes, that's expected. I posted fixes for all of these last week. Some
sub-arch maintainers haven't picked up the
Replace 'hcm5843' with 'hmc5843'.
Signed-off-by: Song Qiang
---
drivers/iio/magnetometer/hmc5843.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/magnetometer/hmc5843.h
b/drivers/iio/magnetometer/hmc5843.h
index 76a5d7484d8d..a75224cf99df 100644
---
Replace 'hcm5843' with 'hmc5843'.
Signed-off-by: Song Qiang
---
drivers/iio/magnetometer/hmc5843.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/magnetometer/hmc5843.h
b/drivers/iio/magnetometer/hmc5843.h
index 76a5d7484d8d..a75224cf99df 100644
---
Hi Matthias,
On 2018-09-19 22:51, Matthias Kaehlcke wrote:
On Wed, Sep 19, 2018 at 08:51:13PM +0530, Balakrishna Godavarthi wrote:
This patch enables power off support for hci down and power on support
for hci up. As wcn3990 power sources are ignited by regulators, we
will
turn off them
Hi Matthias,
On 2018-09-19 22:51, Matthias Kaehlcke wrote:
On Wed, Sep 19, 2018 at 08:51:13PM +0530, Balakrishna Godavarthi wrote:
This patch enables power off support for hci down and power on support
for hci up. As wcn3990 power sources are ignited by regulators, we
will
turn off them
This error apparently is caused by timed out event, so a -ETIMEDOUT
should be used instead of a -EIO, and it also tells user what happened
, so this dev_err may not be needed anymore.
Signed-off-by: Song Qiang
---
I used ./scripts/get_maintainer.pl to get maintainers about this file,
I thought
This error apparently is caused by timed out event, so a -ETIMEDOUT
should be used instead of a -EIO, and it also tells user what happened
, so this dev_err may not be needed anymore.
Signed-off-by: Song Qiang
---
I used ./scripts/get_maintainer.pl to get maintainers about this file,
I thought
Em Thu, Sep 20, 2018 at 04:00:42PM +0300, Adrian Hunter escreveu:
> Here is V2 of some Intel PT patches to improve the data displayed when using
> address filters.
> Changes in V2:
>
> Improve commit messages
Thanks a lot, helps a lot,
- Arnaldo
Em Thu, Sep 20, 2018 at 04:00:42PM +0300, Adrian Hunter escreveu:
> Here is V2 of some Intel PT patches to improve the data displayed when using
> address filters.
> Changes in V2:
>
> Improve commit messages
Thanks a lot, helps a lot,
- Arnaldo
On Thu, Sep 20, 2018 at 12:17:43PM +0200, Greg KH wrote:
> On Thu, Sep 20, 2018 at 06:14:07PM +0800, Guo Ren wrote:
> > Add a maintainer information for the csky(C-SKY) architecture.
> >
> > Signed-off-by: Guo Ren
> > ---
> > MAINTAINERS | 16
> > 1 file changed, 16
On Thu, Sep 20, 2018 at 12:17:43PM +0200, Greg KH wrote:
> On Thu, Sep 20, 2018 at 06:14:07PM +0800, Guo Ren wrote:
> > Add a maintainer information for the csky(C-SKY) architecture.
> >
> > Signed-off-by: Guo Ren
> > ---
> > MAINTAINERS | 16
> > 1 file changed, 16
Hi Kashyap,
On 2018/9/20 16:39, Kashyap Desai worte:
Dou - Do you want me to test your patch or shall I wait for next version
?
I'm sorry, please wait for the next version.
Thanks,
dou
Hi Kashyap,
On 2018/9/20 16:39, Kashyap Desai worte:
Dou - Do you want me to test your patch or shall I wait for next version
?
I'm sorry, please wait for the next version.
Thanks,
dou
PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the vendors list, so this is also adding it.
Following functions are available:
- Single-shot measurement from
PNI RM3100 magnetometer is a high resolution, large signal immunity
magnetometer, composed of 3 single sensors and a processing chip.
PNI is currently not in the vendors list, so this is also adding it.
Following functions are available:
- Single-shot measurement from
On Thu, Sep 13, 2018 at 12:48:43PM +0200, Eric W. Biederman wrote:
>
> The genweq_add_file and genwqe_del_file by caching current without
> using reference counting embed the assumption that a file descriptor
> will never be passed from one process to another. It even embeds the
> assumption
On Thu, Sep 13, 2018 at 12:48:43PM +0200, Eric W. Biederman wrote:
>
> The genweq_add_file and genwqe_del_file by caching current without
> using reference counting embed the assumption that a file descriptor
> will never be passed from one process to another. It even embeds the
> assumption
2018-09-12 10:04 GMT+02:00 Bartosz Golaszewski :
> From: Bartosz Golaszewski
>
> While working on the nvmem framework recently I noticed that there are
> many providers that don't use the devm variant of nvmem_register().
> This series contains relevant updates for eeprom drivers.
>
> Note that
2018-09-12 10:04 GMT+02:00 Bartosz Golaszewski :
> From: Bartosz Golaszewski
>
> While working on the nvmem framework recently I noticed that there are
> many providers that don't use the devm variant of nvmem_register().
> This series contains relevant updates for eeprom drivers.
>
> Note that
Allow for different combinations of sample flags with "trace begin" or
"trace end".
Previously, the Intel PT decoder would indicate begin / end by a branch
from / to zero. That hides useful information, in particular when a trace
ends with a call. Before remedying that, prepare 'perf script' to
Allow for different combinations of sample flags with "trace begin" or
"trace end".
Previously, the Intel PT decoder would indicate begin / end by a branch
from / to zero. That hides useful information, in particular when a trace
ends with a call. Before remedying that, prepare 'perf script' to
Hi
Here is V2 of some Intel PT patches to improve the data displayed when using
address filters.
Previously, the decoder would indicate begin / end by a branch from / to
zero. That hides useful information, in particular when a trace ends with a
call. That happens when using address filters, for
thread_stack__event() is used to create call stacks, by keeping track of
calls and returns. Improve the handling of trace begin / end to allow for a
trace that ends in a call.
Previously, the Intel PT decoder would indicate begin / end by a branch
from / to zero. That hides useful information, in
Add branch types to cover different combinations with "trace begin" or
"trace end".
Previously, the Intel PT decoder would indicate begin / end by a branch
from / to zero. That hides useful information, in particular when a trace
ends with a call. Before remedying that, prepare the database
Previously, the decoder would indicate begin / end by a branch from / to
zero. That hides useful information, in particular when a trace ends with a
call. To prepare for remedying that, add Intel PT decoder flags for trace
begin / end and map them to the existing sample flags.
Signed-off-by:
On 9/20/2018 1:54 AM, Craig wrote:
> Yup, this patch seems to have fixed the higher frequencies from the quick
> test I did.
>
Thanks !!. Can i take that as
Tested-by: Craig Tatlor ?
Regards,
Sricharan
> On 7 September 2018 15:28:53 BST, Craig Tatlor wrote:
>>
>>
>> On
On 9/20/2018 1:54 AM, Craig wrote:
> Yup, this patch seems to have fixed the higher frequencies from the quick
> test I did.
>
Thanks !!. Can i take that as
Tested-by: Craig Tatlor ?
Regards,
Sricharan
> On 7 September 2018 15:28:53 BST, Craig Tatlor wrote:
>>
>>
>> On
Hi
Here is V2 of some Intel PT patches to improve the data displayed when using
address filters.
Previously, the decoder would indicate begin / end by a branch from / to
zero. That hides useful information, in particular when a trace ends with a
call. That happens when using address filters, for
thread_stack__event() is used to create call stacks, by keeping track of
calls and returns. Improve the handling of trace begin / end to allow for a
trace that ends in a call.
Previously, the Intel PT decoder would indicate begin / end by a branch
from / to zero. That hides useful information, in
Add branch types to cover different combinations with "trace begin" or
"trace end".
Previously, the Intel PT decoder would indicate begin / end by a branch
from / to zero. That hides useful information, in particular when a trace
ends with a call. Before remedying that, prepare the database
Previously, the decoder would indicate begin / end by a branch from / to
zero. That hides useful information, in particular when a trace ends with a
call. To prepare for remedying that, add Intel PT decoder flags for trace
begin / end and map them to the existing sample flags.
Signed-off-by:
thread_stack__process() is used to create call paths for database export.
Improve the handling of trace begin / end to allow for a trace that ends in
a call.
Previously, the Intel PT decoder would indicate begin / end by a branch
from / to zero. That hides useful information, in particular when a
Have the Intel PT decoder implement the new Intel PT decoder flags for
trace begin / end.
Previously, the decoder would indicate begin / end by a branch from / to
zero. That hides useful information, in particular when a trace ends with a
call. That happens when using address filters, for
thread_stack__process() is used to create call paths for database export.
Improve the handling of trace begin / end to allow for a trace that ends in
a call.
Previously, the Intel PT decoder would indicate begin / end by a branch
from / to zero. That hides useful information, in particular when a
Have the Intel PT decoder implement the new Intel PT decoder flags for
trace begin / end.
Previously, the decoder would indicate begin / end by a branch from / to
zero. That hides useful information, in particular when a trace ends with a
call. That happens when using address filters, for
On 9/20/2018 1:54 AM, Craig wrote:
> Yup, this patch seems to have fixed the higher frequencies from the quick
> test I did.
>
Thanks !!. Can i take that as Craig Tatlor ?
Regards,
Sricharan
tested-by:
> On 7 September 2018 15:28:53 BST, Craig Tatlor wrote:
>>
>>
>> On 7
On 9/20/2018 1:54 AM, Craig wrote:
> Yup, this patch seems to have fixed the higher frequencies from the quick
> test I did.
>
Thanks !!. Can i take that as Craig Tatlor ?
Regards,
Sricharan
tested-by:
> On 7 September 2018 15:28:53 BST, Craig Tatlor wrote:
>>
>>
>> On 7
2018-08-27 11:06 GMT+02:00 Bartosz Golaszewski :
> I recently started a discussion about the need for a proper early device
> probing mechanism[1]. One that would be based on real platform drivers
> and support both platform data and device tree.
>
> While we're far from reaching any consensus on
2018-08-27 11:06 GMT+02:00 Bartosz Golaszewski :
> I recently started a discussion about the need for a proper early device
> probing mechanism[1]. One that would be based on real platform drivers
> and support both platform data and device tree.
>
> While we're far from reaching any consensus on
On Thu, Sep 20, 2018 at 03:45:52PM +0300, Alexander Shishkin wrote:
> This adds a helper to paste 2 pointer arrays together, useful for merging
> various types of attribute arrays. There are a few places in the kernel
> tree where this is open coded, and I just added one more in the STM class.
>
On Thu, Sep 20, 2018 at 03:45:52PM +0300, Alexander Shishkin wrote:
> This adds a helper to paste 2 pointer arrays together, useful for merging
> various types of attribute arrays. There are a few places in the kernel
> tree where this is open coded, and I just added one more in the STM class.
>
2018-08-28 11:33 GMT+02:00 Bartosz Golaszewski :
> This series implements devm_kstrdup_const() together with some
> prerequisite changes and uses it in pmc-atom driver.
>
> v1 -> v2:
> - fixed the changelog in the patch implementing devm_kstrdup_const()
> - fixed the kernel doc
> - moved
2018-08-28 11:33 GMT+02:00 Bartosz Golaszewski :
> This series implements devm_kstrdup_const() together with some
> prerequisite changes and uses it in pmc-atom driver.
>
> v1 -> v2:
> - fixed the changelog in the patch implementing devm_kstrdup_const()
> - fixed the kernel doc
> - moved
On Thu, Sep 20, 2018 at 08:58:16PM +0800, Wei Wang wrote:
> On 09/20/2018 08:37 PM, Peter Zijlstra wrote:
> > On Thu, Sep 20, 2018 at 06:05:59PM +0800, Wei Wang wrote:
> > > /**
> > > + * lbr_select_user_callstack - check if the user callstack mode is set
> > > + *
> > > + * @lbr_select: the lbr
On Thu, Sep 20, 2018 at 08:58:16PM +0800, Wei Wang wrote:
> On 09/20/2018 08:37 PM, Peter Zijlstra wrote:
> > On Thu, Sep 20, 2018 at 06:05:59PM +0800, Wei Wang wrote:
> > > /**
> > > + * lbr_select_user_callstack - check if the user callstack mode is set
> > > + *
> > > + * @lbr_select: the lbr
On 09/20/2018 08:37 PM, Peter Zijlstra wrote:
On Thu, Sep 20, 2018 at 06:05:59PM +0800, Wei Wang wrote:
/**
+ * lbr_select_user_callstack - check if the user callstack mode is set
+ *
+ * @lbr_select: the lbr select msr
+ *
+ * Returns: true if the msr is configured to the user callstack
On 09/20/2018 08:37 PM, Peter Zijlstra wrote:
On Thu, Sep 20, 2018 at 06:05:59PM +0800, Wei Wang wrote:
/**
+ * lbr_select_user_callstack - check if the user callstack mode is set
+ *
+ * @lbr_select: the lbr select msr
+ *
+ * Returns: true if the msr is configured to the user callstack
801 - 900 of 1302 matches
Mail list logo
