Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

On 20.02.2017 04:47, Baolin Wang wrote: Hi Mathias, On 6 February 2017 at 13:26, Baolin Wang wrote: Hi Mathias, On 31 January 2017 at 21:14, Mathias Nyman wrote: On 16.01.2017 12:56, Baolin Wang wrote: Hi Mathias, Hi Sorry about

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

On 20.02.2017 04:47, Baolin Wang wrote: Hi Mathias, On 6 February 2017 at 13:26, Baolin Wang wrote: Hi Mathias, On 31 January 2017 at 21:14, Mathias Nyman wrote: On 16.01.2017 12:56, Baolin Wang wrote: Hi Mathias, Hi Sorry about the long review delay CC Alan in case my pm assumptions

Re: [PATCH 04/21] ARM: sun8i: dt: Add DT bindings documentation for Allwinner dwmac-sun8i

On Thu, Feb 16, 2017 at 12:58:46PM -0800, Florian Fainelli wrote: > On 02/16/2017 04:48 AM, Corentin Labbe wrote: > > + > > +Optional properties: > > +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. > > Default is 0) > > +- allwinner,rx-delay: RX clock delay chain value.

Re: [PATCH 04/21] ARM: sun8i: dt: Add DT bindings documentation for Allwinner dwmac-sun8i

On Thu, Feb 16, 2017 at 12:58:46PM -0800, Florian Fainelli wrote: > On 02/16/2017 04:48 AM, Corentin Labbe wrote: > > + > > +Optional properties: > > +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. > > Default is 0) > > +- allwinner,rx-delay: RX clock delay chain value.

Re: next-20170217 boot on POWER8 LPAR : WARNING @kernel/jump_label.c:287

