Re: [PATCH 14/14] perf script: show overhead events

On Wed, Nov 23, 2016 at 04:44:52AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Introduce a new option --show-overhead to show overhead events in perf > script perf 7356 [001] 7292.203517: 482010 cycles:pp: 818e2150

Re: [PATCH 14/14] perf script: show overhead events

On Wed, Nov 23, 2016 at 04:44:52AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Introduce a new option --show-overhead to show overhead events in perf > script perf 7356 [001] 7292.203517: 482010 cycles:pp: 818e2150 _raw_spin_unlock_irqrestore+0x40

Re: [PATCH v4 1/2] Documentation: dt: reset: Add TI SCI reset binding

On Mon, Nov 21, 2016 at 03:30:51PM -0600, Andrew F. Davis wrote: > Add TI SCI reset controller binding. This describes the DT binding > details for a reset controller node providing reset management services > to hardware blocks (reset consumers) using the Texas Instrument's System > Control

Re: [PATCH v4 1/2] Documentation: dt: reset: Add TI SCI reset binding

On Mon, Nov 21, 2016 at 03:30:51PM -0600, Andrew F. Davis wrote: > Add TI SCI reset controller binding. This describes the DT binding > details for a reset controller node providing reset management services > to hardware blocks (reset consumers) using the Texas Instrument's System > Control

Re: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

On Tue, Nov 08, 2016 at 02:04:38PM -0800, Long Li wrote: > From: Long Li > > hv_do_hypercall assumes that we pass a segment from a physically > continuous buffer. Buffer allocated on the stack may not work if > CONFIG_VMAP_STACK=y is set. > > Change to use kmalloc to

