On Thu, Apr 10, 2014 at 12:44 AM, Takashi Iwai wrote:
> At Wed, 9 Apr 2014 14:06:13 -0700,
> Greg Kroah-Hartman wrote:
>>
>> On Wed, Apr 09, 2014 at 01:52:29PM -0700, Luis R. Rodriguez wrote:
>> > On Wed, Apr 9, 2014 at 1:22 PM, Greg Kroah-Hartman
>> > wrote:
>> > > On Wed, Apr 09, 2014 at
On Thu, Apr 10, 2014 at 06:51:12PM +0200, Linus Walleij wrote:
> On Thu, Apr 10, 2014 at 6:49 PM, Linus Walleij
> wrote:
> > On Thu, Apr 3, 2014 at 12:40 AM, Sherman Yin wrote:
> >
> >> To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
> >> driver and its related CONFIG
Richard Yao writes:
> Performance analysis of software compilation by Gentoo portage on an
> Intel E5-2620 with 64GB of RAM revealed that a sizeable amount of time,
> anywhere from 5% to 15%, was spent in get_vmalloc_info(), with at least
> 40% of that time spent in the _raw_spin_lock() invoked
Modules installed outside of the kernel's build system should go into
"%s/lib/modules/%s/extra", but at present, perf will only look at them
when they are in "%s/lib/modules/%s/kernel". Lets encourage good
citizenship by relaxing this requirement to "%s/lib/modules/%s". This
way open source
On Thu, Apr 10, 2014 at 6:49 PM, Linus Walleij wrote:
> On Thu, Apr 3, 2014 at 12:40 AM, Sherman Yin wrote:
>
>> To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
>> driver and its related CONFIG option are renamed to bcm281xx.
>>
>> Devicetree compatible string and
On Wed, 09 Apr 2014 14:02:04 -0700, Tony Luck said:
> Take a look at this thread: https://lkml.org/lkml/2013/10/30/83
>
> I think there were some bugs in the console-efi code a while
> back - perhaps you ran a kernel had the bug and made all these
> duplicate entries?
The cited patch pair isn't
On Thu, Apr 3, 2014 at 12:40 AM, Sherman Yin wrote:
> To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
> driver and its related CONFIG option are renamed to bcm281xx.
>
> Devicetree compatible string and binding documentation use
> "brcm,bcm11351-pinctrl" to match the
Performance analysis of software compilation by Gentoo portage on an
Intel E5-2620 with 64GB of RAM revealed that a sizeable amount of time,
anywhere from 5% to 15%, was spent in get_vmalloc_info(), with at least
40% of that time spent in the _raw_spin_lock() invoked by it.
The spinlock call is
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
> To improve latency with cyclic DMA operation it is preferred to
> use different eventq/tc than the default which is used by all
> other drivers (mmc, spi, i2c, etc).
> When preparing the cyclic dma ask for non default queue for the
> channel which is
Hi guys,
let me answer to all of you here:
On Thu, Apr 10, 2014 at 03:45:41PM +, Ertman, DavidX M wrote:
> Could you also provide some information about the configuration
> of the system when this happens?
AFAIR, this happens when I stick the network cable in. I'll pay
attention to the
On 08.04.2014 03:29, poma wrote:
> ...
> Command line: initrd=initrd.img
> inst.stage2=hd:LABEL=Fedora\x20rawhide\x20x86_64 xdriver=modesetting
> BOOT_IMAGE=vmlinuz
> Kernel command line: initrd=initrd.img
> inst.stage2=hd:LABEL=Fedora\x20rawhide\x20x86_64 xdriver=modesetting
>
On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote:
> > > > > >> > > > > dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr
> > > > > >> > > > > 7f61e000
> >
> > That "Present bit in context entry is clear" fault means that we have
> > not set up *any* mappings for this PCI device…
From: Nico Pitre
All known BE8-capable systems have LE bootloaders, so we need to ensure
that the magic number and image start/end values are in little endian
format.
[ben.do...@codethink.co.uk: from nico's original email on this subject]
Signed-off-by: Ben Dooks
[taras.kondrat...@linaro.org:
Hi,
On Thu, Apr 10, 2014 at 04:44:36PM +0300, Kirill A. Shutemov wrote:
> Okay, below is my attempt to fix the bug. I'm not entirely sure it's
> correct. Andrea, could you take a look?
The possibility the interval tree implicitly broke the walk order of
the anon_vma list didn't cross my mind,
On Tue, Apr 1, 2014 at 4:02 PM, Heikki Krogerus
wrote:
> There is no need to dynamically generate the names. This
> will fix a static checker warning..
>
> net/rfkill/rfkill-gpio.c:144 rfkill_gpio_probe()
> warn: variable dereferenced before check 'rfkill->name'
>
> Reported-by: Dan
On Tue, Apr 1, 2014 at 4:02 PM, Heikki Krogerus
wrote:
> After upgrading to descriptor based gpios, the gpio numbers
> are not used anymore. The power_clk_name and the platform
> specific setup and close hooks are not used by anybody, and
> we should not encourage use of such things, so removing
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
> Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
> priority channels, like audio.
>
> Signed-off-by: Peter Ujfalusi
This looks good, though another way to do it would be to leave default
to Queue 0. Put audio in Queue 1, and
On Tue, Apr 1, 2014 at 12:03 PM, Mika Westerberg
wrote:
> Dan Carpenter's static code checker reports:
>
> The patch 473ed7be0da0: "gpio / ACPI: Add support for ACPI GPIO
> operation regions" from Mar 14, 2014, leads to the following static
> checker warning:
>
>
On Tue, Apr 8, 2014 at 8:39 PM, Bjorn Andersson wrote:
> On Tue, Apr 8, 2014 at 7:18 AM, Timur Tabi wrote:
>> Back in July, Qualcomm submitted a patch that added this information into
>> the device tree:
>>
>> http://marc.info/?t=13718516613=1=2
>>
>> However, this was rejected. Now it
On Wed, Apr 09, 2014 at 09:49:57PM +0200, Peter Zijlstra wrote:
> Anyway, I'll look over the stuff tomorrow.
That patch was missing useful clues..
Also, I shot __for_each_thread in the head, it seemed useless.
---
include/linux/sched.h | 11 ++-
1 file changed, 6 insertions(+), 5
Hi Linus,
Support for the new keyboard features on the Thinkpad Carbon, a bunch of
updates for the Sony and Toshiba drivers, a new driver for upcoming
Alienware hardware and a few misc fixes. There's a couple of patches
that got Acked today but aren't invasive, so I'll send a further PR for
On Mon, Mar 31, 2014 at 11:49 PM, Bjorn Andersson
wrote:
> This adds pinctrl definitions for the GPIO pins of the TLMM v2 block in the
> Qualcomm APQ8064 platform.
>
> Signed-off-by: Bjorn Andersson
Patch applied for next.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line
Commit 198d208df4371734ac4728f69cb585c284d20a15 ("x86: Keep thread_info
on thread stack in x86_32") made 32-bit kernels use kernel_stack to point to
thread_info. That change missed a couple of updates needed by Xen's
32-bit PV guests:
1. kernel_stack needs to be initialized for secondary CPUs
2.
On Mon, Mar 31, 2014 at 11:49 PM, Bjorn Andersson
wrote:
> DT bindingdocumentation for qcom,apq8064-pinctrl driver.
>
> Signed-off-by: Bjorn Andersson
No news in this binding. Patch applied for next.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe
On Mon, Mar 31, 2014 at 11:49 PM, Bjorn Andersson
wrote:
> The various pins may have different number of functions defined, so make this
> number definable per pin instead of just increasing it to the largest one for
> all of the platforms.
>
> Signed-off-by: Bjorn Andersson
Patch applied for
Hello,
I added --percentage option to perf report to control display of
percentage of filtered entries.
usage: perf report []
--percentage
how to display percentage of filtered entries
"relative" means it's relative to filtered entries only so that the
sum
When filtering by thread, dso or symbol on TUI it also update total
period so that the output shows different result than no filter - the
percentage changed to relative to filtered entries only. Sometimes
this is not desired since users might expect same results with filter.
So new filtered_*
On Mon, Mar 31, 2014 at 11:49 PM, Bjorn Andersson
wrote:
> Acking interrupts are done differently between on v2 and v3, so add an extra
> attribute to the pingroup struct to let the platform definitions control this.
> Also make sure to start dual edge detection by detecting the rising edge.
>
>
On Mon, Mar 31, 2014 at 2:16 PM, Mika Westerberg
wrote:
> Commit aa92b6f689ac (gpio / ACPI: Allocate ACPI specific data directly in
> acpi_gpiochip_add()) moved ACPI handle checking to acpi_gpiochip_add() but
> forgot to check whether chip->dev is NULL before dereferencing it.
>
> Since
The --percentage option is for controlling overhead percentage
displayed. It can only receive either of "relative" or "absolute" and
affects -c delta output only.
For more information, please see previous commit same thing done to
"perf report".
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
The --percentage option is for controlling overhead percentage
displayed. It can only receive either of "relative" or "absolute".
"relative" means it's relative to filtered entries only so that the
sum of shown entries will be always 100%. "absolute" means it retains
the original value before
On Wed, Apr 9, 2014 at 6:26 AM, Sylwester Nawrocki
wrote:
> This patch adds a helper function to configure clock parents and
> rates as specified in clock-parents, clock-rates DT properties
> for a consumer device and a call to it before driver is bound to
> a device.
>
> Signed-off-by: Sylwester
Add hist.percentage option for setting default value of the
symbol_conf.filter_relative. It affects the output of various perf
commands (like perf report, top and diff) only if filter(s) applied.
An user can write .perfconfig file like below to show absolute
percentage of filtered entries by
The --percentage option is for controlling overhead percentage
displayed. It can only receive either of "relative" or "absolute".
Move the parser callback function into a common location since it's
used by multiple commands now.
For more information, please see previous commit same thing done to
Add 'F' hotkey to toggle relative and absolute percentage of filtered
entries.
Suggested-by: Jiri Olsa
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c |4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/ui/browsers/hists.c
[+cc Steve and iss_storagedev, remove "storagedev" which bounced
(apparent typo)]
On Thu, Apr 10, 2014 at 9:43 AM, Bjorn Helgaas wrote:
> On Tue, Apr 8, 2014 at 8:39 PM, Baoquan He wrote:
>> Hi,
>>
>> The kernel is 3.14.0+ which is pulled just now.
>>
>>
>> [ 18.402695] systemd[1]: Set
Now perf report will show absolute percentage on filter entries by
default.
Suggested-by: Jiri Olsa
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/util/symbol.c |1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index
Jiri noticed that netperf throughput had gotten worse in recent years,
for smaller message sizes. In the past, ksoftirqd would take around 80%
of a CPU, and netserver would take around 100% of another CPU.
On current kernels, sometimes all the softirq processing is done in the
context of the
On Thu, Apr 10, 2014 at 03:00:09PM +0200, Borislav Petkov wrote:
> Hi Greg,
>
> please take the patch into the stable 3.14.y queue. It fixes a number
> of EFI machines which makes a stable backport a good thing. Before you
> apply it though, cherry-pick 42a5477251f on which this patch depends.
>
On Thu, Apr 10, 2014 at 01:31:31AM -0700, Guenter Roeck wrote:
> On 04/09/2014 08:21 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.4.87 release.
> >There are 134 patches in this series, all will be posted as a response
> >to this one. If anyone has any
On Thu, Apr 10, 2014 at 07:59:38AM +, Narasimharao Bolisetti wrote:
>
> Hi,
>
> I have checked the same in the recent kernel versions also. Issue is still
> remain.
What versions have you tried, and what are the logs from those versions?
> ::DISCLAIMER::
>
Hi Linus,
A small collection of fixes that should go in before -rc1. The pull
request contains:
- A two patch fix for a regression with block enabled tagging caused by
a commit in the initial pull request. One patch is from Martin and
ensures that SCSI doesn't truncate 64-bit block flags,
Boris,
What kind of system (platform) is this happening on? It's a LOM correct? Can
you run 'lspci -vvv' and output the results?
Thanks.
Cheers,
John
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Thursday, April 10, 2014 5:00 AM
> To:
On Thu, 2014-04-10 at 16:34 +0800, Jiang Liu wrote:
> Hi Baoquan,
> Could you please help to give output of "lspci -"?
Attached.
> Is device "hpsa :03:00.0" a legacy PCI device(non-PCIe)?
> It may have relationship with IOMMU driver.
I honestly don't know. PCI is way out of my
> -Original Message-
> From: Fujinaka, Todd [mailto:todd.fujin...@intel.com]
> Sent: Thursday, April 10, 2014 7:59 AM
> To: Borislav Petkov; e1000-de...@lists.sourceforge.net
> Cc: net...@vger.kernel.org; lkml
> Subject: Re: [E1000-devel] e1000e :00:19.0 eth0: Hardware Error
>
> We
On Tue, Apr 8, 2014 at 8:39 PM, Baoquan He wrote:
> Hi,
>
> The kernel is 3.14.0+ which is pulled just now.
>
>
> [ 18.402695] systemd[1]: Set hostname to
> .
> [ 18.408456] random: systemd urandom read with 70 bits of entropy
> available
> [ 18md[1]: Expecting device
>
On 04/10/2014 01:04 AM, Alexandre Courbot wrote:
> Stephen, any news about this patch? I'm waiting for it to be merged in
> order to resend some Tegra DTs, but still cannot see it in -next.
To be honest, this became too painful to work on just to fix a warning
at boot which has no practical
On Thu, 10 Apr 2014 17:03:36 +0200
Sebastian Andrzej Siewior wrote:
> On 04/10/2014 04:44 PM, Clark Williams wrote:
> > The means of each group of five test runs are:
> >
> > vanilla.log: 1210117 rt.log: 17210953 (14.2 x slower than
> > vanilla) rt-fixes.log: 10062027 (8.3 x slower than
On Thu, 2014-04-10 at 09:14 -0600, Bjorn Helgaas wrote:
> > Thus, my first guess would be that we are quite happily setting up the
> > requested DMA maps on the *wrong* IOMMU, and then taking faults when the
> > device actually tries to do DMA.
> >
> I like the "wrong IOMMU (or no IOMMU at all)"
On 4/10/2014 11:14 AM, Bjorn Helgaas wrote:
> On Thu, Apr 10, 2014 at 2:46 AM, Woodhouse, David
> wrote:
>
>>> DMAR:[fault reason 02] Present bit in context entry is clear
>>> dmar: DRHD: handling fault status reg 602
>>> dmar: DMAR:[DMA Read] Request device [02:00.0]
On Thu, 10 Apr 2014, Vivek Gautam wrote:
> Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
> adds a check for possible race between suspend and wakeup interrupt,
> and thereby it returns -EBUSY as error code if there's a wakeup
> interrupt.
> So the platform host controller should
On Thu, 10 Apr 2014, Vivek Gautam wrote:
> Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
> adds a check for possible race between suspend and wakeup interrupt,
> and thereby it returns -EBUSY as error code if there's a wakeup
> interrupt.
> So the platform host controller should
The SAI mainly has the following clocks:
bus clock
control and configure registers and to generate synchronous
interrupts and DMA requests.
mclk1, mclk2, mclk3
to generate the bit clock when the receiver or transmitter is
configured for an internally generated bit clock.
So
Linus,
please pull sound fixes for v3.15-rc1 from:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
tags/sound-fix-3.15-rc1
The topmost commit is a5065eb6da55b226661456e6a7435f605df98111
sound fixes for 3.15-rc1
The SAI mainly has the following clocks:
bus clock
control and configure registers and to generate synchronous
interrupts and DMA requests.
mclk1, mclk2, mclk3
to generate the bit clock when the receiver or transmitter is
configured for an internally generated bit clock.
So
On Thu, Apr 10, 2014 at 2:46 AM, Woodhouse, David
wrote:
>> > > >> > > > > DMAR:[fault reason 02] Present bit in context entry is clear
>> > > >> > > > > dmar: DRHD: handling fault status reg 602
>> > > >> > > > > dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr
>> > > >> > > > >
On Thu, 10 Apr 2014 16:46:55 +0200
Oleg Nesterov wrote:
> > I mean, the tracepoint is
> > activated usually by humans, and if they enabled it just as a usermode
> > helper is activated, and those are really fast to run, do we even care
> > if it is missed?
>
> A user space task spawned by
This patch replaces the inconsistent copyright symbols in each source
file with (C).
Signed-off-by: Benjamin Romer
---
drivers/staging/unisys/channels/channel.c | 2 +-
drivers/staging/unisys/channels/chanstub.c | 2 +-
On 04/10/2014 04:44 PM, Clark Williams wrote:
> The means of each group of five test runs are:
>
> vanilla.log: 1210117 rt.log: 17210953 (14.2 x slower than
> vanilla) rt-fixes.log: 10062027 (8.3 x slower than vanilla)
> rt-multi.log: 3179582 (2.x x slower than vanilla)
>
>
> As expected,
On Thu, 10 Apr 2014 09:44:30 -0500
Clark Williams wrote:
> I wrote a program named whack_mmap_sem which creates a large (4GB)
> buffer, then creates 2 x ncpus threads that are affined across all the
> available cpus. These threads then randomly write into the buffer,
> which should cause page
On Wed, Apr 09, 2014 at 05:28:57PM +0530, Viresh Kumar wrote:
> Hi Guys,
>
> File: kernel/time/tick-sched.c
> function: tick_nohz_idle_exit()
>
> We are checking here if idle_active is true or not and then
> do some stuff. But is it possible that idle_active be false
> here?
>
> The sequence as
op 10-04-14 13:08, Thomas Hellstrom schreef:
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use this.
We also need to know what part you're using. "lspci | grep Ethernet" should
narrow that down.
Thanks.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565
-Original Message-
From: Borislav Petkov
On Thu, Apr 10, 2014 at 10:07:47PM +0800, Shawn Guo wrote:
> On Thu, Apr 10, 2014 at 07:23:12PM +0800, Nicolin Chen wrote:
> > The SAI mainly has the following clocks:
> > bus clock
> > control and configure registers and to generate synchronous
> > interrupts and DMA requests.
> >
> >
On Wed, 2014-04-09 at 12:25 -0700, Greg Kroah-Hartman wrote:
> Patches need to do only one thing, so can you please split this up in to
> multiple patches, each one only doing one thing.
Sorry about that! I'll send another patch that fixes all of the
copyright statements at once then. :)
> You
On Thu, Apr 10, 2014 at 03:07:44PM +0100, Arnd Bergmann wrote:
> On Thursday 10 April 2014 07:50:52 Bjorn Helgaas wrote:
> > On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann wrote:
> > > On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
> > >> On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau
On Thu, Mar 20, 2014 at 11:32 AM, ty...@mit.edu wrote:
Looking at your patches, and what files you are modifying, you are
enforcing this in the low-level file system.
I would love for this to be implemented in the filesystem level as
well. Something like the ext4 immutable bit, but with the
On 04/10, Steven Rostedt wrote:
>
> On Thu, 10 Apr 2014 15:38:55 +0200
> Oleg Nesterov wrote:
>
> > > > However, this means that a user-space task spawned by
> > > > call_usermodehelper() won't report the system calls if
> > > > kernel_execve() is called when sys_tracepoint_refcount != 0.
> > >
>
On Wed, 9 Apr 2014 15:19:22 -0400
Steven Rostedt wrote:
> This patch is built on top of the two other patches that I posted
> earlier, which should not be as controversial.
>
> If you have any benchmark on large machines I would be very happy if
> you could test this patch against the
On 04/10/2014 10:37 AM, Dave Jones wrote:
> On Thu, Apr 10, 2014 at 04:45:58PM +0800, Bob Liu wrote:
> > On Tue, Apr 8, 2014 at 10:37 PM, Sasha Levin
> wrote:
> > > Hi all,
> > >
> > > While fuzzing with trinity inside a KVM tools guest running the latest
> -next
> > > kernel, I've
Hi Stephen,
thanks for the comments.
On 04/09/2014 03:09 AM, Stephen Boyd wrote:
> On 04/03, Stanimir Varbanov wrote:
>> +static void qce_ahash_dma_done(void *data)
>> +{
>> +struct crypto_async_request *async_req = data;
>> +struct ahash_request *req = ahash_request_cast(async_req);
>>
Em Thu, 10 Apr 2014 12:46:53 +0100
One Thousand Gnomes escreveu:
> > For example, some devices provide standard USB Audio Class, handled by
> > snd-usb-audio for the audio stream, while the video stream is handled
> > via a separate driver, like some em28xx devices.
>
> Which is what mfd is
On Wed, Apr 09, 2014 at 04:19:44PM +0530, Viresh Kumar wrote:
> On 9 April 2014 16:03, Viresh Kumar wrote:
> > Hi Frederic,
> >
> > File: kernel/time/tick-sched.c
> > Function: tick_nohz_full_stop_tick()
> >
> > We are doing this:
> >
> > if (!tick_nohz_full_cpu(cpu) || is_idle_task(current))
> >
On Thu, Apr 10, 2014 at 04:45:58PM +0800, Bob Liu wrote:
> On Tue, Apr 8, 2014 at 10:37 PM, Sasha Levin wrote:
> > Hi all,
> >
> > While fuzzing with trinity inside a KVM tools guest running the latest
> > -next
> > kernel, I've stumbled on the following:
> >
>
> Wow! There are so many
On 04/10/2014 05:38 AM, Mauro Carvalho Chehab wrote:
Hi Alan,
Em Thu, 10 Apr 2014 12:04:35 +0100
One Thousand Gnomes escreveu:
- Construct string with (dev is struct em28xx *dev)
format: "tuner:%s-%s-%d"
with the following:
On Thu, 10 Apr 2014 16:28:43 +0200
Mike Galbraith wrote:
> On Thu, 2014-04-10 at 16:18 +0200, Mike Galbraith wrote:
> > On Wed, 2014-04-09 at 15:19 -0400, Steven Rostedt wrote:
> >
> > > If you have any benchmark on large machines I would be very happy if
> > > you could test this patch
On 04/10/2014 04:18 PM, Oleg Nesterov wrote:
> On 04/10, Denys Vlasenko wrote:
>>
>> There is this monstrosity, "16-bit override for branches" in 64-mode:
>>
>> 66 e8 nn nn callw
>>
>> Nobody sane uses it because it truncates instruction pointer.
>>
>> Or rather, *I think* it should
On Thu, 2014-04-10 at 16:18 +0200, Mike Galbraith wrote:
> On Wed, 2014-04-09 at 15:19 -0400, Steven Rostedt wrote:
>
> > If you have any benchmark on large machines I would be very happy if
> > you could test this patch against the unpatched version of -rt.
>
> Too bad I don't have (and know
On Thu, 10 Apr 2014 15:38:55 +0200
Oleg Nesterov wrote:
> On 04/10, Steven Rostedt wrote:
> >
> > On Wed, 9 Apr 2014 19:06:16 +0200
> > Oleg Nesterov wrote:
> >
> > > syscall_regfunc() ignores the kernel thread because "it has
> > > no effect", see cc3b13c1 "Don't trace kernel thread syscalls".
On 04/10, Masami Hiramatsu wrote:
>
> (2014/04/10 22:41), Denys Vlasenko wrote:
> > On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
> >> On 04/08, Jim Keniston wrote:
> >>>
> >>> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> 0xe8. Anything else?
> >>>
> >>> No, I think e8 is the only
On Wed, Apr 09, 2014 at 12:15:12PM +0200, Jan Kara wrote:
> > + /*
> > +* ext4 sometimes asks to zero past the end of a block. It
> > +* really just wants to zero to the end of the block.
> > +*/
> Then we should really fix ext4 I believe...
Since
On 10 April 2014 16:43, Chander Kashyap wrote:
> In menu_select function we check for correction factor every time.
> If it is zero we are initializing to unity. Hence move it to init function
> and initialise by unity, hence avoid repeated comparisons.
>
> Signed-off-by: Chander Kashyap
> ---
>
On Wed, Apr 09, 2014 at 12:04:35PM +0200, Jan Kara wrote:
> On Sun 23-03-14 15:08:43, Matthew Wilcox wrote:
> > The only remaining usage is userspace's 'xip' option.
> Looks good. You can add:
> Reviewed-by: Jan Kara
I've been thinking about this patch, and I'm not happy with it any more :-)
On Wed, Apr 09, 2014 at 11:59:18AM +0200, Jan Kara wrote:
> On Sun 23-03-14 15:08:41, Matthew Wilcox wrote:
> > The fewer Kconfig options we have the better. Use the generic
> > CONFIG_FS_DAX to enable XIP support in ext2 as well as in the core.
> >
> > Signed-off-by: Matthew Wilcox
> Looks
On Wed, Apr 09, 2014 at 11:52:54AM +0200, Jan Kara wrote:
> > - if ((sbi->s_mount_opt ^ old_mount_opt) & EXT2_MOUNT_XIP) {
> > + if ((sbi->s_mount_opt ^ old_opts.s_mount_opt) & EXT2_MOUNT_XIP) {
> > ext2_msg(sb, KERN_WARNING, "warning: refusing change of "
> >
On 04/10/2014 03:57 PM, Masami Hiramatsu wrote:
> (2014/04/10 22:41), Denys Vlasenko wrote:
>> On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
>>> On 04/08, Jim Keniston wrote:
On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
> 0xe8. Anything else?
No, I think e8 is the
Hello,
On Thu, Apr 10, 2014 at 09:04:24AM -0500, Serge Hallyn wrote:
> Except for the keeping state. If the userspace agent crashes when it
> was meant to drop 100 cgroups when they become empty, then when it
> restarts those 100 cgroups may never be freed. Of course userspace
> can do things
On 04/10, Denys Vlasenko wrote:
>
> There is this monstrosity, "16-bit override for branches" in 64-mode:
>
> 66 e8 nn nn callw
>
> Nobody sane uses it because it truncates instruction pointer.
>
> Or rather, *I think* it should truncate it (i.e. zero-extend to full width),
> but
On Wed, 2014-04-09 at 15:19 -0400, Steven Rostedt wrote:
> If you have any benchmark on large machines I would be very happy if
> you could test this patch against the unpatched version of -rt.
Too bad I don't have (and know how to use) specjbb.
I dug up old vmark, thinking I'd be able to get
On Wed, Apr 09, 2014 at 11:46:44AM +0200, Jan Kara wrote:
> Another day, some more review ;) Comments below.
I'm really grateful for all this review! It's killing me, though ;-)
> > +int dax_clear_blocks(struct inode *inode, sector_t block, long size)
> > +{
> > + struct block_device *bdev
On Thu, Apr 10, 2014 at 6:51 PM, Jingoo Han wrote:
> On Thursday, April 10, 2014 1:17 PM, Alexandre Courbot wrote:
>>
>> Ping, can I have the Samsung folks review and ,aybe even merge this
>> patch? enable_gpio_flags is never used in any code, is replaced by
>> gpiod, and we would like to remove
On Thursday 10 April 2014 07:50:52 Bjorn Helgaas wrote:
> On Thu, Apr 10, 2014 at 2:00 AM, Arnd Bergmann wrote:
> > On Wednesday 09 April 2014 21:48:14 Bjorn Helgaas wrote:
> >> On Wed, Apr 9, 2014 at 7:27 PM, Liviu Dudau wrote:
> >> > On Wed, Apr 09, 2014 at 08:02:41AM -0600, Bjorn Helgaas
On Thu, Apr 10, 2014 at 07:23:12PM +0800, Nicolin Chen wrote:
> The SAI mainly has the following clocks:
> bus clock
> control and configure registers and to generate synchronous
> interrupts and DMA requests.
>
> mclk1, mclk2, mclk3
> to generate the bit clock when the receiver
Quoting Tejun Heo (t...@kernel.org):
> Hey, Serge.
>
> On Thu, Apr 10, 2014 at 05:08:55AM +0200, Serge E. Hallyn wrote:
> > Quoting Tejun Heo (t...@kernel.org):
> > > * It delivers events by forking and execing a userland binary
> > > specified as the release_agent. This is a long deprecated
(2014/04/10 1:55), Oleg Nesterov wrote:
> On 04/09, Masami Hiramatsu wrote:
>>
>> Reviewed-by: Masami Hiramatsu
>
> Thanks!
>
> Does this mean that I can add the same into 6-8 you didn't ack
> explicitely ?
Ah, yes! You can add my reviewed-by to other patches in the series.
Thank you,
--
Define PL and PM pin macros.
Signed-off-by: Boris BREZILLON
Acked-by: Maxime Ripard
---
drivers/pinctrl/pinctrl-sunxi.h | 68 +
1 file changed, 68 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-sunxi.h b/drivers/pinctrl/pinctrl-sunxi.h
index
(2014/04/10 22:41), Denys Vlasenko wrote:
> On 04/09/2014 05:43 PM, Oleg Nesterov wrote:
>> On 04/08, Jim Keniston wrote:
>>>
>>> On Sun, 2014-04-06 at 22:16 +0200, Oleg Nesterov wrote:
0xe8. Anything else?
>>>
>>> No, I think e8 is the only call instruction uprobes will see.
>>
>> Good.
>
>
Hello,
This series rework the sunxi pinctrl driver to support the PL and PM
pins available on the A31 SoC, which are controlled using the R_PIO
block.
This series add support for multi pin controller which was previously
impossible for several reasons:
1) the pinctrl instance was registering a
The A31 SoC define a reset line for the R_PIO block which needs to be
deasserted.
Try to retrieve a reset control and deassert if one was found.
Signed-off-by: Boris BREZILLON
---
drivers/pinctrl/pinctrl-sunxi.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff
Add support for multiple pin controller instances.
First remove the static definition of the sunxi gpio chip struct and fill
the dynamically struct instead.
Then define a new pin_base field in the sunxi_pinctrl_desc which will be
used to specify the gpiochip base pin.
Signed-off-by: Boris
301 - 400 of 1406 matches
Mail list logo
