[PATCH 5/6 resend] statfs: add ST_SLAVE

Signed-off-by: Christian Brauner --- fs/statfs.c| 10 +- include/linux/statfs.h | 1 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/statfs.c b/fs/statfs.c index 2fc6f9c3793c..35ad0402c9a3 100644 --- a/fs/statfs.c +++

[PATCH 5/6 resend] statfs: add ST_SLAVE

Signed-off-by: Christian Brauner --- fs/statfs.c| 10 +- include/linux/statfs.h | 1 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/fs/statfs.c b/fs/statfs.c index 2fc6f9c3793c..35ad0402c9a3 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -10,6 +10,7 @@

[PATCH 6/6 resend] statfs: add ST_PRIVATE

Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index 35ad0402c9a3..899e899ee84c 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -58,6 +58,8 @@

[PATCH 6/6 resend] statfs: add ST_PRIVATE

Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index 35ad0402c9a3..899e899ee84c 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -58,6 +58,8 @@ static int

[PATCH 0/6 resend] statfs: handle mount propagation

Hey, This is the second resend of this patchset. I'm not sure whether it has simply been overlooked but the number of people get_maintainer.pl was rather small and seemed a little random so I added Linus and Christoph, two people I know that do look at VFS stuff at least from time to time,

[PATCH 0/6 resend] statfs: handle mount propagation

Hey, This is the second resend of this patchset. I'm not sure whether it has simply been overlooked but the number of people get_maintainer.pl was rather small and seemed a little random so I added Linus and Christoph, two people I know that do look at VFS stuff at least from time to time,

[PATCH 1/6 resend] fs: use << for MS_* flags

Signed-off-by: Christian Brauner --- include/uapi/linux/fs.h | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index d2a8313fabd7..9662790a657c 100644 ---

[PATCH 1/6 resend] fs: use << for MS_* flags

Signed-off-by: Christian Brauner --- include/uapi/linux/fs.h | 33 + 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index d2a8313fabd7..9662790a657c 100644 --- a/include/uapi/linux/fs.h +++

[PATCH 4/6 resend] statfs: add ST_SHARED

Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index 61b3063d3921..2fc6f9c3793c 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -31,6 +31,8 @@

[PATCH 3/6 resend] statfs: add ST_UNBINDABLE

Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index 5b2a24f0f263..61b3063d3921 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -29,6 +29,8 @@