Hi, On 02/19/2017 09:07 AM, Sachin Sant wrote: > While booting next-20170217 on a POWER8 LPAR following > warning is displayed. > > Reverting the following commit helps boot cleanly. > commit 3821fd35b5 : jump_label: Reduce the size of struct static_key > > [ 11.393008] [ cut

Re: next-20170217 boot on POWER8 LPAR : WARNING @kernel/jump_label.c:287

Hi, On 02/19/2017 09:07 AM, Sachin Sant wrote: > While booting next-20170217 on a POWER8 LPAR following > warning is displayed. > > Reverting the following commit helps boot cleanly. > commit 3821fd35b5 : jump_label: Reduce the size of struct static_key > > [ 11.393008] [ cut

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Monday, February 20, 2017 02:49:18 PM Rafael J. Wysocki wrote: > On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote: > > On 17-02-17, 13:48, Peter Zijlstra wrote: > > > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote: > > > > On Thursday, February 16, 2017 01:36:05 PM

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Monday, February 20, 2017 02:49:18 PM Rafael J. Wysocki wrote: > On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote: > > On 17-02-17, 13:48, Peter Zijlstra wrote: > > > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote: > > > > On Thursday, February 16, 2017 01:36:05 PM

Re: [PATCH 3/4] sparc: convert mdesc_handle.refcnt from atomic_t to refcount_t

From: Elena Reshetova Date: Mon, 20 Feb 2017 13:06:20 +0200 > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to

Re: [PATCH 3/4] sparc: convert mdesc_handle.refcnt from atomic_t to refcount_t

From: Elena Reshetova Date: Mon, 20 Feb 2017 13:06:20 +0200 > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > >

Re: [PATCH] ipmi: bt-bmc: Use a regmap for register access

On Mon, 2017-02-20 at 07:35 -0600, Corey Minyard wrote: > On 02/19/2017 10:45 PM, Andrew Jeffery wrote: > > Hi Cory, > > > > On Tue, 2016-12-06 at 16:02 +0100, Cédric Le Goater wrote: > > > [ this is a resend bc of some mailing list issues] > > > > > > On 12/06/2016 03:57 AM, Andrew Jeffery

Re: [PATCH] ipmi: bt-bmc: Use a regmap for register access

On Mon, 2017-02-20 at 07:35 -0600, Corey Minyard wrote: > On 02/19/2017 10:45 PM, Andrew Jeffery wrote: > > Hi Cory, > > > > On Tue, 2016-12-06 at 16:02 +0100, Cédric Le Goater wrote: > > > [ this is a resend bc of some mailing list issues] > > > > > > On 12/06/2016 03:57 AM, Andrew Jeffery

Re: linux-next: manual merge of the tip tree with the openrisc tree

On Mon, Feb 20, 2017 at 12:28:44PM +0100, Peter Zijlstra wrote: > On Mon, Feb 20, 2017 at 12:18:05PM +0100, Peter Zijlstra wrote: > > On Sun, Feb 19, 2017 at 04:26:54PM +0900, Stafford Horne wrote: > > > On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote: > > > > Hi all, > > > > > >

Re: linux-next: manual merge of the tip tree with the openrisc tree

On Mon, Feb 20, 2017 at 12:28:44PM +0100, Peter Zijlstra wrote: > On Mon, Feb 20, 2017 at 12:18:05PM +0100, Peter Zijlstra wrote: > > On Sun, Feb 19, 2017 at 04:26:54PM +0900, Stafford Horne wrote: > > > On Fri, Feb 17, 2017 at 12:43:21PM +1100, Stephen Rothwell wrote: > > > > Hi all, > > > > > >

Re: [PATCH 2/6] perf utils: Check verbose flag properly

Em Fri, Feb 17, 2017 at 05:17:38PM +0900, Namhyung Kim escreveu: > It now can have negative value to suppress the message entirely. So it > needs to check it being positive. find tools/perf -name "*.[chly]" | xargs grep -w verbose Shows several other places, I'm trying to plug those, fixed it

Re: [PATCH 2/6] perf utils: Check verbose flag properly

Em Fri, Feb 17, 2017 at 05:17:38PM +0900, Namhyung Kim escreveu: > It now can have negative value to suppress the message entirely. So it > needs to check it being positive. find tools/perf -name "*.[chly]" | xargs grep -w verbose Shows several other places, I'm trying to plug those, fixed it

[PATCH] gpio: aspeed: Add debounce support

Each GPIO in the Aspeed GPIO controller can choose one of four input debounce states: to not debounce an input or to select from one of three programmable debounce timer values. Each GPIO in a four-bank-set is assigned one bit in each of two debounce configuration registers dedicated to the set,

[PATCH] gpio: aspeed: Add debounce support

Each GPIO in the Aspeed GPIO controller can choose one of four input debounce states: to not debounce an input or to select from one of three programmable debounce timer values. Each GPIO in a four-bank-set is assigned one bit in each of two debounce configuration registers dedicated to the set,

[PATCH] pinctrl: aspeed: Add initial pinconf support

Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the

[PATCH] pinctrl: aspeed: Add initial pinconf support

Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the

[PATCH 2/2] docs / driver-api: Fix structure references in device_link.rst

From: Rafael J. Wysocki The format of the structure references in device_link.rst is incorrect, because it doesn't cause proper references to the struct data types to be generated (for struct dev_pm_domain in particular). Fix that by using the :c:type:`struct name `

[PATCH 1/2] PM / docs: Fix structure references in device.rst

From: Rafael J. Wysocki There is a better way to represent structure references than it was done in device.rst by commit 730c4c053012 (PM / sleep / docs: Convert PM notifiers document to reST), which is to use "struct name" as a link caption (e.g. :c:type:`struct

[PATCH 0/2] PM / docs: Fixes for PM and device links driver-api

Hi Jon, These two patches fix references to struct data types in two documents that did those things more or less incorrectly. Both of them fix existing commits, one in the mainline and one in your tree. Thanks, Rafael

[PATCH 0/2] PM / docs: Fixes for PM and device links driver-api

Hi Jon, These two patches fix references to struct data types in two documents that did those things more or less incorrectly. Both of them fix existing commits, one in the mainline and one in your tree. Thanks, Rafael

[PATCH 2/2] docs / driver-api: Fix structure references in device_link.rst

From: Rafael J. Wysocki The format of the structure references in device_link.rst is incorrect, because it doesn't cause proper references to the struct data types to be generated (for struct dev_pm_domain in particular). Fix that by using the :c:type:`struct name ` convention for encoding

[PATCH 1/2] PM / docs: Fix structure references in device.rst

From: Rafael J. Wysocki There is a better way to represent structure references than it was done in device.rst by commit 730c4c053012 (PM / sleep / docs: Convert PM notifiers document to reST), which is to use "struct name" as a link caption (e.g. :c:type:`struct device `). That will cause

Re: [PATCH net-next v3 0/4] net: mvneta: improve rx/tx performance

Hi Jisheng, On lun., févr. 20 2017, Jisheng Zhang wrote: > In hot code path such as mvneta_rx_swbm(), we access fields of rx_desc > and tx_desc. These DMA descs are allocated by dma_alloc_coherent, they > are uncacheable if the device isn't cache coherent, reading from >

Re: [PATCH net-next v3 0/4] net: mvneta: improve rx/tx performance

Hi Jisheng, On lun., févr. 20 2017, Jisheng Zhang wrote: > In hot code path such as mvneta_rx_swbm(), we access fields of rx_desc > and tx_desc. These DMA descs are allocated by dma_alloc_coherent, they > are uncacheable if the device isn't cache coherent, reading from > uncached memory is

Re: [PATCH] cpufreq: imx6q: use devm to fetch resources

Am Montag, den 20.02.2017, 16:02 +0200 schrieb Leonard Crestez: > Replace the clk_get and regulator_get will devm variants to free the > resources automatically when probe failed or driver is removed. > > The device we are probing is not cpu_dev but the cpufreq platform_device > (pdev->dev). In

Re: [PATCH] cpufreq: imx6q: use devm to fetch resources

Am Montag, den 20.02.2017, 16:02 +0200 schrieb Leonard Crestez: > Replace the clk_get and regulator_get will devm variants to free the > resources automatically when probe failed or driver is removed. > > The device we are probing is not cpu_dev but the cpufreq platform_device > (pdev->dev). In

Re: [RFC] perf/sdt: Directly record SDT event with 'perf record'

Em Mon, Feb 20, 2017 at 04:31:50PM +0530, Ravi Bangoria escreveu: > Thanks Ingo, > > On Monday 20 February 2017 02:12 PM, Ingo Molnar wrote: > > * Ravi Bangoria wrote: > > > >> What should be the behavior of the tool? Should it record only one > >>

Re: [RFC] perf/sdt: Directly record SDT event with 'perf record'

Em Mon, Feb 20, 2017 at 04:31:50PM +0530, Ravi Bangoria escreveu: > Thanks Ingo, > > On Monday 20 February 2017 02:12 PM, Ingo Molnar wrote: > > * Ravi Bangoria wrote: > > > >> What should be the behavior of the tool? Should it record only one > >> 'sdt_libpthread:mutex_entry' which exists in

Re: next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Sat, Feb 18, 2017 at 07:05:20PM +0100, Pavel Machek wrote: > Hi! > > > > I guess I can. But I'll only have one 80x25 screen to look at... > > > > > > .config is attached. > > > > Ah this is x86-32, interesting! I'm going to try to boot that, we never > > know. > > > > Thanks a lot! > >

Re: next_tick hang was Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Sat, Feb 18, 2017 at 07:05:20PM +0100, Pavel Machek wrote: > Hi! > > > > I guess I can. But I'll only have one 80x25 screen to look at... > > > > > > .config is attached. > > > > Ah this is x86-32, interesting! I'm going to try to boot that, we never > > know. > > > > Thanks a lot! > >

Re: [RFC][PATCH] cpufreq: User/admin documentation update and consolidation

On Monday, February 20, 2017 03:26:08 PM Viresh Kumar wrote: > On 18-02-17, 02:36, Rafael J. Wysocki wrote: > > +CPU Initialization > > +== > > + > > > > +Next, the scaling driver's ``->init()`` callback is invoked with the policy > > +pointer of the new CPU passed to it as the

Re: [RFC][PATCH] cpufreq: User/admin documentation update and consolidation

On Monday, February 20, 2017 03:26:08 PM Viresh Kumar wrote: > On 18-02-17, 02:36, Rafael J. Wysocki wrote: > > +CPU Initialization > > +== > > + > > > > +Next, the scaling driver's ``->init()`` callback is invoked with the policy > > +pointer of the new CPU passed to it as the

[PATCH] cpufreq: imx6q: use devm to fetch resources

Replace the clk_get and regulator_get will devm variants to free the resources automatically when probe failed or driver is removed. The device we are probing is not cpu_dev but the cpufreq platform_device (pdev->dev). In order for this to actually work correctly we assign to the cpufreq device

[PATCH] cpufreq: imx6q: use devm to fetch resources

Replace the clk_get and regulator_get will devm variants to free the resources automatically when probe failed or driver is removed. The device we are probing is not cpu_dev but the cpufreq platform_device (pdev->dev). In order for this to actually work correctly we assign to the cpufreq device

Re: [PATCH v2 1/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node

Hello Rob, On 01/10/2017 04:55 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 01/10/2017 03:47 PM, Krzysztof Kozlowski wrote: >> On Tue, Jan 10, 2017 at 02:38:30PM -0300, Javier Martinez Canillas wrote: >>> This patch fixes the following DTC warning about a mismatch >>> between a

Re: [PATCH v2 1/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node

Hello Rob, On 01/10/2017 04:55 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 01/10/2017 03:47 PM, Krzysztof Kozlowski wrote: >> On Tue, Jan 10, 2017 at 02:38:30PM -0300, Javier Martinez Canillas wrote: >>> This patch fixes the following DTC warning about a mismatch >>> between a

URGENT

-- Good day friend , I apologize for sending you this sensitive information via e-mail, This is due to the urgency of the project . I'm Mr Fredrick Moor, a personal banker to late engineer,a National of your Country, who has lived in Lome Togo for the past 35 years, and whom here in after shall

URGENT

-- Good day friend , I apologize for sending you this sensitive information via e-mail, This is due to the urgency of the project . I'm Mr Fredrick Moor, a personal banker to late engineer,a National of your Country, who has lived in Lome Togo for the past 35 years, and whom here in after shall

Re: [PATCH] mm/thp/autonuma: Use TNF flag instead of vm fault.

On Sun, 2017-02-19 at 15:29 +0530, Aneesh Kumar K.V wrote: > We are using wrong flag value in task_numa_falt function. This can > result in > us doing wrong numa fault statistics update, because we update > num_pages_migrate > and numa_fault_locality etc based on the flag argument passed. > >

Re: [PATCH 2/4] Documentation: devicetree: arm: Document Marvell IAP140

Hello, On Mon, 20 Feb 2017 14:16:13 +0100, Andreas Färber wrote: > I'm confused now. According to Marvell IR [0] they are NASDAQ-listed as > MRVL. My understanding is that in that case the official vendor prefix > becomes mrvl. Why not here? Not sure why, but as of today, we have a mix of

Re: [PATCH] mm/thp/autonuma: Use TNF flag instead of vm fault.

On Sun, 2017-02-19 at 15:29 +0530, Aneesh Kumar K.V wrote: > We are using wrong flag value in task_numa_falt function. This can > result in > us doing wrong numa fault statistics update, because we update > num_pages_migrate > and numa_fault_locality etc based on the flag argument passed. > >

Re: [PATCH 2/4] Documentation: devicetree: arm: Document Marvell IAP140

Hello, On Mon, 20 Feb 2017 14:16:13 +0100, Andreas Färber wrote: > I'm confused now. According to Marvell IR [0] they are NASDAQ-listed as > MRVL. My understanding is that in that case the official vendor prefix > becomes mrvl. Why not here? Not sure why, but as of today, we have a mix of

Re: [PATCH] groups: don't return unmapped gids in getgroups(2)

On Thu, Feb 16, 2017 at 7:19 PM, Eric W. Biederman wrote: > > Added a few more relevant mailing-lists to the CC list. > > Aleksa Sarai writes: > >> One thing overlooked by commit 9cc46516ddf4 ("userns: Add a knob to >> disable setgroups on a per user

Re: [PATCH] groups: don't return unmapped gids in getgroups(2)

On Thu, Feb 16, 2017 at 7:19 PM, Eric W. Biederman wrote: > > Added a few more relevant mailing-lists to the CC list. > > Aleksa Sarai writes: > >> One thing overlooked by commit 9cc46516ddf4 ("userns: Add a knob to >> disable setgroups on a per user namespace basis") is that because >>

Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

On Mon, Feb 20, 2017 at 03:09:13PM +0200, Sakari Ailus wrote: > I've tested ACPI, will test DT soon... DT case works, too (Nokia N9). -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

On Mon, Feb 20, 2017 at 03:09:13PM +0200, Sakari Ailus wrote: > I've tested ACPI, will test DT soon... DT case works, too (Nokia N9). -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 01/14] Documentation: dt/bindings: Document pinctrl-ingenic

On Thu, Feb 9, 2017 at 6:28 PM, Paul Cercueil wrote: > I was thinking that instead of having one pinctrl-ingenic instance covering > 0x600 of register space, and 6 instances of gpio-ingenic having 0x100 each, > I could just have 6 instances of pinctrl-ingenic, each one with

Re: [PATCH v3 01/14] Documentation: dt/bindings: Document pinctrl-ingenic

On Thu, Feb 9, 2017 at 6:28 PM, Paul Cercueil wrote: > I was thinking that instead of having one pinctrl-ingenic instance covering > 0x600 of register space, and 6 instances of gpio-ingenic having 0x100 each, > I could just have 6 instances of pinctrl-ingenic, each one with an instance > of

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote: > On 17-02-17, 13:48, Peter Zijlstra wrote: > > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote: > > > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote: > > > > On Thu, Feb 16, 2017 at 03:42:10PM +0530,

Re: [PATCH] cpufreq: schedutil: govern how frequently we change frequency with rate_limit

On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote: > On 17-02-17, 13:48, Peter Zijlstra wrote: > > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote: > > > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote: > > > > On Thu, Feb 16, 2017 at 03:42:10PM +0530,

Re: [PATCH 2/4] Documentation: devicetree: arm: Document Marvell IAP140

Hi, Am 20.02.2017 um 13:56 schrieb Thomas Petazzoni: > On Sun, 19 Feb 2017 04:19:58 +0100, Andreas Färber wrote: > >> + - compatible : must contain "mrvl,iap140" > > Even though there's indeed a good number of existing "mrvl," compatible > strings in the tree, the official vendor prefix

Re: [PATCH 2/4] Documentation: devicetree: arm: Document Marvell IAP140

Hi, Am 20.02.2017 um 13:56 schrieb Thomas Petazzoni: > On Sun, 19 Feb 2017 04:19:58 +0100, Andreas Färber wrote: > >> + - compatible : must contain "mrvl,iap140" > > Even though there's indeed a good number of existing "mrvl," compatible > strings in the tree, the official vendor prefix

Re: [PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

Hello, On 01/02/2017 03:06 PM, Javier Martinez Canillas wrote: > The OF device ID table doesn't have a sentinel NULL entry and so it > causes the following error: > > FATAL: drivers/auxdisplay/img-ascii-lcd: struct of_device_id is not > terminated with a NULL entry! >

Re: [PATCH 1/2] auxdisplay: img-ascii-lcd: Add a sentinel entry to OF device ID table

Hello, On 01/02/2017 03:06 PM, Javier Martinez Canillas wrote: > The OF device ID table doesn't have a sentinel NULL entry and so it > causes the following error: > > FATAL: drivers/auxdisplay/img-ascii-lcd: struct of_device_id is not > terminated with a NULL entry! >

[PATCH 4/4] perf/x86/intel/pt: Handle VMX better

Since commit 1c5ac21a0e ("perf/x86/intel/pt: Don't die on VMXON") PT events depend on re-scheduling to get enabled after a VMX session has taken place. This is, in particular, a problem for CPU context events, which don't normally get re-scheduled, unless there is a reason. This patch changes the

[PATCH 4/4] perf/x86/intel/pt: Handle VMX better

Since commit 1c5ac21a0e ("perf/x86/intel/pt: Don't die on VMXON") PT events depend on re-scheduling to get enabled after a VMX session has taken place. This is, in particular, a problem for CPU context events, which don't normally get re-scheduled, unless there is a reason. This patch changes the

[PATCH RFC] net: stmmac: unify registers dumps methods

The stmmac driver have two methods for registers dumps: via ethtool and at init (if NETIF_MSG_HW is enabled). It is better to keep only one method, ethtool, since the other was ugly. This patch convert all dump_regs() function from "printing regs" to "fill the reg_space used by ethtool".

[PATCH RFC] net: stmmac: unify registers dumps methods

hello The following patch address the problem that two way of dumping registers are available in stmmac, via ethtool and directly at init (if NETIF_MSG_HW is enabled). It is better to keep only one method, ethtool, since the other was ugly (logs of pr_xxx). But by working on this issue, I saw

[PATCH RFC] net: stmmac: unify registers dumps methods

The stmmac driver have two methods for registers dumps: via ethtool and at init (if NETIF_MSG_HW is enabled). It is better to keep only one method, ethtool, since the other was ugly. This patch convert all dump_regs() function from "printing regs" to "fill the reg_space used by ethtool".

[PATCH RFC] net: stmmac: unify registers dumps methods

hello The following patch address the problem that two way of dumping registers are available in stmmac, via ethtool and directly at init (if NETIF_MSG_HW is enabled). It is better to keep only one method, ethtool, since the other was ugly (logs of pr_xxx). But by working on this issue, I saw

[PATCH 3/4] perf: Add a flag for partial AUX records

Intel PT driver needs to be able to communicate partial AUX transactions, that is, transactions with gaps in data for reasons other than no room left in the buffer (i.e. truncated transactions). Therefore, this condition does not imply a wakeup for the consumer. To this end, add a new "partial"

[PATCH 3/4] perf: Add a flag for partial AUX records

Intel PT driver needs to be able to communicate partial AUX transactions, that is, transactions with gaps in data for reasons other than no room left in the buffer (i.e. truncated transactions). Therefore, this condition does not imply a wakeup for the consumer. To this end, add a new "partial"

[PATCH 2/4] perf: Keep AUX flags in the output handle

From: Will Deacon In preparation for adding more flags to perf AUX records, introduce a separate API for setting the flags for a session, rather than appending more bool arguments to perf_aux_output_end. This allows to set each flag at the time a corresponding condition is

[PATCH 2/4] perf: Keep AUX flags in the output handle

From: Will Deacon In preparation for adding more flags to perf AUX records, introduce a separate API for setting the flags for a session, rather than appending more bool arguments to perf_aux_output_end. This allows to set each flag at the time a corresponding condition is detected, instead of

Re: [PATCH 06/11] tty: serial: Add Actions Semi Owl UART earlycon

Am 16.02.2017 um 14:41 schrieb Arnd Bergmann: > On Wednesday, February 15, 2017 5:55:23 PM CET Andreas Färber wrote: >> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig >> index 6117ac8..9d4213c 100644 >> --- a/drivers/tty/serial/Kconfig >> +++ b/drivers/tty/serial/Kconfig >>

Re: [PATCH 06/11] tty: serial: Add Actions Semi Owl UART earlycon

Am 16.02.2017 um 14:41 schrieb Arnd Bergmann: > On Wednesday, February 15, 2017 5:55:23 PM CET Andreas Färber wrote: >> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig >> index 6117ac8..9d4213c 100644 >> --- a/drivers/tty/serial/Kconfig >> +++ b/drivers/tty/serial/Kconfig >>

[PATCH 1/4] perf: Export AUX buffer helpers to modules

From: Will Deacon Perf PMU drivers using AUX buffers cannot be built as modules unless the AUX helpers are exported. This patch exports perf_aux_output_{begin,end,skip} and perf_get_aux to modules. Cc: Peter Zijlstra Signed-off-by: Will Deacon

[PATCH 1/4] perf: Export AUX buffer helpers to modules

From: Will Deacon Perf PMU drivers using AUX buffers cannot be built as modules unless the AUX helpers are exported. This patch exports perf_aux_output_{begin,end,skip} and perf_get_aux to modules. Cc: Peter Zijlstra Signed-off-by: Will Deacon Signed-off-by: Alexander Shishkin ---

Re: [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t

On Mon, Feb 20, 2017 at 02:24:24PM +0100, Heiko Carstens wrote: > On Mon, Feb 20, 2017 at 01:06:18PM +0200, Elena Reshetova wrote: > > @@ -361,7 +361,7 @@ debug_info_create(const char *name, int pages_per_area, > > int nr_areas, > > debug_area_last = rc; > > rc->next = NULL; >

Re: [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t

On Mon, Feb 20, 2017 at 02:24:24PM +0100, Heiko Carstens wrote: > On Mon, Feb 20, 2017 at 01:06:18PM +0200, Elena Reshetova wrote: > > @@ -361,7 +361,7 @@ debug_info_create(const char *name, int pages_per_area, > > int nr_areas, > > debug_area_last = rc; > > rc->next = NULL; >

Re: [PATCH] ipmi: bt-bmc: Use a regmap for register access

On 02/19/2017 10:45 PM, Andrew Jeffery wrote: Hi Cory, On Tue, 2016-12-06 at 16:02 +0100, Cédric Le Goater wrote: [ this is a resend bc of some mailing list issues] On 12/06/2016 03:57 AM, Andrew Jeffery wrote: The registers for the bt-bmc device live under the Aspeed LPC controller.

RE: [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t

> On Mon, Feb 20, 2017 at 01:06:18PM +0200, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > >

Re: [PATCH] ipmi: bt-bmc: Use a regmap for register access

On 02/19/2017 10:45 PM, Andrew Jeffery wrote: Hi Cory, On Tue, 2016-12-06 at 16:02 +0100, Cédric Le Goater wrote: [ this is a resend bc of some mailing list issues] On 12/06/2016 03:57 AM, Andrew Jeffery wrote: The registers for the bt-bmc device live under the Aspeed LPC controller.

RE: [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t

> On Mon, Feb 20, 2017 at 01:06:18PM +0200, Elena Reshetova wrote: > > refcount_t type and corresponding API should be > > used instead of atomic_t when the variable is used as > > a reference counter. This allows to avoid accidental > > refcounter overflows that might lead to use-after-free > >

[PATCH 0/4] perf, pt, coresight: AUX flags and VMX update

Hi Peter, With the vmm_exclusive=0, PT seems to be much more usable on BDW now. This patchset does three things: * adds a flag to PERF_RECORD_AUX, signalling that a transaction has gaps in it (due to VMX root mode kicking in), * changes the AUX API slightly to allow for flags to be set at

Re: [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t

On Mon, Feb 20, 2017 at 02:24:24PM +0100, Heiko Carstens wrote: > > @@ -361,7 +361,7 @@ debug_info_create(const char *name, int pages_per_area, > > int nr_areas, > > debug_area_last = rc; > > rc->next = NULL; > > > > - debug_info_get(rc); > > + refcount_set(>ref_count, 1);

[PATCH 0/4] perf, pt, coresight: AUX flags and VMX update

Hi Peter, With the vmm_exclusive=0, PT seems to be much more usable on BDW now. This patchset does three things: * adds a flag to PERF_RECORD_AUX, signalling that a transaction has gaps in it (due to VMX root mode kicking in), * changes the AUX API slightly to allow for flags to be set at

Re: [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t

On Mon, Feb 20, 2017 at 02:24:24PM +0100, Heiko Carstens wrote: > > @@ -361,7 +361,7 @@ debug_info_create(const char *name, int pages_per_area, > > int nr_areas, > > debug_area_last = rc; > > rc->next = NULL; > > > > - debug_info_get(rc); > > + refcount_set(>ref_count, 1);

net: possible deadlock in skb_queue_tail

Hi, I've got the following error report while fuzzing the kernel with syzkaller. On commit c470abd4fde40ea6a0846a2beab642a578c0b8cd (4.10). Unfortunately I can't reproduce it. == [ INFO: possible circular locking dependency detected ]

net: possible deadlock in skb_queue_tail

Hi, I've got the following error report while fuzzing the kernel with syzkaller. On commit c470abd4fde40ea6a0846a2beab642a578c0b8cd (4.10). Unfortunately I can't reproduce it. == [ INFO: possible circular locking dependency detected ]

Re: [PATCH v2] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

On 02/20/2017 at 07:09 PM, Borislav Petkov wrote: > On Mon, Feb 20, 2017 at 02:10:37PM +0800, Xunlei Pang wrote: >> @@ -1128,8 +1129,9 @@ void do_machine_check(struct pt_regs *regs, long >> error_code) >> */ >> int lmce = 1; >> >> -/* If this CPU is offline, just bail out. */ >>

Re: [PATCH v2] x86/mce: Don't participate in rendezvous process once nmi_shootdown_cpus() was made

On 02/20/2017 at 07:09 PM, Borislav Petkov wrote: > On Mon, Feb 20, 2017 at 02:10:37PM +0800, Xunlei Pang wrote: >> @@ -1128,8 +1129,9 @@ void do_machine_check(struct pt_regs *regs, long >> error_code) >> */ >> int lmce = 1; >> >> -/* If this CPU is offline, just bail out. */ >>

Re: [PATCH v2 2/2] iio: stm32 trigger: Implement parent trigger feature

2017-02-19 16:53 GMT+01:00 Jonathan Cameron : > Hi All, > > Would be really helpful to get some other input on this. > It's fiddly to put it lightly but if we get it right I think > the interface will be useful in all sorts of common cases. > > On 16/02/17 14:23, Benjamin

Re: [PATCH v2 2/2] iio: stm32 trigger: Implement parent trigger feature

2017-02-19 16:53 GMT+01:00 Jonathan Cameron : > Hi All, > > Would be really helpful to get some other input on this. > It's fiddly to put it lightly but if we get it right I think > the interface will be useful in all sorts of common cases. > > On 16/02/17 14:23, Benjamin Gaignard wrote: >> Add

Re: [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t

On Mon, Feb 20, 2017 at 01:06:18PM +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. >

Re: [PATCH 1/4] s390: convert debug_info.ref_count from atomic_t to refcount_t

On Mon, Feb 20, 2017 at 01:06:18PM +0200, Elena Reshetova wrote: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. >

Re: [PATCH v10 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

On Mon, Feb 20, 2017 at 9:09 AM, Hoegeun Kwon wrote: > From: Hyungwon Hwang > > This patch add the panel device tree node for S6E3HA2 display > controller to TM2 dts. > > Signed-off-by: Hyungwon Hwang > Signed-off-by:

Re: [PATCH v10 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

On Mon, Feb 20, 2017 at 9:09 AM, Hoegeun Kwon wrote: > From: Hyungwon Hwang > > This patch add the panel device tree node for S6E3HA2 display > controller to TM2 dts. > > Signed-off-by: Hyungwon Hwang > Signed-off-by: Andrzej Hajda > Signed-off-by: Chanwoo Choi > Signed-off-by: Hoegeun Kwon

[PATCH] clk: core: Copy connection id

Some drivers use sprintf to build clk connection id names but the clk core will save those strings and occasionally print them back. Duplicate the con_id strings instead of fixing all the users. Signed-off-by: Leonard Crestez --- drivers/clk/clk.c | 3 ++- 1 file

[PATCH] clk: core: Copy connection id

Some drivers use sprintf to build clk connection id names but the clk core will save those strings and occasionally print them back. Duplicate the con_id strings instead of fixing all the users. Signed-off-by: Leonard Crestez --- drivers/clk/clk.c | 3 ++- 1 file changed, 2 insertions(+), 1

Re: [PATCH 5/5] mm: convert mm_struct.mm_count from atomic_t to refcount_t

Hi Elena, [auto build test ERROR on mmotm/master] [also build test ERROR on next-20170220] [cannot apply to linus/master linux/master v4.10] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Elena

Re: [PATCH 5/5] mm: convert mm_struct.mm_count from atomic_t to refcount_t

Hi Elena, [auto build test ERROR on mmotm/master] [also build test ERROR on next-20170220] [cannot apply to linus/master linux/master v4.10] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Elena

Re: [RFC] perf/sdt: Directly record SDT event with 'perf record'

Thanks Ingo, On Monday 20 February 2017 02:12 PM, Ingo Molnar wrote: > * Ravi Bangoria wrote: > >> What should be the behavior of the tool? Should it record only one >> 'sdt_libpthread:mutex_entry' which exists in uprobe_events? Or it >> should record all the

Re: [RFC] perf/sdt: Directly record SDT event with 'perf record'

Thanks Ingo, On Monday 20 February 2017 02:12 PM, Ingo Molnar wrote: > * Ravi Bangoria wrote: > >> What should be the behavior of the tool? Should it record only one >> 'sdt_libpthread:mutex_entry' which exists in uprobe_events? Or it >> should record all the SDT events from libpthread? We can

Re: [PATCH 0/4] ARM64: Initial Marvell IAP140 enablement

Hi Andreas, On dim., févr. 19 2017, Andreas Färber wrote: > Hello, > > This mini-series adds initial support for the Marvell IAP140 SoC (aka PXA1908) > and the Andromeda Box Edge development board. Given the name of the SoC (PXA1908) and the fact that you reuse driver

Re: [PATCH 0/4] ARM64: Initial Marvell IAP140 enablement

Hi Andreas, On dim., févr. 19 2017, Andreas Färber wrote: > Hello, > > This mini-series adds initial support for the Marvell IAP140 SoC (aka PXA1908) > and the Andromeda Box Edge development board. Given the name of the SoC (PXA1908) and the fact that you reuse driver related to PXA, for me

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