On Tue, May 06, 2014 at 10:07:38PM +0200, Richard Cochran wrote:
> On Tue, May 06, 2014 at 12:50:49PM -0700, Andi Kleen wrote:
> >
> > > So I think Dave is right
> > > in rejecting anything that compromises the _quality_ of the stack.
> >
> > I don't think anything I removed compromised quality (
On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote:
> From: Cong Wang
> Date: Tue, 6 May 2014 11:33:11 -0700
>
> > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x?
> > 2.4.x kernel doesn't have so many new features you want to get rid of here.
>
> +1
You've got
Oups sorry msmtp messed up the from mail address. Do you want me to
re-submit this or you can fix it while applying the patch ?
--
Remi Pommarel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi,
On 06/05/2014 at 19:06:56 +, Bryan Evenson wrote :
>
> I'd assume this patch would be backported to the longterm releases?
>
If by longterm, you mean the linux4sam tree, 3.10 branch, it is up to
Nicolas to take it. I believe it will be pretty easy to convince him ;)
--
Alexandre Bello
Hi!
> Most likely yes but I wanted to keep sha1_ssse3_mod_init consistent
> with sha256_ssse3_mod_init/sha512_ssse3_mod_init functions.
> > > Reported-by:
> > > Signed-off-by: Milos Vyletel
> > > ---
> > > arch/x86/crypto/sha1_ssse3_glue.c | 22 --
> > > 1 file changed, 12
From: j...@joshtriplett.org
Date: Tue, 6 May 2014 14:08:15 -0700
> On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote:
>> From: Cong Wang
>> Date: Tue, 6 May 2014 11:33:11 -0700
>>
>> > So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x?
>> > 2.4.x kernel doesn't h
3.8.13.23 -stable review patch. If anyone has any objections, please let me
know.
--
From: Daniel Borkmann
commit b22f5126a24b3b2f15448c3f2a254fc10cbc2b92 upstream.
Some occurences in the netfilter tree use skb_header_pointer() in
the following way ...
struct dccp_hdr _dh,
This is the start of the review cycle for the Linux 3.8.13.23 stable kernel.
This version contains 4 new patches, summarized below. The new patches are
posted as replies to this message and also available in this git branch:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=linux-3.8.y-review;a=
3.8.13.23 -stable review patch. If anyone has any objections, please let me
know.
--
From: Matthew Daley
commit 2145e15e0557a01b9195d1c7199a1b92cb9be81f upstream.
Do not leak kernel-only floppy_raw_cmd structure members to userspace.
This includes the linked-list pointer and
3.8.13.23 -stable review patch. If anyone has any objections, please let me
know.
--
From: Matthew Daley
commit ef87dbe7614341c2e7bfe8d32fcb7028cc97442c upstream.
Always clear out these floppy_raw_cmd struct members after copying the
entire structure from userspace so that th
3.8.13.23 -stable review patch. If anyone has any objections, please let me
know.
--
From: Peter Hurley
commit 4291086b1f081b869c6d79e5b7441633dc3ace00 upstream.
The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are L
On 14/05/05, Nicolas Dichtel wrote:
> Le 02/05/2014 16:28, Richard Guy Briggs a ?crit :
> >On 14/05/02, Serge E. Hallyn wrote:
> >>Quoting Richard Guy Briggs (r...@redhat.com):
> >>>I saw no replies to my questions when I replied a year after Aris'
> >>>posting, so
> >>>I don't know if it was igno
- Original Message -
> From: "Steven Rostedt"
> To: "Mathieu Desnoyers"
> Cc: "LKML" , "Andrew Morton"
> , "Javi Merino"
> , "David Howells" , "Ingo Molnar"
>
> Sent: Tuesday, May 6, 2014 5:06:40 PM
> Subject: Re: [RFA][PATCH] tracing: Add trace__enabled() function
>
> On Tue, 6 May 2
bytes_transferred will overflow during long audio playbacks. Since
the driver only ever consults this value modulo bytes_requested, store the
value modulo bytes_requested.
Signed-off-by: Christopher Freeman
---
drivers/dma/tegra20-apb-dma.c | 20
1 file changed, 12 insert
Get word-level granularity from hardware for calculating
the transfer count remaining.
Signed-off-by: Christopher Freeman
---
drivers/dma/tegra20-apb-dma.c | 52 +
1 file changed, 52 insertions(+)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma
Log levels from info -> debug for a couple of interrupt
related prints. Interrupts may be handled outside of the ISR
when tx_status is called because they need to be handled before
calculating the residual.
Signed-off-by: Christopher Freeman
---
drivers/dma/tegra20-apb-dma.c |4 ++--
1 file
A collection of patches to improve Tegra's DMA residual reporting
Christopher Freeman (3):
dma: tegra: finer granularity residual for tx_status
dma: tegra: change interrupt-related log levels
dma: tegra: avoid int overflow for transferred count
drivers/dma/tegra20-apb-dma.c | 74
On 05/07/2014 02:04 AM, Andrew Morton wrote:
> On Tue, 06 May 2014 23:32:51 +0530 "Srivatsa S. Bhat"
> wrote:
>
>> Today the smp-call-function code just prints a warning if we get an IPI on
>> an offline CPU. This info is sufficient to let us know that something went
>> wrong, but often it is ve
On Tue, May 6, 2014 at 2:00 PM, Linus Torvalds
wrote:
>
> I'll do profiles and test the kernel compile too, but the raw timings
> are certainly promising. The "sysret" hack is pretty disgusting, and
> it's broken too. sysret doesn't do some things iret does (like TF flag
> etc), so it's not comple
w1_process_callbacks() expects to be called with dev->list_mutex held,
but it is the fact only in w1_process(). __w1_remove_master_device()
calls w1_process_callbacks() after it releases list_mutex.
The patch fixes __w1_remove_master_device() to acquire list_mutex
for w1_process_callbacks().
Foun
If the kernel is built to support multi-ARM configuration with shmobile
support built in, then drivers/sh is not built. This contains the PM
runtime code in drivers/sh/pm_runtime.c, which implicitly enables the
module clocks for all devices, and thus is quite essential.
Without this, the state of c
On Wed, 7 May 2014, Cyrill Gorcunov wrote:
> > [ 67.872274] BUG: unable to handle kernel NULL pointer dereference at
> > 0004
> > [ 67.876146] IP: [] p4_pmu_schedule_events+0xa5/0x331
>
> This looks like
>
> p4_pmu_schedule_events:
> ...
> bind = p4_config_ge
On Sun, 2014-05-04 at 13:50 +0200, Paul Bolle wrote:
> Ever since v2.6.19 the code contains a check for CONFIG_NO_ATA_LEGACY.
> But that macro has never been defined. Apparently no one ran into
> problems on platforms that do not support compatibility mode.
It was needed for some of the FRV device
On Tue, May 06, 2014 at 11:10:11PM +0200, Remi Pommarel wrote:
> Oups sorry msmtp messed up the from mail address. Do you want me to
> re-submit this or you can fix it while applying the patch ?
>
Best to fix it yourself and Greg can take which ever version is easiest.
https://www.google.com/sea
On 05/07/2014 02:12 AM, Tejun Heo wrote:
> On Tue, May 06, 2014 at 01:40:54PM -0700, Andrew Morton wrote:
>> On Tue, 06 May 2014 23:33:03 +0530 "Srivatsa S. Bhat"
>> wrote:
>>
>>> --- a/kernel/stop_machine.c
>>> +++ b/kernel/stop_machine.c
>>> @@ -165,12 +165,21 @@ static void ack_state(struct mu
>From d39d3460f1ab36365a48b6815dd9a5d26613d3ec Mon Sep 17 00:00:00 2001
From: poma
Date: Tue, 6 May 2014 22:03:38 +0200
Subject: [PATCH] WAPF 4 for ASUSTeK COMPUTER INC. X75VBP WLAN ON.
The 'asus-nb-wmi' WAPF parameter must be set to 4, so the internal Wireless LAN device is operational.
Signe
On Tue, May 6, 2014 at 2:25 PM, Linus Torvalds
wrote:
> On Tue, May 6, 2014 at 2:00 PM, Linus Torvalds
> wrote:
>>
>> I'll do profiles and test the kernel compile too, but the raw timings
>> are certainly promising. The "sysret" hack is pretty disgusting, and
>> it's broken too. sysret doesn't do
On Wed, May 07, 2014 at 12:27:21AM +0300, Dan Carpenter wrote:
> Best to fix it yourself and Greg can take which ever version is easiest.
Ok thank you so I'll re-submitted it.
Regards
--
Remi Pommarel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
One misfeature in the timekeeping seqlock code I noticed is that
read_seqcount_begin returns "unsigned int", not "unsigned long".
Casting to a larger type is harmless, but inefficient.
> This is due to printk() triggering console sem wakeup, which can
> cause scheduling code to trigger hrtimers w
This patch fixes all prohibited spaces after open '(' checkpatch.pl errors
for rtl8188eu.
Signed-off-by: Remi Pommarel
---
drivers/staging/rtl8188eu/include/odm_debug.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/include/odm_debug.h
b/dri
On Tue, May 6, 2014 at 2:25 PM, Linus Torvalds
wrote:
>
> Whatever. I got enough profile data to say that it seems to have cut
> 'iret' overhead by at least two thirds. So it may not *work*, but from
> a "hey look, some random numbers" standpoint it is worth playing with.
Just to clarify: that's
The PHY on board is the SMSC LAN8720
With the generic PHY driver selected: http://pastebin.com/A4MH4Ptw
[ 28.828761] fec 800f.ethernet eth0: Freescale FEC PHY driver
[Generic PHY] (mii_bus:phy_addr=800f.etherne:00, irq=-1)
[ 28.840626] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not rea
On 14/05/05, James Bottomley wrote:
> On May 5, 2014 3:36:38 PM PDT, Serge Hallyn wrote:
> >Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> >> On Mon, 2014-05-05 at 22:27 +, Serge Hallyn wrote:
> >> > Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> >> > >
Thanks, if there are no objections I'll apply that.
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please r
On 01.05.2014 07:48, David Fries wrote:
> On Thu, May 01, 2014 at 12:37:58AM +0400, Alexey Khoroshilov wrote:
>> w1_process_callbacks() expects to be called with dev->list_mutex held,
>> but it is the fact only in w1_process(). __w1_remove_master_device()
>> calls w1_process_callbacks() after it re
The Ceph bit is fine.
Acked-by: Greg Farnum
On Mon, Apr 28, 2014 at 10:50 AM, Jeff Layton wrote:
> Currently, the fl_owner isn't set for flock locks. Some filesystems use
> byte-range locks to simulate flock locks and there is a common idiom in
> those that does:
>
> fl->fl_owner = (fl_owne
Sricharan R wrote on Tue [2014-May-06 19:26:16 +0530]:
> Some socs have a large number of interrupts requests to service
> the needs of its many peripherals and subsystems. All of the interrupt
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the
On Tue, May 06, 2014 at 05:30:19PM -0400, Vince Weaver wrote:
> On Wed, 7 May 2014, Cyrill Gorcunov wrote:
>
> > > [ 67.872274] BUG: unable to handle kernel NULL pointer dereference at
> > > 0004
> > > [ 67.876146] IP: [] p4_pmu_schedule_events+0xa5/0x331
> >
> > This looks like
> >
> >
On Tue, May 6, 2014 at 4:39 PM, Steven Rostedt wrote:
> On Tue, 6 May 2014 16:12:54 -0400
> Dan Streetman wrote:
>
>> On Mon, May 5, 2014 at 10:18 PM, Steven Rostedt wrote:
>> > On Fri, 2 May 2014 15:02:29 -0400
>> > Dan Streetman wrote:
>> >
>> >> Add plist_rotate(), which moves the specified
On Tue, May 6, 2014 at 2:34 PM, Andy Lutomirski wrote:
>
> I don't think that's enough to fix this -- interrupts may not have
> been on in the first place, I think. I wonder if __put_user_inatomic
> would work here.
That might be the way to go, yes.
And in addition to the CS value you should pr
On 6 May 2014, at 19:15, Sasha Levin wrote:
> On 05/06/2014 01:05 PM, Catalin Marinas wrote:
>> On Tue, May 06, 2014 at 04:20:27PM +0100, Sasha Levin wrote:
>>> On 05/02/2014 09:41 AM, Catalin Marinas wrote:
Currently, kmemleak_early_log is disabled at the beginning of the
kmemleak_init(
On 14/05/05, James Bottomley wrote:
> On Tue, 2014-05-06 at 03:27 +, Serge Hallyn wrote:
> > Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> > > >> Right, but when the contaner has an audit namespace, that namespace
> > > >has
> > > >> a name,
> > > >
> > > >What ns has a nam
[...]
>> This will emit the WARN_ON a single time, but will emit the "IPI
>> Payload" list every time the cpu is found to be offline. So on the
>> second and successive occurrences some output will still occur.
>>
>> Unfortunately WARN_ON_ONCE() returns the value of `condition', not
>> `__warned',
[...]
>>> The code comments are a bit lame. Can we do a better job of explaining
>>> the overall dynamic behaviour? Help readers to understand the problem
>>> which hold_active_cpus() is solving and how it solves it?
>>
>> Does it even need to be a separate function? I kinda really dislike
>> tr
On Tue, 6 May 2014, Alessandro Zummo wrote:
> > This brings in drivers/char/rtc.c functionality required for DECstation
> > and, should the maintainers decide to switch, Alpha systems to use
> > rtc-cmos.
>
> Seems sane. We need to be sure it doesn't break anything
> on non-Alpha machines. Di
On Tue, 6 May 2014 14:12:34 +0100 Will Deacon wrote:
> > > > My opinion is that when you are printing from each and every interrupt
> > > > which happens so often, then you have a problem and disabling IRQs in
> > > > printk so that your interrupt doesn't happen that often seems like a
> > > > p
2014-05-06 14:40 GMT-07:00 Brian Lilly :
> The PHY on board is the SMSC LAN8720
>
> With the generic PHY driver selected: http://pastebin.com/A4MH4Ptw
>
> [ 28.828761] fec 800f.ethernet eth0: Freescale FEC PHY driver
> [Generic PHY] (mii_bus:phy_addr=800f.etherne:00, irq=-1)
> [ 28.840
On Tue, 2014-05-06 at 22:40 +0200, Michael Kerrisk (man-pages) wrote:
> Hi Davidlohr,
>
> On Tue, May 6, 2014 at 10:06 PM, Davidlohr Bueso wrote:
> > On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote:
> >> Hi Manfred,
> >>
> >> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul
>
Broadcom mobile SoCs use a ROM-implemented holding pen for
controlled boot of secondary cores. A special register is
used to communicate to the ROM that a secondary core should
start executing kernel code. This enable method is currently
used for members of the bcm281xx and bcm21664 SoC families.
Define nodes representing the two Cortex A9 CPUs in a bcm21644 SoC.
Signed-off-by: Alex Elder
---
arch/arm/boot/dts/bcm21664.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
index 08a44d4..a37ded1 1006
Also explicitly set CONFIG_NR_CPUS to 2, limiting it to the most we
currently need.
Signed-off-by: Ray Jui
Signed-off-by: Alex Elder
---
arch/arm/configs/bcm_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 3df3f
Define nodes representing the two Cortex A9 CPUs in a bcm28155 SoC.
Signed-off-by: Ray Jui
Signed-off-by: Alex Elder
---
arch/arm/boot/dts/bcm11351.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
ind
This series adds SMP support for two Broadcom mobile SoC families.
It uses CPU_METHOD_OF_DECLARE() so that SMP operations are assigned
using device tree rather than adding it to a machine definition in a
board file.
The enable method starts a secondary core by writing to a register
monitored by CP
This patch adds SMP support for BCM281XX and BCM21664 family SoCs.
This feature is controlled with a distinct config option such that a
SMP-enabled multi-v7 binary can be configured to run these SoCs in
uniprocessor mode. Since this SMP functionality is used for
multiple Broadcom mobile chip fami
On Tue, May 06, 2014 at 10:23:50PM +0200, Peter Zijlstra wrote:
> On Thu, May 01, 2014 at 09:44:34AM +0100, Mel Gorman wrote:
> > If cpusets are not in use then we still check a global variable on every
> > page allocation. Use jump labels to avoid the overhead.
> >
> > Signed-off-by: Mel Gorman
On Tue, May 06, 2014 at 10:34:49PM +0200, Peter Zijlstra wrote:
> On Thu, May 01, 2014 at 09:44:39AM +0100, Mel Gorman wrote:
> > +void set_pfnblock_flags_group(struct page *page, unsigned long flags,
> > + unsigned long end_bitidx,
> > +
It would appear that I don't have that commit. I could move to 3.14
to see if it makes a difference, but the last couple of responses have
been on 3.12.18 -- or perhaps I'm missing something else.
Please let me know if you have any questions.
Thank you.
Brian Lilly
Crystalfontz America, Incorpor
(2014/05/06 21:26), Steven Rostedt wrote:
> On Tue, 06 May 2014 20:45:50 +0900
> Masami Hiramatsu wrote:
>
>
>> However, I also think if users can accept such freezing wait-time,
>> it means they can also accept kexec based "checkpoint-restart" patching.
>> So, I think the final goal of the kpat
On Tue, May 06, 2014 at 07:21:14PM +0200, Fabian Frederick wrote:
> Those 2 arrays are being passed to lockdep_init_map with const char *
> and stored in lockdep_map the same way
>
> Cc: Dipankar Sarma
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Queued for 3.17, thank you Fabian!
On Tue, 6 May 2014 17:47:16 -0400
Dan Streetman wrote:
> well the specific reason in swap's case is the need to use
> same-priority entries in a round-robin basis, but I don't know if
> plist_round_robin() is very clear.
No, that's not very clear.
>
> Maybe plist_demote()? Although demote mi
Commit-ID: 4c88d7f9b0d5fb0588c3386be62115cc2eaa8f9f
Gitweb: http://git.kernel.org/tip/4c88d7f9b0d5fb0588c3386be62115cc2eaa8f9f
Author: Arnd Bergmann
AuthorDate: Wed, 23 Apr 2014 14:49:17 +0200
Committer: Thomas Gleixner
CommitDate: Wed, 7 May 2014 00:42:09 +0200
genirq: Provide irq_for
The DMA-API documentation sometimes refers to "physical addresses" when it
really means "bus addresses." Sometimes these are identical, but they may
be different if the bridge leading to the bus performs address translation.
Update the documentation to use "bus address" when appropriate.
Also, co
Remove the unnecessary "&" from the function pointers in exynos_iommu_ops.
Signed-off-by: Bjorn Helgaas
---
drivers/iommu/exynos-iommu.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 57324709
I thought this was going to be a simple doc clarification patch, but
it's suffered a bit of feature creep.
The main point is that the DMA API uses "dma_addr_t" as the type for
addresses to be programmed into devices for doing DMA, but the
documentation sometimes refers to these as "bus addresses"
Convert the "iova" arguments of iommu_map(), iommu_unmap(), etc., from
"unsigned long" to dma_addr_t.
bb5547acfcd8 ("iommu/fsl: Make iova dma_addr_t in the iommu_iova_to_phys
API") did this for iommu_iova_to_phys(), but didn't fix the rest of the
IOMMU API.
This changes the following generic func
dma_declare_coherent_memory() takes two addresses for a region of memory: a
"bus_addr" and a "device_addr". I think the intent is that "bus_addr" is
the physical address a *CPU* would use to access the region, and
"device_addr" is the bus address the *device* would use to address the
region.
Rena
On Tue, 6 May 2014 14:48:50 -0700
Linus Torvalds wrote:
> Yeah, it's disgusting. I think it is worth fixing to get better
> numbers (it *would* be very interesting to hear whether this plus the
> kernel 'retq' thing actually makes real device interrupt overhead
> lower), but I'd be very wary of
(2014/05/06 21:33), Steven Rostedt wrote:
> On Tue, 6 May 2014 07:12:11 -0500
> Josh Poimboeuf wrote:
>
>> Live patching is a very sensitive and risky operation, and from a kernel
>> standpoint we should make it as safe as we reasonably can. But we can't
>> do much about careless users. Ultimat
dma_declare_coherent_memory() needs both the CPU physical address and the
bus address of the device memory. They are likely the same on this
platform, but in general we should use pcibios_bus_to_resource() to account
for any address translation done by the PCI host bridge.
Signed-off-by: Bjorn He
On Tue, May 06, 2014 at 05:11:17PM -0400, David Miller wrote:
> From: j...@joshtriplett.org
> Date: Tue, 6 May 2014 14:08:15 -0700
>
> > On Tue, May 06, 2014 at 04:44:10PM -0400, David Miller wrote:
> >> From: Cong Wang
> >> Date: Tue, 6 May 2014 11:33:11 -0700
> >>
> >> > So why bothers 3.15+ L
On Tue, 6 May 2014 19:31:36 +0200 Oleg Nesterov wrote:
> On 05/06, Kirill Tkhai wrote:
> >
> > User may want to prohibit autoloading of some modules,
> > which happens when someone in kernel calls request_module().
> >
> > For comparison, udev considers blacklist even if corresponding
> > hardwar
Callers of mmc_regulator_get_supply could benefit from knowing if either
of the regulators are present but not yet available. Since callers do
not currently examine the return value, modify this function to return
zero or -EPROBE_DEFER if either regulator get returns the same.
Furthermore, since
On Tue, May 6, 2014 at 3:57 PM, Tim Kryger wrote:
> Callers of mmc_regulator_get_supply could benefit from knowing if either
> of the regulators are present but not yet available. Since callers do
> not currently examine the return value, modify this function to return
> zero or -EPROBE_DEFER if
On 05/06/2014 05:52 PM, Catalin Marinas wrote:
> On 6 May 2014, at 19:15, Sasha Levin wrote:
>> On 05/06/2014 01:05 PM, Catalin Marinas wrote:
>>> On Tue, May 06, 2014 at 04:20:27PM +0100, Sasha Levin wrote:
On 05/02/2014 09:41 AM, Catalin Marinas wrote:
> Currently, kmemleak_early_log is
Hi Linus,
radeon, i915 and nouveau fixes, all fixes for regressions or black
screens, or possible oopses,
I have an optional follow up to this for AMD as they have some new HW
support they'd like in, but I'm not sure how you are feeling at the
moment!
Dave.
The following changes since commi
This is support for the new AMD mullins APU, it pretty much just adds
support to the driver in the all the right places, and is pretty low risk
wrt other GPUs, however I'll leave it up to you if it fits with the
current release cycle,
Dave.
The following changes since commit 2a1235e53bed8fa11
On Tue, 2014-05-06 at 15:50 -0700, j...@joshtriplett.org wrote:
> There's something very wrong if 2.4.x works for
> cases that 3.x doesn't; that would be a serious regression.
You'll have to ask Linus to bring back i386 support then,
I believe it was removed in 3.8
--
To unsubscribe from this
On Tue, 2014-05-06 at 14:05 -0700, Andi Kleen wrote:
> - Make GRO optional.
> This is purely a performance feature for high bandwidth.
Make this properly then, instead of relying on LTO.
We did preliminary work to put this stuff in separate files, but its not
complete yet.
tcpv4_offload has poi
To implement the context tracker properly on arm64,
a function call needs to be made after debugging and
interrupts are turned on, but before the lr is changed
to point to ret_from_exception(). If the function call
is made after the lr is changed the function will not
return to the correct place.
Make calls to ct_user_enter when the kernel is exited
and ct_user_exit when the kernel is entered (in el0_da,
el0_ia, el0_svc, el0_irq).
These macros expand to function calls which will only work
properly if el0_sync and related code has been rearranged
(in a previous patch of this series).
In or
On Sat, May 3, 2014 at 4:15 PM, Christian Engelmayer wrote:
> Fix the error path when a cookie mismatch is detected. In that case the
> function jumps to the exit label without setting the uninitialized, local
> variable 'return_error'. Detected by Coverity - CID 201453.
>
> Signed-off-by: Christi
Implement and enable context tracking for arm64 (which is
a prerequisite for FULL_NOHZ support). This patchset
builds upon earlier work by Kevin Hilman and is based on 3.15-rc2.
Larry Bassel (2):
arm64: adjust el0_sync so that a function can be called
arm64: enable context tracking
arch/arm6
On Tue, 6 May 2014 07:04:46 -0400 Steven Rostedt wrote:
> On Tue, 6 May 2014 11:45:57 +0200
> Jan Kara wrote:
>
> > On Mon 05-05-14 19:18:46, Steven Rostedt wrote:
> > > To prevent deadlocks with doing a printk inside the scheduler,
> > > printk_sched() was created. The issue is that printk has
Steven Rostedt writes:
> On Tue, 6 May 2014 14:48:50 -0700
> Linus Torvalds wrote:
>
>> Yeah, it's disgusting. I think it is worth fixing to get better
>> numbers (it *would* be very interesting to hear whether this plus the
>> kernel 'retq' thing actually makes real device interrupt overhead
>>
On Fri, Apr 25, 2014 at 1:15 AM, Ulf Hansson wrote:
> On 25 April 2014 00:36, Tim Kryger wrote:
>> Switch the common SDHCI code over to use mmc_host's regulator pointers
>> and remove the ones in the sdhci_host structure. Additionally, use the
>> common mmc_regulator_get_supply function to get t
Hi
My holiday is finished.
I implemented another cpufreq driver. And that driver also have to use
exynos_sort_descend_freq_table().
Then exynos5440 and new cpufreq have a duplicate
function.(exynos_sort_descend_freq_table().
So I want to solve it.
Thanks.~
> -Original Message-
> Fro
On Tue, 6 May 2014 16:37:14 -0700
Andrew Morton wrote:
> What I have in -next is very different from this version of the patch.
> What's happening?
Hmm, good question.
Let me review this one. The one I sent recently was one I pulled from
my "sent" folder. I thought it was the latest one, but p
On 05/06/2014 04:39 PM, Peter Zijlstra wrote:
> On Tue, May 06, 2014 at 04:19:21PM -0400, Rik van Riel wrote:
>> On 05/06/2014 07:54 AM, Peter Zijlstra wrote:
>>> On Fri, May 02, 2014 at 11:19:47AM -0400, Rik van Riel wrote:
As an aside, it also looks like SD_BALANCE_WAKE is set on all domains
On Wed, May 07, 2014 at 01:42:12AM +0400, Alexey Khoroshilov wrote:
> On 01.05.2014 07:48, David Fries wrote:
> > On Thu, May 01, 2014 at 12:37:58AM +0400, Alexey Khoroshilov wrote:
> >> w1_process_callbacks() expects to be called with dev->list_mutex held,
> >> but it is the fact only in w1_proces
Acked-by: David Fries
On Wed, May 07, 2014 at 01:26:04AM +0400, Alexey Khoroshilov wrote:
> w1_process_callbacks() expects to be called with dev->list_mutex held,
> but it is the fact only in w1_process(). __w1_remove_master_device()
> calls w1_process_callbacks() after it releases list_mutex.
>
Hi everyone
07.05.2014, 03:49, "David Fries" :
> Acked-by: David Fries
>
> On Wed, May 07, 2014 at 01:26:04AM +0400, Alexey Khoroshilov wrote:
>
>> w1_process_callbacks() expects to be called with dev->list_mutex held,
>> but it is the fact only in w1_process(). __w1_remove_master_device()
>>
On Tue, 2014-05-06 at 17:41 -0400, Richard Guy Briggs wrote:
> On 14/05/05, James Bottomley wrote:
> > On May 5, 2014 3:36:38 PM PDT, Serge Hallyn wrote:
> > >Quoting James Bottomley (james.bottom...@hansenpartnership.com):
> > >> On Mon, 2014-05-05 at 22:27 +, Serge Hallyn wrote:
> > >> > Quo
bb bb
[ 2719.121933] Padding 88002dd9e7a8: 5a 5a 5a 5a 5a 5a 5a 5a
[ 2719.121933] CPU: 0 PID: 9797 Comm: runtrin.sh Tainted: GB W
3.15.0-rc4-next-20140506-sasha-00021-gc164334-dirty #447
[ 2719.121933] 88002dd9d668 880031b
On Tue, 6 May 2014 16:37:14 -0700
Andrew Morton wrote:
> What I have in -next is very different from this version of the patch.
> What's happening?
Hmm, it looks massaged from what I originally sent in order to be
placed after the other patches in the series. A quick review of the
patch seems
Create a module that allows udelay() to be executed to ensure that
it is delaying at least as long as requested.
Signed-off-by: David Riley
Reviewed-on: https://chromium-review.googlesource.com/194223
Reviewed-by: Doug Anderson
---
kernel/time/Kconfig |7 ++
kernel/time/Makefile
This change adds a module and a script that makes use of it to
validate that udelay delays for at least as long as requested
(as compared to ktime).
David Riley (2):
kernel: time: Add udelay_test module to validate udelay
tools: add script to test udelay
kernel/time/Kconfig |7 ++
This script makes use of the udelay_test module to exercise udelay()
and ensure that it is delaying long enough (as compared to ktime).
Signed-off-by: David Riley
---
tools/time/udelay_test.sh | 66 +
1 file changed, 66 insertions(+)
create mode 100
Hi Tomasz,
Thanks for review.
On 05/07/2014 03:36 AM, Tomasz Figa wrote:
Hi Pankaj,
On 06.05.2014 10:51, Pankaj Dubey wrote:
Let's move I2C interrupt re-configuration code from machine
file exynos.c to I2C driver. Since only Exynos5250, and
Exynos5420 need to do this, added syscon based phand
On Tuesday, May 06, 2014 03:31:02 PM Alan Stern wrote:
> On Tue, 6 May 2014, Rafael J. Wysocki wrote:
>
> > > > > You are using leave_runtime_suspended to mean two different things:
> > > > > remain runtime-suspended during the system suspend stages (i.e., no
> > > > > reprogramming is needed so
On 05/07/2014 04:04 AM, Tomasz Figa wrote:
Hi Pankaj,
On 06.05.2014 10:51, Pankaj Dubey wrote:
Let's move SYS_I2C_CFG register save/restore during s2r into i2c driver.
This will help in removing static iodesc based mapping from exynos.c.
Also will help in removing SoC specific checks in pm.c ma
601 - 700 of 829 matches
Mail list logo