[PATCH 4/6 resend] statfs: add ST_SHARED

Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index 61b3063d3921..2fc6f9c3793c 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -31,6 +31,8 @@ static int flags_by_mnt(int

[PATCH 3/6 resend] statfs: add ST_UNBINDABLE

Signed-off-by: Christian Brauner --- fs/statfs.c| 2 ++ include/linux/statfs.h | 1 + 2 files changed, 3 insertions(+) diff --git a/fs/statfs.c b/fs/statfs.c index 5b2a24f0f263..61b3063d3921 100644 --- a/fs/statfs.c +++ b/fs/statfs.c @@ -29,6 +29,8 @@ static int flags_by_mnt(int

[PATCH 2/6 resend] statfs: use << to align with fs header

Signed-off-by: Christian Brauner --- include/linux/statfs.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/include/linux/statfs.h b/include/linux/statfs.h index 3142e98546ac..b336c04e793c 100644 ---

[PATCH 2/6 resend] statfs: use << to align with fs header

Signed-off-by: Christian Brauner --- include/linux/statfs.h | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/include/linux/statfs.h b/include/linux/statfs.h index 3142e98546ac..b336c04e793c 100644 --- a/include/linux/statfs.h +++

[PATCH v4 1/3] mfd: cros_ec: Add USBPD charger commands and struct definitions.

From: Sameer Nanda The USBPD charger driver gets information from the ChromeOS EC, this patch adds the USBPD charger definitions needed by this driver. Signed-off-by: Sameer Nanda Signed-off-by: Enric Balletbo i Serra ---

[PATCH v4 1/3] mfd: cros_ec: Add USBPD charger commands and struct definitions.

From: Sameer Nanda The USBPD charger driver gets information from the ChromeOS EC, this patch adds the USBPD charger definitions needed by this driver. Signed-off-by: Sameer Nanda Signed-off-by: Enric Balletbo i Serra --- Changes in v4: None Changes in v3: - [1/3] Use the BIT macro. Changes

Re: [PATCH 2/3] kexec: call LSM hook for kexec_load syscall

On Wed, 2018-05-02 at 09:45 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > Allow LSMs and IMA to differentiate between the kexec_load and > > kexec_file_load syscalls by adding an "unnecessary" call to > > security_kernel_read_file() in kexec_load. This

Re: [PATCH 2/3] kexec: call LSM hook for kexec_load syscall

On Wed, 2018-05-02 at 09:45 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > Allow LSMs and IMA to differentiate between the kexec_load and > > kexec_file_load syscalls by adding an "unnecessary" call to > > security_kernel_read_file() in kexec_load. This would be similar to the > >

[PATCH v4 2/3] power: supply: add cros-ec USBPD charger driver.

From: Sameer Nanda This driver gets various bits of information about what is connected to USB PD ports from the EC and converts that into power_supply properties. Signed-off-by: Sameer Nanda Signed-off-by: Enric Balletbo i Serra

[PATCH v4 2/3] power: supply: add cros-ec USBPD charger driver.

From: Sameer Nanda This driver gets various bits of information about what is connected to USB PD ports from the EC and converts that into power_supply properties. Signed-off-by: Sameer Nanda Signed-off-by: Enric Balletbo i Serra Acked-by: Lee Jones --- Changes in v4: - [2/3] Drop

Re: [PATCH v2] thermal: ti-soc-thermal: fix incorrect entry in omap5430_adc_to_temp[]

On Wednesday 02 May 2018 07:44 PM, Bartlomiej Zolnierkiewicz wrote: > Entry for Index 941 has one zero too much. Fix it. > Acked-by: Keerthy > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > v2: > - Fix patch description. > >

[PATCH v4 3/3] mfd: cros_ec_dev: Register cros_usbpd-charger driver as a subdevice.

Check whether this EC instance has USBPD host command support and instatiate the cros_usbpd-charger driver as a subdevice in such case. Signed-off-by: Enric Balletbo i Serra --- Changes in v4: None Changes in v3: None Changes in v2: - [3/3] Use ARRAY_SIZE instead

Re: [PATCH v2] thermal: ti-soc-thermal: fix incorrect entry in omap5430_adc_to_temp[]

On Wednesday 02 May 2018 07:44 PM, Bartlomiej Zolnierkiewicz wrote: > Entry for Index 941 has one zero too much. Fix it. > Acked-by: Keerthy > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > v2: > - Fix patch description. > > drivers/thermal/ti-soc-thermal/omap5-thermal-data.c |2 +-

[PATCH v4 3/3] mfd: cros_ec_dev: Register cros_usbpd-charger driver as a subdevice.

Check whether this EC instance has USBPD host command support and instatiate the cros_usbpd-charger driver as a subdevice in such case. Signed-off-by: Enric Balletbo i Serra --- Changes in v4: None Changes in v3: None Changes in v2: - [3/3] Use ARRAY_SIZE instead of hardcoded 1.

[PATCH v4 0/3] mfd/power: cros_ec: add support for USBPD charger driver.

Dear all, This is a fourth version of a patched to add support for the ChromeOS EC USBPD charger driver, the driver has been used on Chromebooks kernel for long time and has been ported now to mainline. The patches were tested successfully with a Samsung Chromebook Plus and an Pixel 2

[PATCH v4 0/3] mfd/power: cros_ec: add support for USBPD charger driver.

Dear all, This is a fourth version of a patched to add support for the ChromeOS EC USBPD charger driver, the driver has been used on Chromebooks kernel for long time and has been ported now to mainline. The patches were tested successfully with a Samsung Chromebook Plus and an Pixel 2

Re: linux-next: Tree for May 2 (objtool bug!)

On Wed, May 02, 2018 at 08:37:53AM -0700, Randy Dunlap wrote: > On 05/01/2018 11:59 PM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20180501: > > > > on x86_64 randconfig: > > CC fs/cifs/smbencrypt.o > drivers/char/ipmi/ipmi_ssif.o: warning: objtool:

Re: linux-next: Tree for May 2 (objtool bug!)

On Wed, May 02, 2018 at 08:37:53AM -0700, Randy Dunlap wrote: > On 05/01/2018 11:59 PM, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20180501: > > > > on x86_64 randconfig: > > CC fs/cifs/smbencrypt.o > drivers/char/ipmi/ipmi_ssif.o: warning: objtool:

Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring

On Wed, May 02, 2018 at 11:12:55PM +0800, Tiwei Bie wrote: > On Wed, May 02, 2018 at 04:51:01PM +0300, Michael S. Tsirkin wrote: > > On Wed, May 02, 2018 at 03:28:19PM +0800, Tiwei Bie wrote: > > > On Wed, May 02, 2018 at 10:51:06AM +0800, Jason Wang wrote: > > > > On 2018年04月25日 13:15, Tiwei Bie

Re: [RFC v3 4/5] virtio_ring: add event idx support in packed ring

On Wed, May 02, 2018 at 11:12:55PM +0800, Tiwei Bie wrote: > On Wed, May 02, 2018 at 04:51:01PM +0300, Michael S. Tsirkin wrote: > > On Wed, May 02, 2018 at 03:28:19PM +0800, Tiwei Bie wrote: > > > On Wed, May 02, 2018 at 10:51:06AM +0800, Jason Wang wrote: > > > > On 2018年04月25日 13:15, Tiwei Bie

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 17:22, wrote: > On 05/02/2018 11:01 AM, Jan Beulich wrote: > On 02.05.18 at 17:00, wrote: >>> On 05/02/2018 04:16 AM, Jan Beulich wrote: >>> On 30.04.18 at 18:23, wrote: > ---

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 17:22, wrote: > On 05/02/2018 11:01 AM, Jan Beulich wrote: > On 02.05.18 at 17:00, wrote: >>> On 05/02/2018 04:16 AM, Jan Beulich wrote: >>> On 30.04.18 at 18:23, wrote: > --- a/arch/x86/xen/xen-pvh.S > +++ b/arch/x86/xen/xen-pvh.S > @@ -54,6 +54,9 @@

Re: [PATCH v3 3/5] soc: rockchip: power-domain: Use of_clk_get_parent_count() instead of open coding

Quoting Geert Uytterhoeven (2018-04-18 07:50:03) > As of_clk_get_parent_count() returns zero on failure, while > of_count_phandle_with_args() might return a negative error code, this > also fixes the issue of possibly using a negative number in the > allocation below. > > Signed-off-by: Geert

Re: [PATCH v3 3/5] soc: rockchip: power-domain: Use of_clk_get_parent_count() instead of open coding

Quoting Geert Uytterhoeven (2018-04-18 07:50:03) > As of_clk_get_parent_count() returns zero on failure, while > of_count_phandle_with_args() might return a negative error code, this > also fixes the issue of possibly using a negative number in the > allocation below. > > Signed-off-by: Geert

Re: [PATCH v3 2/3] power: supply: add cros-ec USBPD charger driver.

Hi Sebastian, On 02/05/18 12:57, Sebastian Reichel wrote: > Hi, > > I found one more issue, otherwise the driver looks fine to me. > > On Wed, May 02, 2018 at 11:53:42AM +0200, Enric Balletbo i Serra wrote: >> This driver gets various bits of information about what is connected to >> USB PD

Re: [PATCH v3 2/3] power: supply: add cros-ec USBPD charger driver.

Hi Sebastian, On 02/05/18 12:57, Sebastian Reichel wrote: > Hi, > > I found one more issue, otherwise the driver looks fine to me. > > On Wed, May 02, 2018 at 11:53:42AM +0200, Enric Balletbo i Serra wrote: >> This driver gets various bits of information about what is connected to >> USB PD

Re: [PATCH v3 4/5] soc/tegra: pmc: Use of_clk_get_parent_count() instead of open coding

Quoting Geert Uytterhoeven (2018-04-18 07:50:04) > As of_clk_get_parent_count() returns zero on failure, while > of_count_phandle_with_args() might return a negative error code, this > also fixes the issue of possibly using a very big number in the > allocation below. > > Signed-off-by: Geert

Re: [PATCH v3 4/5] soc/tegra: pmc: Use of_clk_get_parent_count() instead of open coding

Quoting Geert Uytterhoeven (2018-04-18 07:50:04) > As of_clk_get_parent_count() returns zero on failure, while > of_count_phandle_with_args() might return a negative error code, this > also fixes the issue of possibly using a very big number in the > allocation below. > > Signed-off-by: Geert

Re: [PATCH v3] drm/i915: Disable some extra clang warnings

Quoting Chris Wilson (2018-05-02 10:46:07) > Quoting Matthias Kaehlcke (2018-05-01 19:24:40) > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set > > warnings to full") enabled extra warnings for i915 to spot possible > > bugs in new code, and then disabled a subset of these

Re: [PATCH v3] drm/i915: Disable some extra clang warnings

Quoting Chris Wilson (2018-05-02 10:46:07) > Quoting Matthias Kaehlcke (2018-05-01 19:24:40) > > Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set > > warnings to full") enabled extra warnings for i915 to spot possible > > bugs in new code, and then disabled a subset of these

Re: [PATCH v3 5/5] pinctrl: sunxi: Use of_clk_get_parent_count() instead of open coding

Quoting Geert Uytterhoeven (2018-04-18 07:50:05) > A new open coder has crept in since 470b73a38470e8ba ("pinctrl: sunxi: > Use of_clk_get_parent_count() instead of open coding"), replace it. > > of_clk_get_parent_count() was moved to , so include that > instead of . > > Signed-off-by: Geert

Re: [PATCH v3 5/5] pinctrl: sunxi: Use of_clk_get_parent_count() instead of open coding

Quoting Geert Uytterhoeven (2018-04-18 07:50:05) > A new open coder has crept in since 470b73a38470e8ba ("pinctrl: sunxi: > Use of_clk_get_parent_count() instead of open coding"), replace it. > > of_clk_get_parent_count() was moved to , so include that > instead of . > > Signed-off-by: Geert

Re: [PATCH v3 2/5] ARM: timer-sp: Use of_clk_get_parent_count() instead of open coding

Quoting Geert Uytterhoeven (2018-04-18 07:50:02) > Signed-off-by: Geert Uytterhoeven > Acked-by: Daniel Lezcano > --- Applied to clk-next

Re: [PATCH v3 1/5] clk: Extract OF clock helpers in

Quoting Geert Uytterhoeven (2018-04-18 07:50:01) > The use of of_clk_get_parent_{count,name}() and of_clk_init() is not > limited to clock providers. > > Hence move these helpers into their own header file, so callers that are > not clock providers no longer have to include . > > Suggested-by:

Re: [PATCH v3 2/5] ARM: timer-sp: Use of_clk_get_parent_count() instead of open coding

Quoting Geert Uytterhoeven (2018-04-18 07:50:02) > Signed-off-by: Geert Uytterhoeven > Acked-by: Daniel Lezcano > --- Applied to clk-next

Re: [PATCH v3 1/5] clk: Extract OF clock helpers in

Quoting Geert Uytterhoeven (2018-04-18 07:50:01) > The use of of_clk_get_parent_{count,name}() and of_clk_init() is not > limited to clock providers. > > Hence move these helpers into their own header file, so callers that are > not clock providers no longer have to include . > > Suggested-by:

Re: linux-next: Tree for May 2 (objtool bug!)

On 05/01/2018 11:59 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20180501: > on x86_64 randconfig: CC fs/cifs/smbencrypt.o drivers/char/ipmi/ipmi_ssif.o: warning: objtool: return_hosed_msg()+0x0: infinite recursion (objtool bug!) drivers/char/ipmi/ipmi_ssif.o: warning:

Re: linux-next: Tree for May 2 (objtool bug!)

On 05/01/2018 11:59 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20180501: > on x86_64 randconfig: CC fs/cifs/smbencrypt.o drivers/char/ipmi/ipmi_ssif.o: warning: objtool: return_hosed_msg()+0x0: infinite recursion (objtool bug!) drivers/char/ipmi/ipmi_ssif.o: warning:

Re: [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c

On Wed, May 02, 2018 at 02:38:42PM +, Andrey Konovalov wrote: > > Does having a tagged address here makes any difference? I couldn't hit a > > failure with my simple tests (LD_PRELOAD a library that randomly adds > > tags to pointers returned by malloc). > > I think you're right,

Re: [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c

On Wed, May 02, 2018 at 02:38:42PM +, Andrey Konovalov wrote: > > Does having a tagged address here makes any difference? I couldn't hit a > > failure with my simple tests (LD_PRELOAD a library that randomly adds > > tags to pointers returned by malloc). > > I think you're right,

[PATCH 02/52] perf buildid-cache: Support --purge-all option

From: Ravi Bangoria User can remove files from cache using --remove/--purge options but both needs list of files as an argument. It's not convenient when you want to flush out entire cache. Add an option to purge all files from cache. Ex, # perf buildid-cache

[PATCH 02/52] perf buildid-cache: Support --purge-all option

From: Ravi Bangoria User can remove files from cache using --remove/--purge options but both needs list of files as an argument. It's not convenient when you want to flush out entire cache. Add an option to purge all files from cache. Ex, # perf buildid-cache -l

[PATCH 04/52] perf check-headers.sh: Add support to check 2 independent files

From: Jiri Olsa Add 'check_2' function to check 2 different files, the 'check' function stays to check files that differs only in the prefix path. In upcoming changes we need to check header files in locations which don't follow the prefix logic. Signed-off-by: Jiri Olsa

[PATCH 04/52] perf check-headers.sh: Add support to check 2 independent files

From: Jiri Olsa Add 'check_2' function to check 2 different files, the 'check' function stays to check files that differs only in the prefix path. In upcoming changes we need to check header files in locations which don't follow the prefix logic. Signed-off-by: Jiri Olsa Cc: Alexander

[PATCH 06/52] perf stat: Add --table option to display time of each run

From: Jiri Olsa Add --table option to display time for each run (-r option), like: $ perf stat --null -r 5 --table perf bench sched pipe Performance counter stats for './perf bench sched pipe' (5 runs): # Table of individual measurements: 5.379

[PATCH 06/52] perf stat: Add --table option to display time of each run

From: Jiri Olsa Add --table option to display time for each run (-r option), like: $ perf stat --null -r 5 --table perf bench sched pipe Performance counter stats for './perf bench sched pipe' (5 runs): # Table of individual measurements: 5.379 (-0.176)

[PATCH 07/52] perf stat: Display length strings of each run for --table option

From: Jiri Olsa Adding support to display visual aid 'length strings' to easily spot the biggest difference in time table. $ perf stat -r 10 --table perf bench sched pipe ... Performance counter stats for './perf bench sched pipe' (5 runs): # Table of

[PATCH 07/52] perf stat: Display length strings of each run for --table option

From: Jiri Olsa Adding support to display visual aid 'length strings' to easily spot the biggest difference in time table. $ perf stat -r 10 --table perf bench sched pipe ... Performance counter stats for './perf bench sched pipe' (5 runs): # Table of individual

[PATCH 08/52] perf top: Use __map__is_kernel()

From: Arnaldo Carvalho de Melo Shorter form to figure out if a given map is the kernel one and also reduces the number of code accessing MAP__{FUNCTION,VARIABLE}, that should go away at some point. Cc: Adrian Hunter Cc: David Ahern

[PATCH 08/52] perf top: Use __map__is_kernel()

From: Arnaldo Carvalho de Melo Shorter form to figure out if a given map is the kernel one and also reduces the number of code accessing MAP__{FUNCTION,VARIABLE}, that should go away at some point. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

Re: bug-introducing patches

Hi Sasha, On Tue, May 1, 2018 at 6:38 PM, Sasha Levin wrote: > Working on AUTOSEL, it became even more obvious to me how difficult it is for > a > patch to get a proper review. Maintainers found it difficult to keep up with > the upstream work for their subsystem,

Re: bug-introducing patches

Hi Sasha, On Tue, May 1, 2018 at 6:38 PM, Sasha Levin wrote: > Working on AUTOSEL, it became even more obvious to me how difficult it is for > a > patch to get a proper review. Maintainers found it difficult to keep up with > the upstream work for their subsystem, and reviewing additional

Re: [alsa-devel] [PATCH] ASoC: Intel: bytcr_rt565: fix missing assignment to ret_val

On 5/2/18 9:29 AM, Colin King wrote: From: Colin Ian King Currently, the check that ret_val is not -ENOENT is always true and the quirk bit BYT_RY5651_MCLK_EN is never being cleared because ret_val is always zero at this point from a previous assignment earlier on. I

Re: [alsa-devel] [PATCH] ASoC: Intel: bytcr_rt565: fix missing assignment to ret_val

On 5/2/18 9:29 AM, Colin King wrote: From: Colin Ian King Currently, the check that ret_val is not -ENOENT is always true and the quirk bit BYT_RY5651_MCLK_EN is never being cleared because ret_val is always zero at this point from a previous assignment earlier on. I believe that ret_val

Re: bug-introducing patches

Hi Sasha, On Tue, May 1, 2018 at 6:38 PM, Sasha Levin wrote: > Working on AUTOSEL, it became even more obvious to me how difficult it is for > a > patch to get a proper review. Maintainers found it difficult to keep up with > the upstream work for their subsystem,

Re: bug-introducing patches

Hi Sasha, On Tue, May 1, 2018 at 6:38 PM, Sasha Levin wrote: > Working on AUTOSEL, it became even more obvious to me how difficult it is for > a > patch to get a proper review. Maintainers found it difficult to keep up with > the upstream work for their subsystem, and reviewing additional

[PATCH 09/52] perf symbols: Use __map__is_kernel() instead of ad-hoc equivalent code

From: Arnaldo Carvalho de Melo Shorter, should be equivalent code, use it. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 09/52] perf symbols: Use __map__is_kernel() instead of ad-hoc equivalent code

From: Arnaldo Carvalho de Melo Shorter, should be equivalent code, use it. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: https://lkml.kernel.org/n/tip-q90olng8sfkvrnsrwu7xn...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo ---

[PATCH 11/52] perf map: Introduce map__has_symbols()

From: Arnaldo Carvalho de Melo To further simplify checking if symbols are available for a given map and to reduce the number of users of MAP__{FUNCTION,VARIABLE}. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa

[PATCH 11/52] perf map: Introduce map__has_symbols()

From: Arnaldo Carvalho de Melo To further simplify checking if symbols are available for a given map and to reduce the number of users of MAP__{FUNCTION,VARIABLE}. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 13/52] perf tests: Let 'perf test list' display subtests

From: Hendrik Brueckner The output of perf test and perf test list differ because perf test list does not display subtests. Correct this behavior and also let perf test list report subtests. For example: $ ./perf test 2>&1 |wc -l 65 Without this

[PATCH 13/52] perf tests: Let 'perf test list' display subtests

From: Hendrik Brueckner The output of perf test and perf test list differ because perf test list does not display subtests. Correct this behavior and also let perf test list report subtests. For example: $ ./perf test 2>&1 |wc -l 65 Without this commit: $ ./perf test

[PATCH 12/52] perf thread: Introduce thread__find_map()

From: Arnaldo Carvalho de Melo Out of thread__find_add_map(..., MAP__FUNCTION, ...), idea here is to continue removing references to MAP__{FUNCTION,VARIABLE} ahead of getting both types of symbols in the same rbtree, as various places do two lookups, looking first at

[PATCH 12/52] perf thread: Introduce thread__find_map()

From: Arnaldo Carvalho de Melo Out of thread__find_add_map(..., MAP__FUNCTION, ...), idea here is to continue removing references to MAP__{FUNCTION,VARIABLE} ahead of getting both types of symbols in the same rbtree, as various places do two lookups, looking first at MAP__FUNCTION, then at

[PATCH 18/52] perf map: Shorten map_groups__find_by_name() signature

From: Arnaldo Carvalho de Melo Another step in the road to elliminate the MAP_{FUNCTION,VARIABLE} separation, reducing the exposure to these details in the tools using the symbol APIs. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa

[PATCH 18/52] perf map: Shorten map_groups__find_by_name() signature

From: Arnaldo Carvalho de Melo Another step in the road to elliminate the MAP_{FUNCTION,VARIABLE} separation, reducing the exposure to these details in the tools using the symbol APIs. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 15/52] perf script: Use thread__find_symbol() instead of ad-hoc equivalent

From: Arnaldo Carvalho de Melo In dc323ce8e72d ("perf script: Enable printing of branch stack") it first tries to find the map for an address, then the symbol in the DSO backing that map, for that address, well, this is what thread__find_symbol() does, so just use it and make

[PATCH 15/52] perf script: Use thread__find_symbol() instead of ad-hoc equivalent

From: Arnaldo Carvalho de Melo In dc323ce8e72d ("perf script: Enable printing of branch stack") it first tries to find the map for an address, then the symbol in the DSO backing that map, for that address, well, this is what thread__find_symbol() does, so just use it and make the code shorter.

[PATCH 16/52] perf thread: Make thread__find_map() return the map

From: Arnaldo Carvalho de Melo It was returning the searched map just on the addr_location passed, with the function itself returning void. Make it return the map so that we can make the code more compact. Cc: Adrian Hunter Cc: David Ahern

[PATCH 16/52] perf thread: Make thread__find_map() return the map

From: Arnaldo Carvalho de Melo It was returning the searched map just on the addr_location passed, with the function itself returning void. Make it return the map so that we can make the code more compact. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 21/52] perf machine: Shorten machine__load_kallsyms() signature

