* Tim Chen wrote:
> > + If unsure say Y here.
> >
> > If/when other architectures make use of this the Kconfig entry can be moved
> > into
> > the scheduler Kconfig - but for the time being it can stay in arch/x86/.
> >
> > Another variant would be to eliminate the Kconfig option altogethe
On Tue, 29 Nov 2016 07:21:14 +0800
kbuild test robot wrote:
> Hi Jacob,
>
> [auto build test ERROR on soc-thermal/next]
> [also build test ERROR on v4.9-rc7 next-20161128]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
&
Commit-ID: 8e8d8725d46d93ceffd3e708d905bc101a1905b5
Gitweb: http://git.kernel.org/tip/8e8d8725d46d93ceffd3e708d905bc101a1905b5
Author: Josh Poimboeuf
AuthorDate: Mon, 28 Nov 2016 17:06:35 -0600
Committer: Ingo Molnar
CommitDate: Tue, 29 Nov 2016 08:10:05 +0100
tools/decode_stacktrace.s
On 11/28/2016, 10:04 PM, Arnd Bergmann wrote:
> Testing with a gcc-7 snapshot produced an internal compiler error
> for this file:
>
> drivers/tty/nozomi.c: In function 'receive_flow_control':
> drivers/tty/nozomi.c:919:12: internal compiler error: in
> get_substring_ranges_for_loc, at input.c:13
* John Stultz wrote:
> From: Chen Yu
>
> Previously we encountered some memory overflow issues due to
> the bogus sleep time brought by inconsistent rtc, which is
> triggered when pm_trace is enabled, and we have fixed it
> in recent kernel. However it's improper in the first place
> to call _
* John Stultz wrote:
> From: Baolin Wang
>
> For system debugging, we sometimes want to know who sets one
> alarm timer, the time of the timer, when the timer started and
> fired and so on. Thus adding tracepoints can help us trace the
> alarmtimer information.
s/one alarm timer/an alarm time
On Mon 28-11-16 12:19:07, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 23, 2016 at 09:50:12AM +0100, Vlastimil Babka wrote:
> > > You'd certainly _hope_ that atomic allocations either have fallbacks
> > > or are harmless if they fail, but I'd still rather see that
> > > __GFP_NOWARN just to make that
* John Stultz wrote:
> + boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the
> + fast monotonic clock, but also accounts for time spent in
> + suspend. Since the clock access is designed for use in
> + tracing in the suspend path, some side
Hi!
We're apparently misunderstanding each other, I meant only that last
#ifdef in the v2 review... Sorry for not being clearer, new attempt
below.
Cheers,
Peter
On 2016-11-29 04:46, tnhu...@apm.com wrote:
> From: Tin Huynh
>
> This patch enables ACPI support for mux-pca954x driver.
>
> Signe
On 2016-11-29 08:04, Tin Huynh wrote:
> This patch enables ACPI support for mux-pca954x driver.
>
> Signed-off-by: Tin Huynh
>
> Change from v1 :
> -Don't shadow id variable.
> -Include sorted header.
> -Redefine acpi_device_id.
> -Add CONFIG_ACPI.
> ---
> drivers/i2c/muxes/i2c-mux-pca954x.
On Tue, Nov 29, 2016 at 10:15:40AM +0530, Binoy Jayan wrote:
>
> Thank you for the reply. The dm-crypt changes are also included as
> part of this patchset. It has been tested for functionality as well.
> More information can be found in the cover letter including the test
> procedure etc.
>
> htt
Hi Peter,
On 11/25/2016 10:49 PM, Peter Zijlstra wrote:
> On Fri, Nov 25, 2016 at 09:54:05PM +0100, Michael Kerrisk (man-pages) wrote:
>> So, part of what I was struggling with was what you meant by cfs-cgroup.
>> Do you mean the CFS bandwidth control features added in Linux 3.2?
>
> Nope, /me di
At least one SoC vendor (Qualcomm) requires additional processing done
during ARM SMCCC calls. As such, an additional parameter to the
arm_smccc_smc is required to be able to handle SoC specific quirks.
The Qualcomm quirk is necessary due to the fact that the scm call can
be interrupted on Qualco
This patch adds a quirk parameter to the arm_smccc_smc call. The quirk
structure allows for specialized SMC operations due to SoC specific
requirements.
This patch also fixes up all the current users of the arm_smccc_smc API.
This patch and partial implementation was suggested by Will Deacon.
S
Erreichen Sie die Speichergrenze für Ihr Postfach.
Bitte besuchen Sie den folgenden link, um die Wiederherstellung Ihrer
E-Mail-Zugriff.
http://www.emailcleanup001.tk/
System-Helpdesk
This patch adds a Qualcomm specific quirk to the arm_smccc_smc call.
On Qualcomm ARM64 platforms, the SMC call can return before it has
completed. If this occurs, the call can be restarted, but it requires
using the returned session ID value from the interrupted SMC call.
The quirk stores off th
Hi Herbert,
On 29 November 2016 at 12:58, Herbert Xu wrote:
> But that begs the question, who is supposed to use crypto_geniv_set_ctx?
> I thought it was dm-crypt but your patch doesn't contain any uses
> of it at all.
No one is using it as of now. It was just a thought to pass context
informati
On 29 November 2016 at 03:53, Ziji Hu wrote:
> Hi Ulf,
>
> On 2016/11/28 23:16, Ulf Hansson wrote:
>> On 28 November 2016 at 12:38, Ziji Hu wrote:
>>> Hi Ulf,
>>>
>>> On 2016/11/28 19:13, Ulf Hansson wrote:
>
> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(),
On Mon, Nov 28, 2016 at 11:43:09PM +0100, Martin Kaiser wrote:
> The current definitions of DMACR_HM() and DMACR_TM() are correct only
> for imx1, they're wrong for imx21.
>
> The macros are meant for legacy board files only, they're not applicable
> for boards using device tree.
>
> At the momen
On 29/11/16 01:24, Dmitry Vyukov wrote:
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") printk() requires KERN_CONT to continue log
messages. Lots of printk() in lockdep.c and print_ip_sym() don't
have it. As the result lockdep reports are completely mess
On Tue, Nov 29, 2016 at 01:16:46PM +0530, Binoy Jayan wrote:
>
> No one is using it as of now. It was just a thought to pass context
> information, instead of making it part of the context which is shared
> among dm-crypt and geniv.
OK in that case we should just get rid of it until it's actually
On Mon, Nov 28, 2016 at 03:21:54PM +0100, Michal Hocko wrote:
> On Tue 08-11-16 08:31:49, Naoya Horiguchi wrote:
> > Introduces CONFIG_ARCH_ENABLE_THP_MIGRATION to limit thp migration
> > functionality to x86_64, which should be safer at the first step.
>
> Please make sure to describe why this ha
On Mon, 2016-11-28 at 12:11 -0800, Guenter Roeck wrote:
> On Mon, Nov 28, 2016 at 04:23:23PM +0200, Heikki Krogerus wrote:
> > On Mon, Nov 28, 2016 at 11:19:32AM +0100, Oliver Neukum wrote:
> The Type-C specification states (in 4.5.2.2.11):
>
> "Note: if both Try.SRC and Try.SNK mechanisms are im
901 - 923 of 923 matches
Mail list logo
