Hi Dave,
On Wed, Jan 15, 2014 at 11:18:27AM +1100, Dave Chinner wrote:
> On Thu, Jan 09, 2014 at 10:57:15AM +0800, Fengguang Wu wrote:
> > Hi Dave,
> >
> > As you suggested, I added tests for ext4 and btrfs, the results are
> > the same.
> >
> > Then I tried running perf record for 10 seconds st
Hi Nicolas,
On 01/27/2014 11:38 AM, Nicolas Pitre wrote:
> The core idle loop now takes care of it. However a few things need
> checking:
>
> - Invocation of cpuidle_idle_call() in pseries_lpar_idle() happened
> through arch_cpu_idle() and was therefore always preceded by a call
> to ppc64_r
On Mon, Jan 27, 2014 at 12:20:15PM +0100, Juri Lelli wrote:
> From: Dario Faggioli
>
> Add in Documentation/scheduler/ some hints about the design
> choices, the usage and the future possible developments of the
> sched_dl scheduling class and of the SCHED_DEADLINE policy.
>
> Cc: bruce.ashfi...
This should make the driver usable with VIA/WonderMedia ARM-based
Systems-on-Chip integrated Rhine III adapters. Note that these
are always in MMIO mode, and don't have any known EEPROM.
Signed-off-by: Alexey Charkov
Signed-off-by: Roger Luethi
---
.../devicetree/bindings/net/via-rhine.txt
Use more generic data structures instead of struct pci_dev wherever
possible in preparation for OF bus binding
Signed-off-by: Alexey Charkov
Signed-off-by: Roger Luethi
---
drivers/net/ethernet/via/via-rhine.c | 116 +++
1 file changed, 62 insertions(+), 54 delet
Remove legacy PCI DMA wrappers and instead use generic DMA functions
directly in preparation for OF bus binding
Signed-off-by: Alexey Charkov
Signed-off-by: Roger Luethi
---
drivers/net/ethernet/via/via-rhine.c | 56 +++-
1 file changed, 29 insertions(+), 27 dele
This series introduces platform bus (OpenFirmware) binding for
via-rhine, as used in various ARM-based Systems-on-Chip by
VIA/WonderMedia.
This has been tested in OF configuration by myself on a WM8950-based VIA
APC Rock development board, and in PCI configuration by Roger.
Unfortunately, I ca
Jan Engelhardt writes:
> On Monday 2013-09-16 05:47, Rusty Russell wrote:
>>
>>Here's what I've got in my pending-rebases tree.
>>
>>@@ -842,6 +818,11 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
>>name_user,
>> return -EFAULT;
>> name[MODULE_NAME_LEN-1] = '\0';
>>
>>
Jiri Slaby writes:
> When dumping loaded modules, we print them one by one in separate
> printks. Let's use pr_cont as they are continuation prints.
Applied.
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
On Mon, Jan 27, 2014 at 11:27:59AM +0100, Peter Zijlstra wrote:
> Obviously I don't particularly like the SAVE_REST/FIXUP_TOP_OF_STACK
> being added to the reschedule path.
>
> Can't we do as Al suggested earlier and have 2 slowpath calls, one
> without PT_REGS and one with?
>
> That said, yes i
Hi Richard,
Thank you for the patch.
On Monday 27 January 2014 09:40:58 Richard Weinberger wrote:
> Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with
> COMPILE_TEST) broke build on archs wihout io memory.
>
> On archs like S390 or um this driver cannot build nor work.
> Make
On Fri, Jan 17, 2014 at 12:25:11PM +, Hanjun Guo wrote:
> ACPI GTDT (Generic Timer Description Table) contains information for
> arch timer initialization, this patch use this table to probe arm timer.
>
> GTDT table is used for ARM/ARM64 only, please refer to chapter 5.2.24
> of ACPI 5.0 spec
On 01/27/2014 12:20 PM, Juri Lelli wrote:
> From: Dario Faggioli
>
> Add in Documentation/scheduler/ some hints about the design
> choices, the usage and the future possible developments of the
> sched_dl scheduling class and of the SCHED_DEADLINE policy.
>
> Cc: bruce.ashfi...@windriver.com
> C
From: Dario Faggioli
Add in Documentation/scheduler/ some hints about the design
choices, the usage and the future possible developments of the
sched_dl scheduling class and of the SCHED_DEADLINE policy.
Cc: bruce.ashfi...@windriver.com
Cc: clau...@evidence.eu.com
Cc: dar...@dvhart.com
Cc: dhava
At Sat, 25 Jan 2014 19:05:03 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.4.78 release.
> There are 12 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
Hi Vinod,
On Sun, Jan 26, 2014 at 7:29 PM, Vinod Koul wrote:
> On Fri, Jan 24, 2014 at 02:24:27PM +0100, Lars-Peter Clausen wrote:
>> On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
>> > Hi Lars,
>> >
>> > On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen
>> > wrote:
>> >> On 01/22/2014 05:52
Hi Linus!
Please pull for CRIS Linux 3.14 updates.
Mostly removal of deprecated or old code, but also
a long promised update of the CRIS syscalls.
Thanks!
The following changes since commit ceb3b0212dfc843a6abe8a6f3b4e28c1f2059e64:
Merge branch 'drm-nouveau-next' of
git://anongit.freedesktop
On Sat, Jan 25, 2014 at 07:12:35PM -0800, David Rientjes wrote:
> As a result of commit 5606e3877ad8 ("mm: numa: Migrate on reference
> policy"), /proc//numa_maps prints the mempolicy for any as
> "prefer:N" for the local node, N, of the process reading the file.
>
> This should only be printed
On Fri, Jan 24, 2014 at 10:55:56PM +0200, Tommi Rantala wrote:
> Hello,
>
> Trinity triggered the following bug in two separate qemu virtual
> machines after fuzzing v3.13-3995-g0dc3fd0 for a day or two. I have
> not been running Trinity in a while, so no idea if this is a
> regression or not.
>
On Sat, Jan 25, 2014 at 07:12:35PM -0800, David Rientjes wrote:
> As a result of commit 5606e3877ad8 ("mm: numa: Migrate on reference
> policy"), /proc//numa_maps prints the mempolicy for any as
> "prefer:N" for the local node, N, of the process reading the file.
>
> This should only be printed
Hi, Maintainers
In our scene, we will create the 6in4/6to4 tunnel firstly and need to
check the tunnel type, secondly, we will configure the ip address on it.
So, Could we have any way to get the actual tunnel for 6in4 and 6to4
from current linux version?
Both 6in4 and 6to4 have the same pro
On 01/27/2014 06:30 PM, Ben Hutchings wrote:
> On Mon, 2014-01-27 at 18:28 +0800, Jason Wang wrote:
>> On 01/27/2014 06:22 PM, Ben Hutchings wrote:
>>> On Mon, 2014-01-27 at 17:40 +0800, Jason Wang wrote:
On 01/27/2014 04:35 PM, David Miller wrote:
> From: Jason Wang
> Date: Mon, 27 J
On Sun, Jan 26, 2014 at 08:16:37PM -0800, Guenter Roeck wrote:
> On 01/26/2014 03:51 PM, Mark Brown wrote:
> >On Sun, Jan 26, 2014 at 02:04:06PM -0800, Guenter Roeck wrote:
> >>I think I have a better idea: Surround the regulator code, or at least
> >>its error handling, in the lm90 driver with
>
On Mon, Jan 27, 2014 at 05:15:39PM -0500, Dongsheng Yang wrote:
> +/**
> + * task_prio - return the priority value of a given task.
> + * @p: the task in question.
> + *
> + * Return: The priority value as seen by users in /proc.
> + * RT tasks are offset by -200. Normal tasks are centered
> + * ar
On Mon, 2014-01-27 at 18:28 +0800, Jason Wang wrote:
> On 01/27/2014 06:22 PM, Ben Hutchings wrote:
> > On Mon, 2014-01-27 at 17:40 +0800, Jason Wang wrote:
> >> On 01/27/2014 04:35 PM, David Miller wrote:
> >>> From: Jason Wang
> >>> Date: Mon, 27 Jan 2014 15:30:54 +0800
> >>>
> Call netif_c
On 27.01.2014 10:54, Dmitry Torokhov wrote:
> Hi Alexey,
>
> On Mon, Jan 27, 2014 at 10:31:36AM +0400, Alexey Khoroshilov wrote:
>> On 21.01.2014 23:59, Dmitry Torokhov wrote:
>>> On Sun, Jan 19, 2014 at 03:24:26AM +0400, Alexey Khoroshilov wrote:
There is usb_get_dev() in gtco_probe(), but th
On 01/27/2014 06:22 PM, Ben Hutchings wrote:
> On Mon, 2014-01-27 at 17:40 +0800, Jason Wang wrote:
>> On 01/27/2014 04:35 PM, David Miller wrote:
>>> From: Jason Wang
>>> Date: Mon, 27 Jan 2014 15:30:54 +0800
>>>
Call netif_carrier_on() after register_device(). Otherwise it won't work
On Sun, Jan 26, 2014 at 02:28:15PM -0800, Linus Torvalds wrote:
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index 1e96c3628bf2..15b5953da958 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -658,30 +658,24 @@ sysret_check:
> /* Han
Hi Arnaldo,
Could you wait for pulling this series?
I've found that this series has an obvious bug on
kaslr enabled kernel. I'll fix that by using
the relative address from _stext for kprobes.
Thank you,
(2014/01/23 11:29), Masami Hiramatsu wrote:
> Hi,
>
> Here is a series of patches for handl
Hi,
On 01/25/2014 05:35 PM, Belisko Marek wrote:
> Hello,
>
> booting linux-next (not actual but older from 20.12 gives me following
> warning).
> I'm booting gta04 device via devicetree with added sound node (copied
> from beagleboard)
Not sure what goes wrong on your board. I just tested toda
From: Sonic Zhang
Signed-off-by: Sonic Zhang
---
drivers/pinctrl/pinctrl-adi2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-adi2.c b/drivers/pinctrl/pinctrl-adi2.c
index 9fb53c9..72450a1 100644
--- a/drivers/pinctrl/pinctrl-adi2.c
+++ b/drivers/pi
On Mon, 2014-01-27 at 17:40 +0800, Jason Wang wrote:
> On 01/27/2014 04:35 PM, David Miller wrote:
> > From: Jason Wang
> > Date: Mon, 27 Jan 2014 15:30:54 +0800
> >
> >> Call netif_carrier_on() after register_device(). Otherwise it won't work
> >> since
> >> the device was still in NETREG_UNINIT
From: Sonic Zhang
It is better to keep this structure in the pinctrl-adi2 driver.
Signed-off-by: Sonic Zhang
---
arch/blackfin/include/asm/irq.h | 9 -
drivers/pinctrl/pinctrl-adi2.c | 15 ++-
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/arch/blackfin/
On Tue, Jan 21, 2014 at 12:44:21PM +, Jonas Jensen wrote:
> MOXA ART SoCs allow to determine PLL output and APB frequencies
> by reading registers holding multiplier and divisor information.
>
> Add a clock driver for this SoC.
>
> Signed-off-by: Jonas Jensen
> ---
>
> Notes:
> Thanks f
From: Sonic Zhang
Negative irq_base means this gpio port doens't support interrupts.
Signed-off-by: Sonic Zhang
---
drivers/pinctrl/pinctrl-adi2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-adi2.c b/drivers/pinctrl/pinctrl-adi2.c
index e8120fa..
On Mon, 2014-01-27 at 07:59 +0400, Max Filippov wrote:
> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
> not disable advertisement when PHY supports them. This results in
> non-functioning network when the MAC is connected to a gigabit PHY connected
> to a gigabit switc
On Sun, 2014-01-26 at 16:47 +0530, Vinod Koul wrote:
> > > > > For these cases, I have been using suspend_late. Since the dmaengine
> > > > > driver is
> > > > > providing service to other clients (SPI), it needs to esnure that it
> > > > > suspends
> > > > > after SPI using suspend_late and res
I've at least identified two possible memory leaks in blkback, both
related to the shutdown path of a VBD:
- We don't wait for any pending purge work to finish before cleaning
the list of free_pages. The purge work will call put_free_pages and
thus we might end up with pages being added to the
On Fri 24-01-14 14:42:22, Steven Whitehouse wrote:
>
> So far I've had one ACK for this, and no other comments. So I think it
> is probably time to send this via some suitable tree. I'm guessing that
> the vfs tree would be the most appropriate route, but not sure that
> there is one at the moment
On Sat, Jan 25, 2014 at 01:09:23AM -0800, Bin Gao wrote:
> > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c index
> > a3acbac2ee72$
> > --- a/arch/x86/kernel/tsc.c
> > +++ b/arch/x86/kernel/tsc.c
> > @@ -655,10 +655,11 @@ unsigned long native_calibrate_tsc(void)
> > local_irq_sav
On Mon, Jan 27, 2014 at 12:15 AM, Mark Brown wrote:
>> No, you don't get what I'm saying. For PC users, the lm90 did not
>
> I understand perfectly well thank you very much.
>
>> request a regulator and things worked because the kernel isn't supposed
>> to take care about things like that on PC ma
swapoff clear swap_info's SWP_USED flag prematurely and free its resources
after that. A concurrent swapon will reuse this swap_info while its previous
resources are not cleared completely.
These late freed resources are:
- p->percpu_cluster
- swap_cgroup_ctrl[type]
- block_device setting
- in
When swapon the same S_ISBLK blockdev concurrent, the allocated two
swap_info could hold the same block_device, because claim_swapfile()
allow the same holder(here, it is sys_swapon function).
To prevent this situation, This patch adds swap_lock protect to ensure
we can find this situation and ret
> Either everything is dynamic, or everything follows proper minor
> assignment process.
Ultimately everything should probably be dynamic, but trying to get there
in one step will simply mean we never get there at all.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
On Sat, 2014-01-25 at 13:07 -0800, Matt Wilson wrote:
> On Fri, Jan 24, 2014 at 03:36:22PM +, Ian Campbell wrote:
> > On Fri, 2014-01-24 at 09:21 +, Ian Campbell wrote:
> > > On Thu, 2014-01-23 at 11:28 -0800, Matt Wilson wrote:
> > > > From: Matt Rushton
> > > >
> > > > Currently shrink_
A potential asynchronous frontswap_register_ops could happen while swapoff
or swapon is happening, there is a need to protect init frontswap type and
prevent NULL point reference to si->frontswap_map.
This patch utilize swapon_mutex to prevent this scenario, see comments of
frontswap_register_ops
The frontswap_shrink works as a "partial swapoff" by using try_to_unuse(),
but is has race condition with swapoff.
Of course we can fix this race issue, however, as this code is not used by
anyone and not efficient, I decide drop this code.
As to shrinker, a frontswap backend should implement its
Consider of performance and simplicity, this patch remove swap_lock
to simplify the si_swapinfo().
Because the system info we obtain through /proc or /sys interface is
just a snapshot, we don't need a very precise freeswap and totalswap count.
Some monitor tool will get these count at per-second p
Since commit 01dcc60a7cb8, platform_device_register_full() is
available to allocate and register a platform device.
If a dma_mask is provided as part of platform_device_info,
platform_device_register_full() allocate memory for a u64 using
kmalloc().
A comment in the code state that "[t]his memory
If S_ISREG swapfile's blocksize > PAGE_SIZE, it is not suitable to be
a swapfile, because swap slot is fixed to PAGE_SIZE.
This patch check this situation and return -EINVAL if it happens.
Signed-off-by: Weijie Yang
---
mm/page_io.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/pa
If a frontswap dup-store failed, it should invalidate the old page in
backend and return failure.
This patch add this missing handle. According to the comments of
__frontswap_store(), it should have been there.
Reported-by: changkun.li
Signed-off-by: Weijie Yang
---
mm/frontswap.c |4 +++-
The swap flag/lock usage in swapfile.c is lack of clarity
and readability, some comments are not correct in other files.
Add some comments to try to make it more clear and readable.
Signed-off-by: Weijie Yang
---
include/linux/blkdev.h |4 ++-
mm/rmap.c |2 +-
mm/swapfile.c
On Mon, Jan 27, 2014 at 8:01 AM, Barry Song <21cn...@gmail.com> wrote:
> i read the patch "gpio: add API to be strict about GPIO IRQ usage"
> again, it seems by checking if (test_bit(FLAG_USED_AS_IRQ,
> &desc->flags)), we do be able to stop users setting irqline to output.
Yes that is the specifi
This patch series focus on some tiny and rare issues in swap subsystem.
These issues happen rarely, so it is just for the correctness of the code.
It firstly add some comments to try to make swap flag/lock usage in
swapfile.c more clear and readable,
and fix some rare issues in swap subsystem that
> >> If CONFIG_PM_SLEEP=n:
> >>
> >> drivers/mfd/max14577.c:177: warning: ‘max14577_suspend’ defined but not
> >> used
> >> drivers/mfd/max14577.c:200: warning: ‘max14577_resume’ defined but not used
> >>
> >> Signed-off-by: Geert Uytterhoeven
> >> ---
> >> drivers/mfd/max14577.c |2 ++
> >>
When dumping loaded modules, we print them one by one in separate
printks. Let's use pr_cont as they are continuation prints.
Signed-off-by: Jiri Slaby
Cc: Rusty Russell
---
kernel/module.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/module.c b/kernel/module
When dumping flags with which the kernel was built, we print them one
by one in separate printks. Let's use pr_cont as they are
continuation prints.
Signed-off-by: Jiri Slaby
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
---
arch/x86/kernel/dumpstack.c | 8 -
On Fri, Jan 24, 2014 at 9:28 AM, Lee Jones wrote:
>> > +/*
>> > + * As edge triggers are not supported at hardware level, it is supported
>> > by
>> > + * software by exploiting the level trigger support in hardware.
>>
>> (...)
>>
>> All this is quite hard to understand. Maybe it's just because
27.01.2014 12:44, Sebastian Andrzej Siewior пишет:
> On 01/26/2014 10:25 PM, Pavel Vasilyev wrote:
>> 25.01.2014 17:45, Sebastian Andrzej Siewior пишет:
>>> Dear RT folks!
>>
>>
>> Gentlemen, let's have a month of stress testing! Divide tasks
>> testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO B
On 01/27/2014 04:35 PM, David Miller wrote:
> From: Jason Wang
> Date: Mon, 27 Jan 2014 15:30:54 +0800
>
>> Call netif_carrier_on() after register_device(). Otherwise it won't work
>> since
>> the device was still in NETREG_UNINITIALIZED state.
>>
>> Fixes a68f9614614749727286f675d15f1e09d13cb54a
Enable the isochrounous IN handling for AM335x HOST.
Reprogram CPPI to receive consecutive ISOCH frames in the same URB.
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_host.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/
Enable CPPI to handle high bandwidth transfers, especially to support
webcam captures. Use a single bd to get the whole of the data in case of
high bandwidth transfers.
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_cppi41.c | 13 +
1 file changed, 13 insertions(+)
diff --g
This series enables the ISOCH IN handling for AM335x HOST mode.
With this series webcam devices are now supported under AM335x
MUSB HOST with CPPI DMA enabled.
Patch 1 - Enable basic ISOCH IN handling
Patch 2 - Make CPPI aware of hb transfers
Patch 3 - Using hrtimer based polling for tx empty lea
In case of ISOCH transfers the hrtimer workaround for the hardware issue
is not very reliable. Instead of checking musb_is_tx_fifo_empty() in hrtimer
routine, schedule a completion work and check the same in completion work.
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_cppi41.c | 53 +
The supported audio parameters are described in the EDID which is
received by the HDMI transmitter from the connected screen.
Use these ones to adjust the audio stream parameters.
Signed-off-by: Jean-Francois Moine
---
drivers/gpu/drm/i2c/tda998x_drv.c | 15
include/drm/i2c/tda998x.h
When both I2S and S/PDIF are wired from the audio device to the
TDA998x, the user or some internal mechanism may choose to do audio
streaming via either inputs.
This patch adds an exported function in the TDA998x driver which
initializes the audio input parameters according to the audio
subsystem.
Add devicetree documentation about the NXP TDA998x CODEC.
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/sound/tda998x.txt | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tda998x.txt
diff --git a/Documen
This patch adds a CODEC driver for the NXP TDA998x HDMI transmitter.
The CODEC handles both I2S and S/PDIF input and does dynamic input
switch in the TDA998x I2C driver on audio streaming start/stop.
Signed-off-by: Jean-Francois Moine
---
sound/soc/codecs/Kconfig | 7 ++
sound/soc/codecs/Ma
The TDA998x HDMI transmitter accepts audio input from either I2S or S/PDIF.
Theses inputs have different intrinsic constraints and these constraints
may be modified by the audio parameters of the connected video device.
The choice of I2S or S/PDIF may be the done by the user or by automatic
proce
On Sunday, January 26, 2014 11:54 AM Jose Alonso wrote:
> I observed that there are for_each macros that do an extra memory access
> beyond the defined area.
> Normally this does not cause problems.
> But, this can cause exceptions. For example: if the area is allocated at
> the end of a page and
On 1/24/2014 11:16 PM, Sergei Shtylyov wrote:
Hello.
On 24-01-2014 18:14, George Cherian wrote:
In case of ISOCH transfers the hrtimer workaround for the hardware issue
is not very reliable. Instead of checking musb_is_tx_fifo_empty() in
hrtimer
routine, schedule a completion work and check t
On 1/24/2014 11:13 PM, Sergei Shtylyov wrote:
Hello.
On 24-01-2014 18:14, George Cherian wrote:
Enable the isochrounous IN handling for AM335x HOST.
Reprogram CPPI to receive consecutive ISOCH frames in the same URB.
Sigh, I knew CPPI ISO path was broken for years but didn't have
time to
2014-01-27 Jiang Liu :
> Commit b981513f806d (ACPI / scan: bail out early if failed to parse
> APIC ID for CPU) emits an error message if ACPI processor driver fails
> to query APIC ID for the CPU.
>
> Originally it's designed to catch BIOS bugs for CPU hot-addition. But
> it accidently reveals ano
Hi Peter,
This patch set collect the bits about priority in linux/sched/prio.h and
expose some macros about priority here. So that the other parts of core kernel
can use the them without reimplementing it in an open way.
Dongsheng Yang (3):
sched: Move the priority specific bits into a new h
Some bits about priority are defined in linux/sched/rt.h, but
some of them are not only for rt scheduler, such as MAX_PRIO.
This patch move them all into a new header file, linux/sched/prio.h.
Signed-off-by: Dongsheng Yang
---
include/linux/sched.h | 4
include/linux/sched/prio.h | 2
Some macros in kernel/sched/sched.h about priority are
private to kernel/sched. But they are useful to other
parts of the core kernel.
This patch move these macros from kernel/sched/sched.h to
include/linux/sched/prio.h so that they are available to
other subsystems.
Signed-off-by: Dongsheng Yang
As commit 0e0c0797 expose the priority related macros in linux/sched/prio.h,
we don't have to implement task_nice and task_prio in kernel/sched/core.c any
more.
This patch implement them in linux/sched/sched.h as static inline functions,
saving the kernel stack and enhancing the performance.
Sign
On Mon, 2014-01-27 at 05:54 +0100, Carsten Emde wrote:
> It is well conceivable that this or one of the next 3.12.X-rtY
> versions will remind us of the legendary 2.6.33 RT kernel.
Hm. I wonder if HRTIMER_SOFTIRQ being processed alone, and at maxed out
priority wouldn't beat 2.6.33-rt on your b
Network Nut wrote:
> As you know, under Windows, synchronization objects such as {event | mutex |
> semaphore | timer}; all have names that are computer-global. Process B can
> open, and use, any {event | mutex | semaphore | timer} that was created by
> process A, as long as Process B knows the nam
Hi Christian,
Am Samstag, den 25.01.2014, 22:47 +0100 schrieb Christian Engelmayer:
> Fix a memory leak in the genwqe_pin_mem() error path as called by
> ioctl GENWQE_PIN_MEM. In case there is an error encountered when
> mapping memory, the already allocated dma_mapping struct needs to
> be freed
On Tue, Jan 14, 2014 at 3:43 PM, Alan Stern wrote:
> Don't bother. I'll redo it using the drm-intel-nightly branch, but I
> won't have time for a few days.
My apologies for the delay in getting around to this. Can you please
test the patch i've just posted?
http://patchwork.freedesktop.org/patc
Hi,
On Monday 20 January 2014 07:12 PM, Vivek Gautam wrote:
> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
> The new driver uses the generic PHY framework and will interact
> with DWC3 controller present on Exynos5 series of SoCs.
> Thereby, removing old phy-samsung-usb3 driver
On Mon, Jan 27, 2014 at 02:41:43PM +0900, Namhyung Kim wrote:
> On Thu, 23 Jan 2014 15:44:00 +0100, Jiri Olsa wrote:
> > On Thu, Jan 23, 2014 at 09:13:45AM +0900, Namhyung Kim wrote:
> >> There're some duplicate code when adding hist entries. They are
> >> different in that some have branch info o
This patch solves problem related with lack of possibility to call
aio_complete() from cancel callback. It was because it needs to lock
ctx->ctx_lock which is always locked before kiocb_cancel() call. So there
was no way to complete request properly.
Now spinlock is unlocked before cancel callback
On 01/26/2014 10:25 PM, Pavel Vasilyev wrote:
> 25.01.2014 17:45, Sebastian Andrzej Siewior пишет:
>> Dear RT folks!
>
>
> Gentlemen, let's have a month of stress testing! Divide tasks
> testing subsystem: USB, NET, MM, ACPI, AUDIO, VIDEO By CPUs:
> ARM/PPC/X86/X86_64...
>
> Purely on observatio
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre
Acked-by: Daniel Lezcano
---
arch/x86/kernel/process.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/p
Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with
COMPILE_TEST)
broke build on archs wihout io memory.
On archs like S390 or um this driver cannot build nor work.
Make it depend on HAS_IOMEM to bypass build failures.
drivers/thermal/rcar_thermal.c:404: undefined reference to
From: Jason Wang
Date: Mon, 27 Jan 2014 15:30:54 +0800
> Call netif_carrier_on() after register_device(). Otherwise it won't work since
> the device was still in NETREG_UNINITIALIZED state.
>
> Fixes a68f9614614749727286f675d15f1e09d13cb54a
> (hyperv: Fix race between probe and open calls)
>
>
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre
Acked-by: Daniel Lezcano
---
arch/sh/kernel/idle.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/sh/kernel/idle.c b/arch/sh/kernel/idle.c
inde
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
The core idle loop now takes care of it. However a few things need
checking:
- Invocation of cpuidle_idle_call() in pseries_lpar_idle() happened
through arch_cpu_idle() and was therefore always preceded by a call
to ppc64_runlatch_off(). To pr
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre
Acked-by: Daniel Lezcano
---
arch/arm/kernel/process.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/kernel/process.c b/ar
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
In order to integrate cpuidle with the scheduler, we must have a better
proximity in the core code with what cpuidle is doing and not delegate
such interaction to arch code.
Architectures implementing arch_cpu_idle() should simply enter
a cheap idle m
On Mon, Jan 27, 2014 at 9:28 AM, Krzysztof Kozlowski
wrote:
> On Sun, 2014-01-26 at 11:38 +0100, Geert Uytterhoeven wrote:
>> If CONFIG_PM_SLEEP=n:
>>
>> drivers/mfd/max14577.c:177: warning: ‘max14577_suspend’ defined but not used
>> drivers/mfd/max14577.c:200: warning: ‘max14577_resume’ defined b
On Sun, 2014-01-26 at 11:38 +0100, Geert Uytterhoeven wrote:
> If CONFIG_PM_SLEEP=n:
>
> drivers/mfd/max14577.c:177: warning: ‘max14577_suspend’ defined but not used
> drivers/mfd/max14577.c:200: warning: ‘max14577_resume’ defined but not used
>
> Signed-off-by: Geert Uytterhoeven
> ---
> drive
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
... so we can get rid of it entirely.
Signed-off-by: Nicolas Pitre
Acked-by: Daniel Lezcano
---
include/linux/cpu.h | 1 -
kernel/cpu/idle.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
in
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
ARM and ARM64 are the only two architectures implementing
arch_cpu_idle_prepare() simply to call local_fiq_enable().
We have secondary_start_kernel() already calling local_fiq_enable() and
this is done a second time in arch_cpu_idle_prepare() in that
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
ARM and ARM64 are the only two architectures implementing
arch_cpu_idle_prepare() simply to call local_fiq_enable().
We have secondary_start_kernel() already calling local_fiq_enable() and
this is done a second time in arch_cpu_idle_prepare() in that
> -Original Message-
> From: Kai Huang [mailto:dev.kai.hu...@gmail.com]
> Sent: Monday, January 27, 2014 5:50 AM
> To: Sethi Varun-B16395
> Cc: Alex Williamson; io...@lists.linux-foundation.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [RFC PATCH] vfio/iommu_type1: Multi-IOMMU domai
Am 27.01.2014 08:38, schrieb Ingo Molnar:
>
> * H. Peter Anvin wrote:
>
>> On 01/26/2014 10:49 PM, Richard Weinberger wrote:
No, because that information is available to user space unless we panic.
>>>
>>> Didn't you mean non-root?
>>> I thought one has to set dmesg_restrict anyways if
501 - 599 of 599 matches
Mail list logo