From: Arnaldo Carvalho de Melo So far the only use is for MAP__FUNCTION, and since we're going to remove that split, remove the map_type argument in machine__load_kallsyms(). Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa

[PATCH 21/52] perf machine: Shorten machine__load_kallsyms() signature

From: Arnaldo Carvalho de Melo So far the only use is for MAP__FUNCTION, and since we're going to remove that split, remove the map_type argument in machine__load_kallsyms(). Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

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

Quoting Taniya Das (2018-05-02 03:51:17) > + ret = devm_clk_hw_register(>dev, hw_clks[i]); > + if (ret) { > + dev_err(>dev, "failed to register %s\n", > + hw_clks[i]->init->name); > + goto

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

Quoting Taniya Das (2018-05-02 03:51:17) > + ret = devm_clk_hw_register(>dev, hw_clks[i]); > + if (ret) { > + dev_err(>dev, "failed to register %s\n", > + hw_clks[i]->init->name); > + goto

[PATCH 23/52] perf tests vmlinux-kallsyms: Use machine__find_kernel_function(_by_name)

From: Arnaldo Carvalho de Melo We had this for ages, IIRC for 'perf probe' use initially, so use them instead of the variants that pass the map_type, that is going away. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa

[PATCH 23/52] perf tests vmlinux-kallsyms: Use machine__find_kernel_function(_by_name)

From: Arnaldo Carvalho de Melo We had this for ages, IIRC for 'perf probe' use initially, so use them instead of the variants that pass the map_type, that is going away. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 19/52] perf Documentation: Support for asciidoctor

From: Takashi Iwai The asciidoc package seems behind the recent big wave of python3 conversion, and we were advised to switch to asciidoctor instead. It's almost compatible but some extensions used for perf documentation don't work with it. Here is the patch to cover them, and

[PATCH 19/52] perf Documentation: Support for asciidoctor

From: Takashi Iwai The asciidoc package seems behind the recent big wave of python3 conversion, and we were advised to switch to asciidoctor instead. It's almost compatible but some extensions used for perf documentation don't work with it. Here is the patch to cover them, and add the proper

Re: [PATCH 3/6] arm64: untag user addresses in copy_from_user and others

On Thu, Apr 26, 2018 at 5:47 PM, Catalin Marinas wrote: > On Wed, Apr 18, 2018 at 08:53:12PM +0200, Andrey Konovalov wrote: >> @@ -238,12 +239,15 @@ static inline void uaccess_enable_not_uao(void) >> /* >> * Sanitise a uaccess pointer such that it becomes NULL if above

Re: [PATCH 3/6] arm64: untag user addresses in copy_from_user and others

On Thu, Apr 26, 2018 at 5:47 PM, Catalin Marinas wrote: > On Wed, Apr 18, 2018 at 08:53:12PM +0200, Andrey Konovalov wrote: >> @@ -238,12 +239,15 @@ static inline void uaccess_enable_not_uao(void) >> /* >> * Sanitise a uaccess pointer such that it becomes NULL if above the >> * current

[PATCH 25/52] perf map: Shorten map_groups__find() signature

From: Arnaldo Carvalho de Melo Removing the map_type, that is going away. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 25/52] perf map: Shorten map_groups__find() signature

From: Arnaldo Carvalho de Melo Removing the map_type, that is going away. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: https://lkml.kernel.org/n/tip-18iiiw25r75xn7zlppjld...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo ---

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

On 02/05/18 16:09, Jan Beulich wrote: On 02.05.18 at 17:08, wrote: >> On 05/02/2018 11:00 AM, Jan Beulich wrote: >> On 02.05.18 at 16:57, wrote: On 05/02/2018 04:05 AM, Jan Beulich wrote: On 30.04.18 at 18:23,

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

On 02/05/18 16:09, Jan Beulich wrote: On 02.05.18 at 17:08, wrote: >> On 05/02/2018 11:00 AM, Jan Beulich wrote: >> On 02.05.18 at 16:57, wrote: On 05/02/2018 04:05 AM, Jan Beulich wrote: On 30.04.18 at 18:23, wrote: >> Signed-off-by: Boris Ostrovsky >

[PATCH 29/52] perf tools: Use kallsyms__is_function()

From: Arnaldo Carvalho de Melo Replacing equivalent, the equivalent and longer variation: symbol__is_a(type, MAP__FUNCTION); Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim

[PATCH 28/52] tools lib symbols: Introduce kallsyms__is_function()

From: Arnaldo Carvalho de Melo Out of symbol_type__is_a(type, MAP__FUNCTION), which is the only variant used so far, useful in a kallsyms library and one more step in ditching the MAP__FUNCTION/VARIABLE split. Cc: Adrian Hunter Cc: David Ahern

[PATCH 29/52] perf tools: Use kallsyms__is_function()

From: Arnaldo Carvalho de Melo Replacing equivalent, the equivalent and longer variation: symbol__is_a(type, MAP__FUNCTION); Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: https://lkml.kernel.org/n/tip-9t3dqogher54owfl9o2mi...@git.kernel.org

[PATCH 28/52] tools lib symbols: Introduce kallsyms__is_function()

From: Arnaldo Carvalho de Melo Out of symbol_type__is_a(type, MAP__FUNCTION), which is the only variant used so far, useful in a kallsyms library and one more step in ditching the MAP__FUNCTION/VARIABLE split. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan

[PATCH 27/52] perf symbols: Shorten dso__(first|last)_symbol()

From: Arnaldo Carvalho de Melo All users want MAP__FUNCTION, and this split is going away. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan

[PATCH 27/52] perf symbols: Shorten dso__(first|last)_symbol()

From: Arnaldo Carvalho de Melo All users want MAP__FUNCTION, and this split is going away. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: https://lkml.kernel.org/n/tip-sm72zwt1f03ma5uw78l6z...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo ---

<    5   6   7   8   9   10   11   12   13   14   >