Re: [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

On Tue, Nov 08, 2016 at 02:04:38PM -0800, Long Li wrote: > From: Long Li > > hv_do_hypercall assumes that we pass a segment from a physically > continuous buffer. Buffer allocated on the stack may not work if > CONFIG_VMAP_STACK=y is set. > > Change to use kmalloc to allocate this buffer. > >

Re: [PATCH] PCI: iproc: Fix incorrect MSI address alignment

On Mon, Nov 21, 2016 at 05:48:30PM -0800, Ray Jui wrote: > In the code to handle PAXB v2 based MSI steering, the logic aligns the > MSI register address to the size of supported inbound mapping range. > This is incorrect since it rounds "up" the starting address to the next > aligned address, but

Re: [PATCH] PCI: iproc: Fix incorrect MSI address alignment

On Mon, Nov 21, 2016 at 05:48:30PM -0800, Ray Jui wrote: > In the code to handle PAXB v2 based MSI steering, the logic aligns the > MSI register address to the size of supported inbound mapping range. > This is incorrect since it rounds "up" the starting address to the next > aligned address, but

[PATCH 3/5] staging: lustre: ldlm: remove ldlm_wire_policy_data_t typedef usage from code

From: Andreas Dilger Replace usage of ldlm_wire_policy_data_t with named enums to conform to upstream coding style. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142 Reviewed-on:

[PATCH 3/5] staging: lustre: ldlm: remove ldlm_wire_policy_data_t typedef usage from code

From: Andreas Dilger Replace usage of ldlm_wire_policy_data_t with named enums to conform to upstream coding style. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142 Reviewed-on: http://review.whamcloud.com/15300 Reviewed-on:

Re: [PATCH] clk: bcm: Make COMMON_CLK_IPROC into a library

Le 23/11/2016 à 14:55, Scott Branden a écrit : >> config COMMON_CLK_IPROC >> -bool "Broadcom iProc clock support" >> -depends on ARCH_BCM_IPROC || ARCH_BCM_63XX || COMPILE_TEST >> -depends on COMMON_CLK > I think the depends on COMMON_CLK needs to remain? That's not necessary; the

Re: [PATCH] clk: bcm: Make COMMON_CLK_IPROC into a library

Le 23/11/2016 à 14:55, Scott Branden a écrit : >> config COMMON_CLK_IPROC >> -bool "Broadcom iProc clock support" >> -depends on ARCH_BCM_IPROC || ARCH_BCM_63XX || COMPILE_TEST >> -depends on COMMON_CLK > I think the depends on COMMON_CLK needs to remain? That's not necessary; the

Re: [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata

Hi Robert, On Wed, Oct 26, 2016 at 09:41:44PM +0200, Robert Jarzmik wrote: > As the power supply framework provides a way to store and retrieve > private supply data, use it. > > In the process, change the platform data for wm97xx_battery from a > container of a single struct wm97xx_batt_pdata

Re: [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata

Hi Robert, On Wed, Oct 26, 2016 at 09:41:44PM +0200, Robert Jarzmik wrote: > As the power supply framework provides a way to store and retrieve > private supply data, use it. > > In the process, change the platform data for wm97xx_battery from a > container of a single struct wm97xx_batt_pdata

fuse: feasible to distinguish between umount and abort?

Hello, Currently, both a call to umount(2) and writing "1" to /sys/fs/fuse/connections/NNN/abort will put the /dev/fuse fd into the same state: reading from it returns ENODEV, and polling on it returns POLLERR. This causes problems for filesystems that want to ensure that the mountpoint is free

fuse: feasible to distinguish between umount and abort?

Hello, Currently, both a call to umount(2) and writing "1" to /sys/fs/fuse/connections/NNN/abort will put the /dev/fuse fd into the same state: reading from it returns ENODEV, and polling on it returns POLLERR. This causes problems for filesystems that want to ensure that the mountpoint is free

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

Thx Adam for the cleaned up patch ... Acked-by: Philip Mueller Tested-by: Philip Mueller

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

Thx Adam for the cleaned up patch ... Acked-by: Philip Mueller Tested-by: Philip Mueller

Re: [PATCH 11/14] perf tools: record write data overhead

On Wed, Nov 23, 2016 at 04:44:49AM -0500, kan.li...@intel.com wrote: SNIP > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > index d8cde21..ce7a0ea 100644 > --- a/tools/perf/util/machine.c > +++ b/tools/perf/util/machine.c > @@ -573,6 +573,11 @@ int

Re: [PATCH 03/15] wm8350_power: use permission-specific DEVICE_ATTR variants

Hi Julia, On Sat, Oct 29, 2016 at 09:36:57PM +0200, Julia Lawall wrote: > Use DEVICE_ATTR_RO for read only attributes. This simplifies the source > code, improves readbility, and reduces the chance of inconsistencies. > > The semantic patch that makes this change is as follows: >

Re: [PATCH 11/14] perf tools: record write data overhead

On Wed, Nov 23, 2016 at 04:44:49AM -0500, kan.li...@intel.com wrote: SNIP > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > index d8cde21..ce7a0ea 100644 > --- a/tools/perf/util/machine.c > +++ b/tools/perf/util/machine.c > @@ -573,6 +573,11 @@ int

Re: [PATCH 03/15] wm8350_power: use permission-specific DEVICE_ATTR variants

Hi Julia, On Sat, Oct 29, 2016 at 09:36:57PM +0200, Julia Lawall wrote: > Use DEVICE_ATTR_RO for read only attributes. This simplifies the source > code, improves readbility, and reduces the chance of inconsistencies. > > The semantic patch that makes this change is as follows: >

Re: [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment

On Tue, Nov 22, 2016 at 10:42 PM, Stefan Agner wrote: > The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them > separately: > > Clock Clock Root Description > apb_clkMAIN_AXI_CLK_ROOT AXI clock > pix_clkLCDIF_PIXEL_CLK_ROOTPixel

Re: [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment

On Tue, Nov 22, 2016 at 10:42 PM, Stefan Agner wrote: > The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them > separately: > > Clock Clock Root Description > apb_clkMAIN_AXI_CLK_ROOT AXI clock > pix_clkLCDIF_PIXEL_CLK_ROOTPixel clock > ipg_clk_s

Re: [PATCH] power: supply: bq27xxx_battery: Fix register map for BQ27510 and BQ27520

Hi, On Fri, Nov 04, 2016 at 01:33:13PM -0500, Andrew F. Davis wrote: > The BQ27510 and BQ27520 use a slightly different register map than the > BQ27500, add a new type enum and add these gauges to it. > > Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional > bq27xxx family

Re: [PATCH] power: supply: bq27xxx_battery: Fix register map for BQ27510 and BQ27520

Hi, On Fri, Nov 04, 2016 at 01:33:13PM -0500, Andrew F. Davis wrote: > The BQ27510 and BQ27520 use a slightly different register map than the > BQ27500, add a new type enum and add these gauges to it. > > Fixes: d74534c27775 ("power: bq27xxx_battery: Add support for additional > bq27xxx family

Re: [PATCH 1/4] clocksource/drivers/arm_arch_timer: Don't assume clock runs in suspend

On Tue, Nov 22, 2016 at 10:44:21AM +0100, Daniel Lezcano wrote: > From: Brian Norris > > The ARM specifies that the system counter "must be implemented in an > always-on power domain," and so we try to use the counter as a source of > timekeeping across suspend/resume.

Re: [PATCH 1/4] clocksource/drivers/arm_arch_timer: Don't assume clock runs in suspend

On Tue, Nov 22, 2016 at 10:44:21AM +0100, Daniel Lezcano wrote: > From: Brian Norris > > The ARM specifies that the system counter "must be implemented in an > always-on power domain," and so we try to use the counter as a source of > timekeeping across suspend/resume. Unfortunately, some SoCs

Re: BUG: 4.9-rc6 Still "no symbol version" on boot

Am 23.11.2016 um 21:53 schrieb Adam Borowski: > Last version (rewritten description) is at: > https://patchwork.kernel.org/patch/9439501/ > (needs s/oeter/peter/ for a typo in Peter Wu's address) Hi Adam, good to know. I kept track on it. For me it is easy to use patches. However it would be

Re: BUG: 4.9-rc6 Still "no symbol version" on boot

Am 23.11.2016 um 21:53 schrieb Adam Borowski: > Last version (rewritten description) is at: > https://patchwork.kernel.org/patch/9439501/ > (needs s/oeter/peter/ for a typo in Peter Wu's address) Hi Adam, good to know. I kept track on it. For me it is easy to use patches. However it would be

[PATCH v2] staging: lustre: osc: Performance tune for LRU

From: Jinshan Xiong Early launch page LRU work in osc_io_rw_iter_init(); Change the page LRU shrinking policy by OSC attributes; Delete the contented lock osc_object::oo_seatbelt Signed-off-by: Jinshan Xiong Intel-bug-id:

Re: [PATCH 11/14] perf tools: record write data overhead

On Wed, Nov 23, 2016 at 04:44:49AM -0500, kan.li...@intel.com wrote: SNIP > > +static void perf_event__synth_overhead(struct record *rec, > perf_event__handler_t process) > +{ > + int cpu; > + > + union perf_event event = { > + .overhead = { > + .header

[PATCH v2] staging: lustre: osc: Performance tune for LRU

From: Jinshan Xiong Early launch page LRU work in osc_io_rw_iter_init(); Change the page LRU shrinking policy by OSC attributes; Delete the contented lock osc_object::oo_seatbelt Signed-off-by: Jinshan Xiong Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5108 Reviewed-on:

Re: [PATCH 11/14] perf tools: record write data overhead

On Wed, Nov 23, 2016 at 04:44:49AM -0500, kan.li...@intel.com wrote: SNIP > > +static void perf_event__synth_overhead(struct record *rec, > perf_event__handler_t process) > +{ > + int cpu; > + > + union perf_event event = { > + .overhead = { > + .header

[PATCH 2/4] staging: lustre: obd: reserve connection flag OBD_CONNECT_LOCK_AHEAD

From: Fan Yong The connection flag OBD_CONNECT_LOCK_AHEAD will be used for the following the patch: LU-6917 LDLM lock ahead http://review.whamcloud.com/13564 Land the connection flags to upstream client earlier for reserving the slot to avoid potential conflict with others.

[PATCH 4/5] staging: lustre: ldlm: rename LDLM_CANCEL_* flags

From: Andreas Dilger Rename LDLM_CANCEL_* flags (used with enum ldlm_lru_flags) to LDLM_LRU_FLAGS_* to avoid confusion with enum ldlm_cancel_flags. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142

[PATCH 4/4] staging: lustre: obd: reserve connection flag OBD_CONNECT_FLAGS2

From: Fan Yong This is a feature for the client and server to use obd_connect_flags2 to communicate future feature flags. The client should set this flag whenever any flags in that field are requested, and the server should mask unsupported features from this field (assuming

[PATCH 1/5] staging: lustre: ldlm: remove ldlm_policy_data_t typedef usage from code

From: Andreas Dilger Replace usage of ldlm_policy_data_t with named enums to conform to upstream coding style. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142 Reviewed-on:

[PATCH 0/4] staging: lustre: obd: reserve connection flags

Reserve several OBD_CONNECT_* flags for future use. Fan Yong (4): staging: lustre: obd: reserve connection flag OBD_CONNECT_SUBTREE staging: lustre: obd: reserve connection flag OBD_CONNECT_LOCK_AHEAD staging: lustre: obd: reserve connection flag OBD_CONNECT_OBDOPACK staging: lustre: obd:

[PATCH 3/4] staging: lustre: obd: reserve connection flag OBD_CONNECT_OBDOPACK

From: Fan Yong The connection flag OBD_CONNECT_OBDOPACK will be used for the following the patch: LU-4215 optimize OUT protocol http://review.whamcloud.com/15336 Land the connection flags to upstream client earlier for reserving the slot to avoid potential conflict with

[PATCH 4/4] staging: lustre: obd: reserve connection flag OBD_CONNECT_FLAGS2

From: Fan Yong This is a feature for the client and server to use obd_connect_flags2 to communicate future feature flags. The client should set this flag whenever any flags in that field are requested, and the server should mask unsupported features from this field (assuming it understands

[PATCH 1/5] staging: lustre: ldlm: remove ldlm_policy_data_t typedef usage from code

From: Andreas Dilger Replace usage of ldlm_policy_data_t with named enums to conform to upstream coding style. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142 Reviewed-on: http://review.whamcloud.com/15300 Reviewed-on: http://review.whamcloud.com/15301

[PATCH 0/4] staging: lustre: obd: reserve connection flags

Reserve several OBD_CONNECT_* flags for future use. Fan Yong (4): staging: lustre: obd: reserve connection flag OBD_CONNECT_SUBTREE staging: lustre: obd: reserve connection flag OBD_CONNECT_LOCK_AHEAD staging: lustre: obd: reserve connection flag OBD_CONNECT_OBDOPACK staging: lustre: obd:

[PATCH 3/4] staging: lustre: obd: reserve connection flag OBD_CONNECT_OBDOPACK

From: Fan Yong The connection flag OBD_CONNECT_OBDOPACK will be used for the following the patch: LU-4215 optimize OUT protocol http://review.whamcloud.com/15336 Land the connection flags to upstream client earlier for reserving the slot to avoid potential conflict with others. Signed-off-by:

[PATCH 2/4] staging: lustre: obd: reserve connection flag OBD_CONNECT_LOCK_AHEAD

From: Fan Yong The connection flag OBD_CONNECT_LOCK_AHEAD will be used for the following the patch: LU-6917 LDLM lock ahead http://review.whamcloud.com/13564 Land the connection flags to upstream client earlier for reserving the slot to avoid potential conflict with others. Signed-off-by: Fan

[PATCH 4/5] staging: lustre: ldlm: rename LDLM_CANCEL_* flags

From: Andreas Dilger Rename LDLM_CANCEL_* flags (used with enum ldlm_lru_flags) to LDLM_LRU_FLAGS_* to avoid confusion with enum ldlm_cancel_flags. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142 Reviewed-on: http://review.whamcloud.com/15300 Reviewed-on:

[PATCH 1/4] staging: lustre: obd: reserve connection flag OBD_CONNECT_SUBTREE

From: Fan Yong The connection flag OBD_CONNECT_SUBTREE will be used for the following the patch: LU-28 mounting of filesystem from MDS http://review.whamcloud.com/5007 Land the connection flags to master earlier for reserving the slot to avoid potential conflict with others.

[PATCH 1/4] staging: lustre: obd: reserve connection flag OBD_CONNECT_SUBTREE

From: Fan Yong The connection flag OBD_CONNECT_SUBTREE will be used for the following the patch: LU-28 mounting of filesystem from MDS http://review.whamcloud.com/5007 Land the connection flags to master earlier for reserving the slot to avoid potential conflict with others. Signed-off-by: Fan

[PATCH 5/5] staging: lustre: ldlm: change "int" to proper enum type

From: Andreas Dilger Fix users of flags that were using "int" instead of named enum. Rename some "flags" variables to distinguish between different flags. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142

[PATCH 0/5] staging: lustre: ldlm: remove ldlm typedef usage from code

Replace usage of ldlm_policy_data_t, ldlm_wire_policy_t, ldlm_side_t with named enums to conform to upstream coding style. Fix users of flags that were using "int" instead of named enum. Rename some "flags" variables to distinguish between different flags. Rename LDLM_CANCEL_* flags (used with

[PATCH 0/5] staging: lustre: ldlm: remove ldlm typedef usage from code

Replace usage of ldlm_policy_data_t, ldlm_wire_policy_t, ldlm_side_t with named enums to conform to upstream coding style. Fix users of flags that were using "int" instead of named enum. Rename some "flags" variables to distinguish between different flags. Rename LDLM_CANCEL_* flags (used with

[PATCH 5/5] staging: lustre: ldlm: change "int" to proper enum type

From: Andreas Dilger Fix users of flags that were using "int" instead of named enum. Rename some "flags" variables to distinguish between different flags. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142 Reviewed-on: http://review.whamcloud.com/15300

Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

"Serge E. Hallyn" writes: > Root in a user ns cannot be trusted to write a traditional > security.capability xattr. If it were allowed to do so, then any > unprivileged user on the host could map his own uid to root in a > namespace, write the xattr, and execute the file with

Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic

"Serge E. Hallyn" writes: > Root in a user ns cannot be trusted to write a traditional > security.capability xattr. If it were allowed to do so, then any > unprivileged user on the host could map his own uid to root in a > namespace, write the xattr, and execute the file with privilege on the >

[PATCH 2/5] staging: lustre: ldlm: remove ldlm_side_t typedef usage from code

From: Andreas Dilger Replace usage of ldlm_side_t with named enums to conform to upstream coding style. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142 Reviewed-on: http://review.whamcloud.com/15300

[PATCH 2/5] staging: lustre: ldlm: remove ldlm_side_t typedef usage from code

From: Andreas Dilger Replace usage of ldlm_side_t with named enums to conform to upstream coding style. Signed-off-by: Andreas Dilger Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6142 Reviewed-on: http://review.whamcloud.com/15300 Reviewed-on: http://review.whamcloud.com/15301

Re: [PATCH] PCI Hotplug: cpqphp: Add missing call to pci_disable_device

On Sat, Nov 19, 2016 at 06:41:48PM +0100, Quentin Lambert wrote: > Most error branches following the call to pci_enable_device contain > a call to pci_disable_device. This patch add these calls where they are > missing. > > This issue was found with Hector. > > Signed-off-by: Quentin Lambert

Re: [PATCH] PCI Hotplug: cpqphp: Add missing call to pci_disable_device

On Sat, Nov 19, 2016 at 06:41:48PM +0100, Quentin Lambert wrote: > Most error branches following the call to pci_enable_device contain > a call to pci_disable_device. This patch add these calls where they are > missing. > > This issue was found with Hector. > > Signed-off-by: Quentin Lambert

Re: [PATCH 05/14] perf tools: handle PERF_RECORD_OVERHEAD record type

On Wed, Nov 23, 2016 at 11:35:59PM +0100, Jiri Olsa wrote: > On Wed, Nov 23, 2016 at 04:44:43AM -0500, kan.li...@intel.com wrote: > > SNIP > > > + > > static void dso__adjust_kmod_long_name(struct dso *dso, const char > > *filename) > > { > > const char *dup_filename; > > @@ -1536,6

Re: [PATCH 05/14] perf tools: handle PERF_RECORD_OVERHEAD record type

On Wed, Nov 23, 2016 at 11:35:59PM +0100, Jiri Olsa wrote: > On Wed, Nov 23, 2016 at 04:44:43AM -0500, kan.li...@intel.com wrote: > > SNIP > > > + > > static void dso__adjust_kmod_long_name(struct dso *dso, const char > > *filename) > > { > > const char *dup_filename; > > @@ -1536,6

Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available [ver #3]

On Nov 23, 2016, at 1:37 AM, Michael Kerrisk wrote: > > Hi David, > > On 11/23/2016 01:55 AM, David Howells wrote: >> Add a system call to make extended file information available, including >> file creation and some attribute flags where available through the >>

Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available [ver #3]

On Nov 23, 2016, at 1:37 AM, Michael Kerrisk wrote: > > Hi David, > > On 11/23/2016 01:55 AM, David Howells wrote: >> Add a system call to make extended file information available, including >> file creation and some attribute flags where available through the >> underlying filesystem. >> >>

Re: [PATCH 1/2] PCI: iproc: fix 32-bit build

On Tue, Nov 22, 2016 at 03:17:51PM +0100, Arnd Bergmann wrote: > The newly added code to setup the inbound ranges causes a link error > on 32-bit machines from a 32-bit division: > > drivers/pci/host/pcie-iproc.o: In function `iproc_pcie_setup_ib': >

Re: [PATCH 1/2] PCI: iproc: fix 32-bit build

On Tue, Nov 22, 2016 at 03:17:51PM +0100, Arnd Bergmann wrote: > The newly added code to setup the inbound ranges causes a link error > on 32-bit machines from a 32-bit division: > > drivers/pci/host/pcie-iproc.o: In function `iproc_pcie_setup_ib': >

Re: [PATCH 2/2] Add support for the Nexbox A1 board based on the Amlogic S912 SoC.

On Mon, Nov 21, 2016 at 05:29:05PM +0100, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/arm/amlogic.txt | 1 + > arch/arm64/boot/dts/amlogic/Makefile | 1 + >

Re: [PATCH 2/2] Add support for the Nexbox A1 board based on the Amlogic S912 SoC.

On Mon, Nov 21, 2016 at 05:29:05PM +0100, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/arm/amlogic.txt | 1 + > arch/arm64/boot/dts/amlogic/Makefile | 1 + > .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 169 >

Re: [PATCH 06/14] perf tools: show NMI overhead

On Wed, Nov 23, 2016 at 04:44:44AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Caculate the total NMI overhead on each CPU, and display them in perf > report so the output looks like this: --- # Elapsed time: 1720167944 ns # Overhead: # CPU 6 #

Re: [PATCH 06/14] perf tools: show NMI overhead

On Wed, Nov 23, 2016 at 04:44:44AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Caculate the total NMI overhead on each CPU, and display them in perf > report so the output looks like this: --- # Elapsed time: 1720167944 ns # Overhead: # CPU 6 # NMI#: 27 time:

Re: [PATCH 06/14] perf tools: show NMI overhead

On Wed, Nov 23, 2016 at 04:44:44AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Caculate the total NMI overhead on each CPU, and display them in perf > report > > Signed-off-by: Kan Liang > --- > tools/perf/builtin-report.c | 11 +++

Re: [PATCH 06/14] perf tools: show NMI overhead

On Wed, Nov 23, 2016 at 04:44:44AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Caculate the total NMI overhead on each CPU, and display them in perf > report please put example output into chagelog thanks, jirka

Re: [PATCH 06/14] perf tools: show NMI overhead

On Wed, Nov 23, 2016 at 04:44:44AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Caculate the total NMI overhead on each CPU, and display them in perf > report please put example output into chagelog thanks, jirka

Re: [PATCH 06/14] perf tools: show NMI overhead

On Wed, Nov 23, 2016 at 04:44:44AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Caculate the total NMI overhead on each CPU, and display them in perf > report > > Signed-off-by: Kan Liang > --- > tools/perf/builtin-report.c | 11 +++ > tools/perf/util/event.h | 4

Re: [PATCH 3/3] firmware: qcom: scm: Add empty functions to help compile testing

On 11/22, Stanimir Varbanov wrote: > This will help to compile testing drivers which depends on scm > functions with COMPILE_TEST Kconfig option. > > Signed-off-by: Stanimir Varbanov > --- Ok. I guess treating scm like a library that has to be selected isn't

Re: [PATCH 3/3] firmware: qcom: scm: Add empty functions to help compile testing

On 11/22, Stanimir Varbanov wrote: > This will help to compile testing drivers which depends on scm > functions with COMPILE_TEST Kconfig option. > > Signed-off-by: Stanimir Varbanov > --- Ok. I guess treating scm like a library that has to be selected isn't possible anymore. Reviewed-by:

Re: [PATCH 1/3] remoteproc: qcom: mdt_loader: add include for sizes

On 11/22, Stanimir Varbanov wrote: > Add linux/sizes.h to prevent build failure on non ARM architectures > as: > > CC [M] drivers/remoteproc/qcom_mdt_loader.o > In file included from include/linux/cache.h:4:0, > from include/linux/printk.h:8, > from

Re: [PATCH 1/3] remoteproc: qcom: mdt_loader: add include for sizes

On 11/22, Stanimir Varbanov wrote: > Add linux/sizes.h to prevent build failure on non ARM architectures > as: > > CC [M] drivers/remoteproc/qcom_mdt_loader.o > In file included from include/linux/cache.h:4:0, > from include/linux/printk.h:8, > from

Re: [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes

On 11/23/2016 04:32 PM, Kevin Hilman wrote: David Lechner writes: On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote: 2016-11-22 23:23 GMT+01:00 David Lechner : On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote: Add the nodes for the MSTPRI

Re: [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes

On 11/23/2016 04:32 PM, Kevin Hilman wrote: David Lechner writes: On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote: 2016-11-22 23:23 GMT+01:00 David Lechner : On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote: Add the nodes for the MSTPRI configuration and DDR2/mDDR memory controller

Re: wl1251 & mac address & calibration data

On Wednesday 23 November 2016 23:23:35 Pavel Machek wrote: > Hi! > > > > > As wl1251.ko does not accept mac_address as module parameter, > > > > such modprobe hook does not help -- as there is absolutely no > > > > way from userspace to set or change (permanent) mac address. > > > > > > Quoting

Re: wl1251 & mac address & calibration data

On Wednesday 23 November 2016 23:23:35 Pavel Machek wrote: > Hi! > > > > > As wl1251.ko does not accept mac_address as module parameter, > > > > such modprobe hook does not help -- as there is absolutely no > > > > way from userspace to set or change (permanent) mac address. > > > > > > Quoting

Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available [ver #3]

On Nov 23, 2016, at 1:37 AM, Michael Kerrisk wrote: > > Hi David, > > On 11/23/2016 01:55 AM, David Howells wrote: >> Add a system call to make extended file information available, including >> file creation and some attribute flags where available through the >>

Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available [ver #3]

On Nov 23, 2016, at 1:37 AM, Michael Kerrisk wrote: > > Hi David, > > On 11/23/2016 01:55 AM, David Howells wrote: >> Add a system call to make extended file information available, including >> file creation and some attribute flags where available through the >> underlying filesystem. >> >>

How are you doing?

Hey! my name is Monica, Can i be your friend?

How are you doing?

Hey! my name is Monica, Can i be your friend?

Re: Enabling peer to peer device transactions for PCIe devices

On Wed, Nov 23, 2016 at 1:55 PM, Jason Gunthorpe wrote: > On Wed, Nov 23, 2016 at 02:11:29PM -0700, Logan Gunthorpe wrote: >> > As I said, there is no possible special handling. Standard IB hardware >> > does not support changing the DMA address once a MR is

Re: Enabling peer to peer device transactions for PCIe devices

On Wed, Nov 23, 2016 at 1:55 PM, Jason Gunthorpe wrote: > On Wed, Nov 23, 2016 at 02:11:29PM -0700, Logan Gunthorpe wrote: >> > As I said, there is no possible special handling. Standard IB hardware >> > does not support changing the DMA address once a MR is created. Forget >> > about doing that.

[PATCH] clk: bcm: Make COMMON_CLK_IPROC into a library

The broadcom clk driver Kconfig file selects and depends on the COMMON_CLK_IPROC config for different SoC specific drivers. Let's simplify this by always selecting the COMMON_CLK_IPROC config, turning it into a set of library code. We still want to retain the SoC specific options, so we leave

[PATCH] clk: bcm: Make COMMON_CLK_IPROC into a library

The broadcom clk driver Kconfig file selects and depends on the COMMON_CLK_IPROC config for different SoC specific drivers. Let's simplify this by always selecting the COMMON_CLK_IPROC config, turning it into a set of library code. We still want to retain the SoC specific options, so we leave

Re: RFC: documentation of the autogroup feature

On 11/23/2016 06:19 PM, Mike Galbraith wrote: > On Wed, 2016-11-23 at 17:05 +0100, Michael Kerrisk (man-pages) wrote: >>> I don't think we need group scheduling details, there's plenty of >>> documentation elsewhere for those who want theory. >> >> Actually, which documentation were you

Re: RFC: documentation of the autogroup feature

On 11/23/2016 06:19 PM, Mike Galbraith wrote: > On Wed, 2016-11-23 at 17:05 +0100, Michael Kerrisk (man-pages) wrote: >>> I don't think we need group scheduling details, there's plenty of >>> documentation elsewhere for those who want theory. >> >> Actually, which documentation were you

Re: [PATCH v3 0/3] Stop sched tick in idle injection task

On Wed, Nov 23, 2016 at 10:45 PM, Peter Zijlstra wrote: > On Wed, Nov 23, 2016 at 10:12:46PM +0100, Rafael J. Wysocki wrote: >> On Wed, Nov 23, 2016 at 9:13 PM, Jacob Pan > >> >> Any objections anyone? >> >> If not, I'll queue up this series for 4.10. > > 1h30 is a bit short

Re: [PATCH v3 0/3] Stop sched tick in idle injection task

On Wed, Nov 23, 2016 at 10:45 PM, Peter Zijlstra wrote: > On Wed, Nov 23, 2016 at 10:12:46PM +0100, Rafael J. Wysocki wrote: >> On Wed, Nov 23, 2016 at 9:13 PM, Jacob Pan > >> >> Any objections anyone? >> >> If not, I'll queue up this series for 4.10. > > 1h30 is a bit short to expect people to

Re: [PATCH] PM / wakeirq: report wakeup events in dedicated wake-IRQs

On Fri, Nov 18, 2016 at 9:18 PM, Tony Lindgren wrote: > Hi, > > * Rafael J. Wysocki [16 16:35]: >> However, my understanding is that the current code actually works for >> runtime PM just fine. > > Hmm well I just noticed that for drivers not using

Re: [PATCH] PM / wakeirq: report wakeup events in dedicated wake-IRQs

On Fri, Nov 18, 2016 at 9:18 PM, Tony Lindgren wrote: > Hi, > > * Rafael J. Wysocki [16 16:35]: >> However, my understanding is that the current code actually works for >> runtime PM just fine. > > Hmm well I just noticed that for drivers not using autosuspend it can be > flakey, see the

Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state binding

Vincent Guittot writes: > On 23 November 2016 at 16:51, Kevin Hilman wrote: >> Vincent Guittot writes: >> >>> On 22 November 2016 at 19:12, Kevin Hilman wrote: Viresh Kumar

Re: [PATCH 1/2] PM / Domains: Introduce domain-performance-state binding

Vincent Guittot writes: > On 23 November 2016 at 16:51, Kevin Hilman wrote: >> Vincent Guittot writes: >> >>> On 22 November 2016 at 19:12, Kevin Hilman wrote: Viresh Kumar writes: > On 21-11-16, 09:07, Rob Herring wrote: >> On Fri, Nov 18, 2016 at 02:53:12PM +0530, Viresh

Re: [PATCH 05/14] perf tools: handle PERF_RECORD_OVERHEAD record type

On Wed, Nov 23, 2016 at 04:44:43AM -0500, kan.li...@intel.com wrote: SNIP > + > static void dso__adjust_kmod_long_name(struct dso *dso, const char *filename) > { > const char *dup_filename; > @@ -1536,6 +1542,8 @@ int machine__process_event(struct machine *machine, > union perf_event

Re: [PATCH 05/14] perf tools: handle PERF_RECORD_OVERHEAD record type

On Wed, Nov 23, 2016 at 04:44:43AM -0500, kan.li...@intel.com wrote: SNIP > + > static void dso__adjust_kmod_long_name(struct dso *dso, const char *filename) > { > const char *dup_filename; > @@ -1536,6 +1542,8 @@ int machine__process_event(struct machine *machine, > union perf_event

Re: [PATCH kernel v3] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

On Mon, Oct 24, 2016 at 06:04:17PM +1100, Alexey Kardashevskiy wrote: > There is at least one Chelsio 10Gb card which uses VPD area to store > some custom blocks (example below). However pci_vpd_size() returns > the length of the first block only assuming that there can be only > one VPD "End Tag"

Re: [PATCH kernel v3] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

On Mon, Oct 24, 2016 at 06:04:17PM +1100, Alexey Kardashevskiy wrote: > There is at least one Chelsio 10Gb card which uses VPD area to store > some custom blocks (example below). However pci_vpd_size() returns > the length of the first block only assuming that there can be only > one VPD "End Tag"

<    1   2   3   4   5   6   7   8   9   10   >